DAE
Forum Replies Created
-
Forum: Plugins
In reply to: [Ceceppa Multilingua] Fix 500 Internal Server Error NOT WORKJust my tuppence, I updated a few plugins after restarting work on a site after a couple of months (it’s not online) and 500 error purely because what should be
RewriteBase /
…
RewriteRule . /index.php [L]is instead
RewriteBase /en/
…
RewriteRule . /en/index.php [L]It’d take more digging to 100% pin it on Ceceppa but it’s a bit suspect.
I don’t know if this has anything to do with ‘ Automatically redirects the default language’ in actions but if the default language isn’t set to the base url it rewrites everything to /en/index.php which then bypasses all other rules on looping because it doesn’t start ‘index.php’ and isn’t a file or directory so keeps hitting the last catchall and loops again.
Even if it did work, the other language would either be inaccessible as /fr/ or display as /en/fr/?
Hi,
Thanks for getting back.
It’s something a client did when trying to add buttons, removed now (as it redirects to another page anyway, no point). The problem seems to be ocurring in some fashion anyway with a single line of text in <p> tags. I haven’t looked in depth at what your parsing code does so I can only say for this use case that I hadn’t pinned it down immediately as it appeared fixed until I went to change something in the theme. Still need to solve the problem that had me looking in the logs actually.
This isn’t something that’s going to happen all the time but it does cause JSMin (in this case called by Autoptimizer but also default for W3 Total Cache) to throw an exception. It seems to be very particular about what it accepts as a newline.
Further update, there’s still some mangling for intents and purposes. JSMin really doesn’t like it when you remove
\r, seems to only properly recognise UNIX newline formatting.I’ve seen the exception disappear in my logs with by changing
var singleOptinMessage = '<?php echo str_replace( '\'' , '"' , preg_replace('/\r?\n/', '\\n', apply_filters('yks_mc_content' , $this->optionVal['single-optin-message']))); ?>'; var doubleOptinMessage = '<?php echo str_replace( '\'' , '"' , preg_replace('/\r?\n/', '\\n', apply_filters('yks_mc_content' , $this->optionVal['double-optin-message']))); ?>';to
var singleOptinMessage = '<?php echo str_replace( array('\'',"\r","\n") , array('"',"\\r","\\n"), apply_filters('yks_mc_content' , $this->optionVal['single-optin-message'])); ?>'; var doubleOptinMessage = '<?php echo str_replace( array('\'',"\r","\n") , array('"',"\\r","\\n"), apply_filters('yks_mc_content' , $this->optionVal['double-optin-message'])); ?>';Not certain if this breaks anything yet but we’ll see.
Or was it the DIVs? Wouldn’t be a bug then but still worth handling as WP won’t reject it as content.
Scuse me, brain fried.
Forum: Plugins
In reply to: [BulletProof Security] Problems with # BEGIN/END placement.Cool, look forward to it!
Forum: Plugins
In reply to: [BulletProof Security] Problems with # BEGIN/END placement.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]Forum: Plugins
In reply to: [BulletProof Security] Problems with # BEGIN/END placement.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.