rklrkl

I got exactly the same error as the OP – this was on a CentOS 6 system running PHP 5.3.3. My suspicion is that version 1.3.0 of the plugin uses a feature of PHP only present in versions later than 5.3.3. Note that version 1.2.4 of the plugin works fine with PHP 5.3.3.

I think the issue here is that you’re not told up front that your site will go offline immediately the plugin is activated for the first time. This means the plugin actually causes unexpected site downtime which isn’t good really.

Also, when you’re in panic mode trying to turn off maintenance mode that hit you on first activation, clicking on the green “Maintenance On” button in the Settings doesn’t take immediate effect (despite immediately changing to a red “Maintenance Off” button to give you the impression maintenance mode is off). You have to remember to scroll all the way down the page and click on the “Save Changes” button. I think the Maintenance On/Off button should take immediate effect myself.

For a “Tech Dude”, Samuel’s replies have been shockingly sub-standard in this thread, though I will admit that I messed up the substitution in my previous posting – it should have been:

https://example.com/blog -> /
(i.e. no need for a regexp)

and Samuel made the one correct note in his reply that the old URL should have been absolute and not relative. Of course, that move of /blog to / may have to be accompanied by an Apache RewriteRule to redirect external old /blog links to the new location:

RewriteRule ^/blog(.*) https://example.com$1 [R=301]

I will repeat that editing hosts files is at best messy and at worst just about the most inefficient way of pointing to a Web site across multiple dev desktops. The fact is that there are often 3 or 4 separate URLs to deal with for each site’s that developed and moving an entire site between them is ultra-painful because of absolute URLs in the DB.

Also the claim that “Absolute URLs work better” is unbelievable – there’s not a single shred of evidence you’ve presented here that proves that. I’ve explained how absolute URLs in the DB are *much* worse, particularly when copying from one URL to another (I noticed you ignored my long list of circumstances where the URL might change – it’s *very* common as I’ve shown, in direct contradiction to your earlier claim).

As for the frankly bananas suggestion that I write a plugin for what I want, well that beggars belief. The problem here in the core WP code as you should well know, being a “tech dude”.

Can you actually provide any proof that having relative URLs in the DB would be worse than absolute ones? Even your /blog -> / move in a DB with relative URLs could be done with my original ^/blog -> / regexp. Plus that sort of relative move is *far* less common than the top-level URL changing anyway.

Why not put “Hello Dolly” into the WordPress Plugin “Store” and then display a banner on first install of WP linking to the plugin and suggesting it can be installed as an example if you’re a plugin developer?

It means it’s no longer in the default install, but it’s still very visible if people want to try it out as an example plugin.

Replying to Wordfence’s post:

> I think it’s OK to modify readme.html. You’re the first to complain about this.

It’s certainly not OK to rename a core WP file as I’ve said earlier. I might be the first to directly post into the Wordfence section of the official WP support forum, but Google did find this, which looks like the hand of Wordfence:

https://www.ads-software.com/support/topic/readmehtml-renamed-hacked?replies=3

> If you don’t like it, just disable the option. It’s as easy as unchecking a box. Nothing dubious about it.

Silently changing a default (you should have put up a warning banner about the change) between releases is bad, especially when the default now actually renames a core WP file, which you should *never* do.

> WP-CLI is not part of core. Again, if you don’t like the feature in Wordfence, just uncheck the box.

WP-CLI might not be part of core, but as WP devs you surely know that WordPress has a checksum API documented here *as part of its core* for tools to use:

https://codex.www.ads-software.com/www.ads-software.com_API#Checksum

Wordfence now breaks that checksum API call when it is installed (or upgraded from an older release that didn’t rename /readme/html). and I suspect WP-CLI isn’t the only security tool using that API. Ironically, you either aren’t making that API call in your Wordfence or you’re deliberately ignoring the missing /readme.html – neither of which is decent security!

> Yup, we’re aware of that, and the version leak that every other plugin with a readme.txt has.

You do realise that this makes it “one rule for us and another rule for everyone else”. Your readme.txt is a far bigger security leak than /readme.html, but it’s “la la la, head in the sand, we’re a security company and we know what we’re doing”. I think it’s time to write a WP plugin that renames /readme.html back again and renames your readme.txt to readme.this.is.security.leak.txt instead ??

> As I mentioned above, I’d encourage you to participate in the community effort that goes into WordPress and file the issue yourself.

OK, so *you* rename /readme.html and break a core WP checksum API and *I’m* expected to chase up WordPress devs asking them to change /readme.html because a “security” company has gone against WP guidelines about not changing core WP files? I’m going to get short shrift there I suspect.

As another poster pointed out (and I should have suggested it myself) – how about an .htaccess entry that Wordfence can add that forbids the loading of /readme.html ? This satisfies your “security through obscurity” measure and doesn’t modify the WP core files either. It seems a decent compromise if you won’t budge on this issue.

Oh and how this issue is marked “resolved” when absolutely nothing’s been done about it is beyond me.

I’ll reply to Samuel’s points one by one:

> However, what happens when you want to migrate a site up a directory from https://example.com/blog to https://example.com ?

It’s called regular expressions and the tool I linked to in my posting supports them. You replace ^/blog with / and you’re done.

> There’s also the case to consider for things like RSS feeds, or other ways of presenting your content

Sadly, you completely missed my whole point – URLs in HTML would be remain absolute URLs, so RSS and other feeds would still display absolute URLs as they currently do now. It’s *only* the DB that would contain relative URLs.

> And let’s face it, realistically, “moving a site” is a pretty uncommon thing to do.

That’s entirely your opinion but not what I experience:

* Dev site copied to UAT (and reverse).
* UAT site copied to live (and reverse).
* Live site synced to DR (possibly requiring URL changes on every single sync of the DB).
* Client doesn’t make their mind up about the live URL until near end of project development (you’d be amazed how often this happens), requiring the “ready to go live” URL to be on a temporary URL that has to be renamed when finally going live.
* Client decides to switch primary live URL (e.g. .com to .co.uk or vice versa).
* A secure cert is purchased (could be up to 4 URL changes needed: dev, UAT, live, DR) for a previously http-only site.

> Changing your hosts file to point whatever domain you like at a local development server is easy verging on trivial.

Editing hosts files to point to sites is *appallingly* kludgy and not great if you have to do it on multiple dev machines and keep a track of which entries should actually be in there – this is what centralised DNS is for!

There is no technical reason why absolute URLs are in the database and they just cause grief – witness the number of posts on the WP forums complaining about this issue!

My post is slightly different from most others out there in that I’m not changing absolute URLs in the output HTML at all. I just want the WP DB to have relative URLs and get the absolute URLs in the HTML constructed from $_SERVER variables. I’ve no idea how major of a task this is, but I can’t believe it’s too difficult though.

BTW, why has this thread been marked as “resolved” – nothing’s happened at all and the highly irritating problem of absolute URLs in the DB remains. It’s about the most hated feature of WP for me and completely unnecessary thanks to PHP’s $_SERVER variables.