Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • try to search for a construct like this: $wp_rewrite->flush_rules(); in all plugins and the current theme source code and if you find it, try to disable it, just as I did in the wp-e-commerce plugin.
    And, by the way, I’m using it’s Lite version (http://wordpress.org/extend/plugins/wordpress-ecommerce/) which is unfortunately up to date (no update is possible) and CONTAINS this rules flushing…

    I found the the guilty module – it’s WordPress e-commerce (http://wordpress.org/extend/plugins/wp-e-commerce/)!
    There, in the file marketplace.php on line 300 there is:
    add_action( 'init', array(&$this, 'flush_rewrite'), 999 );
    Commenting out this line made the Polylang work smoothly without any (my) additional intervention. Now the question is, if this flushing is needed for the e-commerce module to work, or not, but that’s a question for different forum, different topic.

    On the other hand – now that we know there are such “treacherous” modules out there doing such things, could you think about amending the Polylang module to survive in such environment? I find it very helpful (great job Chouby, BTW!) and more people could use in combination with not-that-codex-compliant modules…

    Well, this issue occurred each time I manually triggered the rebuild of rewrite rules (via Permalinks -> Save), meaning the incorrect language_rewrite_rules breaking the %postname% permalink rewrite rule was stored in the database, so I assume it’s not the problem of flushing rewrite rules in init of any m module, but I can have a look.

    Perhaps better tuning of order of calls to add_filter can be done to get the desired result.

    Have you been able to reproduce the issue?

    Might be, I’m pretty new to WordPress and the site I’m working on has no custom post types, so I haven’t noticed it does not work.
    Probably the rewrite rules creation must be split – some of them must be created earlier (like the language_rewrite_rules) and some laters, especially rules related to custom post types as these are most probably not yet initialized in the init() phase.
    Please, try to investigate and let me know.
    Thanks.

    Some more experiments revealed, that most probably the whole Polylang::prepare_rewrite_rules() must be called from init(), otherwise localized homepage (and other pages requiring language code) will not work.

    So the final fix suggestion is to add the mentioned call at the end of the init() function of the Polylang object, so the tail should look like:

    add_permastruct('language', $options['rewrite'] ? '%language%' : 'language/%language%', version_compare($GLOBALS['wp_version'], '3.4' , '<') ? false : array('with_front' => false));
    
    $this->prepare_rewrite_rules();
    }

    Hi, I think I found the issue.

    I also like the Polylang module and I also ran into 404 errors when using %postname% pretty permalinks. Because I did not find a solution to this on Internet, just a couple of similar reports, I had to sit down and debuge the module myself and I think I found it.

    The issue is caused by rewrite rules added for language category, tag = “language_rewrite_rules”.
    Even though they ARE processed (removed) by the Polylang module (polylang.php, function rewrite_rules, lines 371-372: if (($current_filter = current_filter()) == 'language_rewrite_rules') return array();), this processing is too late and it is not executed when the language-related rewrite rules are being created (wp-includes/rewrite.php, function rewrite_rules, line 1580: $rules = apply_filters($permastructname . '_rewrite_rules', $rules);).

    This is because the Polylang prepare_rewrite_rules() function that actually adds the filter, is called too late (Polylang constructor, line 88, add_action('wp_loaded', array(&$this, 'prepare_rewrite_rules'), 20);)

    So my suggested quick fix is to move the add_filter(“language_rewrite_rules”) to the end of the init method (Polylang::init(), line 335: add this line: add_filter('language_rewrite_rules', array(&$this, 'rewrite_rules'));
    )

    Then redundant adding in prepare_rewrite_rules() can be removed, so the enumeration on line 359 can be changed to:

    foreach ($types as $type)
      if ($type != 'language')
        add_filter($type . '_rewrite_rules', array(&$this, 'rewrite_rules'));

    Works for me.

Viewing 6 replies - 1 through 6 (of 6 total)