Problems with # BEGIN/END placement.

  • Resolved DAE

    (@motionrotation)


    11 years, 7 months ago

    OK, starting with: WP _will_not_ use any rules from get_option(‘rewrite_rules’) unless $GLOBALS[‘wp_rewrite’]->use_verbose_rules is set to true, which by default it’s not. Too many plugins rely on this obscure little condition.

    The main issue is that everytime a plugin calls rewrite_flush it replaces everything between BEGIN and END with just the basic WP loop and wipes everything. Seriously, if ‘verbose’ is false it loads, processes, filters the rules for archaic Apache 1.3 regex limitations then drop them.

    The solution to this is _NOT_ to set ‘verbose’ to true as this will immediately break other plugins that won’t get the path they expect. Very break, much 404, no RewriteRule . /index.php catchall.

    This may require more active handling of the BPS rulesets and your own management. What may be viable is to dropkick the entire default ruleset in the options table or at least alter it.

    Also line 9 of secure.htaccess in version 0.51 triggers multiple outputs of the WP loop because. wp-admin/includes/misc.php:125

    https://ww.wp.xz.cn/plugins/bulletproof-security/

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Author AITpro

    (@aitpro)

    11 years, 7 months ago

    http://codex.ww.wp.xz.cn/Function_Reference/flush_rewrite_rules

    This function is useful when used with custom post types as it allows for automatic flushing of the WordPress rewrite rules (usually needs to be done manually for new custom post types). However, this is an expensive operation so it should only be used when absolutely necessary. See Usage section for more details.

    Usage
    Important:

    Flushing the rewrite rules is an expensive operation, there are tutorials and examples that suggest executing it on the ‘init’ hook. This is bad practice.
    Flush rules only on activation or deactivation, or when you know that the rewrite rules need to be changed (e.g. the addition of a new taxonomy or post type in your code). Don’t do it on any other hook. More detail information in the comments on WP Engineer’s post: Custom Post Type and Permalink
    Make sure custom post types and taxonomies are properly registered before flushing rewrite rules, especially during plugin activation: Activation Checklist for WordPress Plugin Developers

    The WordPress flush_rewrite_rules() function performs a couple of tasks. The most important/essential task is internal for flushing custom post types and taxonomies. The external task of “flushing/replacing” the root htaccess code causes some issues and problems.

    If you have a CGI server type you can lock your root htaccess file on the BPS htaccess File Editor tab page. This will allow the internal important/essential task to do what it needs to do and will prevent your root htaccess code from being “flushed/replaced”.

    If you have a DSO server type then you cannot lock your root htaccess file and will just have to reactivate root folder BulletProof Mode each time your root htaccess file code is “flushed/replaced”.

    This may require more active handling of the BPS rulesets and your own management. What may be viable is to dropkick the entire default ruleset in the options table or at least alter it.

    We would not want to interfere with or prevent another plugin or theme from using the WordPress flush_rewrite_rules() function so instead the solution is to prevent the root htaccess file code from being flushed/replaced with the BPS Lock root htaccess file option.

    Also line 9 of secure.htaccess in version 0.51 triggers multiple outputs of the WP loop because. wp-admin/includes/misc.php:125

    Yes, we are planning on changing the placeholder/help text in the root htaccess file so that only 1 instance of the default WP htaccess code is added when the root htaccess file code is flushed and not multiple instances based on the placeholder/help text.

    Plugin Author AITpro

    (@aitpro)

    11 years, 7 months ago

    This is on the scheduled task list for BPS .51.1 and will be included in BPS .51.1.

    Thread Starter DAE

    (@motionrotation)

    11 years, 7 months ago

    Hmm, didn’t see the lock option, not on Apache? It’s also something which makes things slightly tricky if you do need anything else to write. My current sticking-plaster is just to move the BEGIN/END markers so a flush doesn’t actually change anything. I’ve also had to manually insert the rules for YOAST, an enthusiastic flusher if you like, trying to insert rewrite rules which never make it because verbose = false.

    It’s possible that the site I’m creating, a simple 2 language brochure site, isn’t triggering anything because no custom post types? The manner in which some things are handled internally makes it more difficult to pin down when things happen with all the variable name aliasing.

    The problem with flushing of the rules is that it’s not necessarily something an end user has complete control over. I’ve no immediate way of telling if this is always the case or if it’s one of the other plugins but the rules get flushed every time I open (not save, open) the Permalink Settings page.

    Good to know you’re on the case but there’s also a wider problem which I’m not sure is yours to fix, but it may require working around. In short:

    • From an install of last version before 4.0, updated to current.
    • Using rules from those stored in the options table is off by default and stays off. This appears to have been the case since 2.0
    • Switching on use of this in wp-settings breaks Ceceppa plugin (translation), possibly (haven’t tested) because there’s no catchall rewrite rule appended.

    I don’t know how common this problem with flushing is but I’ve seen enough people complain about related problems like plugins hosing their rulesets, having to manually add rules before certain plugins work properly etc. to think it’s not rare. It may be safest to assume that anything between the markers is going to be interfered with.

    I don’t want to be a downer on things, if I thought your work sucked I just wouldn’t use it. I’m just hoping some sort of cause -> effect can be pinned down here to resolve this problem.

    Plugin Author AITpro

    (@aitpro)

    11 years, 7 months ago

    Hmm, didn’t see the lock option, not on Apache?

    The Lock / Unlock buttons are only displayed on Apache CGI server types and not Apache DSO server types since DSO file permissions are different than CGI file permissions. DSO requires 755/644 or a similar variant. CGI allows for 700/705 folder permissions 604/400/404 file permissions.

    “…I’ve also had to manually insert the rules for YOAST…”

    Are you using BPS Custom Code to save your YOAST code permanently or are you editing your root .htaccess file directly with the htaccess File Editor? Unfortunately, most of the placeholder/help text sections of the root htaccess file cannot be changed using BPS Custom Code, but that will be a moot point once BPS .51.1 is released that permanently “fixes” the multiple instances of the WP Default htaccess code being created in the root htaccess file.

    To tell you the truth I only generally understand the usage for the WordPress flush_rewrite_rules() function. I have never used that function personally in any code that I have ever written so I only know the basics of what the function’s intended purpose is.

    Good to know you’re on the case but there’s also a wider problem which I’m not sure is yours to fix, but it may require working around. In short:

    These things above are all out of our control and “jurisdiction” to control. We would not want to interfere with the functionality of other plugins or themes or WordPress itself. As far as BPS is concerned there is only one aspect of what occurs during a “flush” that we have control over and that is specifically what occurs in the BPS Root .htaccess file and code.

    Yep, I have heard and seen a lot of complaints about that function too. 😉
    Yep, we will handle our end of things/jurisdication in BPS .51.1.

    Here is another approach below that you could take, but it could cause problems for your site. I just don’t really know enough about that particular function to tell you what the deeper implications would be of doing something like this below would be:

    Very Rough example/idea: hook into whichever plugin’s function that is using the flush_rewrite_rules function (or maybe this could be done globally) and then do an “unset” or change the returned value from true to false – in essence stopping the function from doing anything.

    Plugin Author AITpro

    (@aitpro)

    11 years, 7 months ago

    If you did do something like the very rough example/idea above you would create your custom function in your theme’s functions.php file. I do not know when it should be called. ie “init/action priority” to be effective.

    Plugin Author AITpro

    (@aitpro)

    11 years, 7 months ago

    Or actually what would be much smarter if it is possible is to hook into the flush_rewrite_rules function itself and then allow everything to occur that normally occurs with the function with the exception of flushing/replacing root htaccess code. This is actually something I would like to research myself and if it is possible to do something like this then I feel it would not be interfering with other plugins and themes functionality since the important/essential tasks regarding custom post types would still be processed normally.

    I will look into this during the next few days and post what I find back here.

    Thread Starter DAE

    (@motionrotation)

    11 years, 7 months ago

    Actually hadn’t caught on to the custom code section but no, I’m not expecting you to do anything about that as it should be inserted by other means anyway, just an example of something I could see failing to transfer from rewrite_rules in the database. There’s just the problem of the rules that are in the default secure.htaccess also getting wiped.

    There do seem to be some filters used in flushing but I’m not sure any are used without the precondition required to use verbose rules. It would be hackish to use that and might interfere with other plugins as before.

    What might be best is to use a function similar to insert_with_markers (which is used for the actual writing on flush) in wp-admin/includes/misc.php. I say ‘like’ because it’s marked as internal so no-one gets to complain if it disappears one day. I’ve tried tweaking code that’s not 100% in my control before and it always ends in something breaking sooner or later so I’m not going to do that.

    Fundamentally, without direct writing the .htaccess file it seems difficult to alter these rules in a way that sticks and doesn’t break something else. add_rules determines anything starting ‘index.php’ to be internal and only external rules get used from the database by default so anything between BEGIN/END gets overwritten with the hardcoded

    RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
    Plugin Author AITpro

    (@aitpro)

    11 years, 7 months ago

    Hooking into the flush_rewrite_rules function globally is not an option and even trying to hook into each plugin’s call/usage would be problematic. I believe that is the same conclusion that I came to years ago when I looked at this function.

    The optimum approach is to handle things “after the fact”. ie if/when X happens do Y to get Z instead of trying to filter X to acheive Y to get Z. So the first important step is to get the BPS root htaccess code squared away so that BPS itself will not be a factor in multiple instances of the WP default rewrite code being written to the root htaccess file. If a plugin still does this mistake/error then BPS will try to recover from that plugin’s error/mistake. If the site crashes due to another plugin’s mistake then BPS cannot do anything about that scenario.

    Plugin Author AITpro

    (@aitpro)

    11 years, 7 months ago

    Of course locking the root htaccess file (if your server type allows this) is the simplest and most effective method of preventing a problem with the flush_rewrite_rules function since it allows the flush of xxx_options | option_name | rewrite_rules, but prevents the root htaccess code from being mangled.

    Plugin Author AITpro

    (@aitpro)

    11 years, 7 months ago

    We had to get a quickie version of BPS released (BPS .51.1) since a security vulnerability was reported in BPS and the WP folks sent me a heads up about that. So anyway the root htaccess code changes will be in BPS .51.2 very soon. And no the “security vulnerability” was not really a security vulnerability in my opinion since in order to execute the exploit/vulnerability you would need to be logged in as an Administrator to the website. If you already have the admin password then in my opinion that would already be >>> game over. 😉

    Plugin Author AITpro

    (@aitpro)

    11 years, 7 months ago

    Just wanted to give you a heads up on this. We have a working solution that is very simple to permanently stop the multiple instances and single instances of the flush_rewrite_rules htaccess code issues/problem. Remove all WordPress BEGIN/END markers from the standard BPS root htaccess file/code. When a flush occurs the standard WP rewrite code is appended to the bottom of the root htaccess file and BPS automatically does a string replace and removes that standard WP rewrite code when that happens. End result: no alerts, no problems and the root htaccess file does not need to be locked. Ironic how simple the solution was. ETA on BPS version .51.2 release is November 5th to the 12th.

    Thread Starter DAE

    (@motionrotation)

    11 years, 7 months ago

    Cool, look forward to it!

    Plugin Author AITpro

    (@aitpro)

    11 years, 6 months ago

    BPS .51.2 has been released. We decided to do this as a one-time manual click thing for a number of important reasons instead of just completely automating the process like a typical/normal BPS upgrade. You can see all of the reasons for choosing that route here: http://forum.ait-pro.com/forums/topic/root-and-wp-admin-htaccess-file-significant-changes/

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

The topic ‘Problems with # BEGIN/END placement.’ is closed to new replies.