plembo

<> is not an industry standard, and saying it is won’t make it so. To me it’s just an affectation that has no real value.

I ran into this same issue with the web mail client of my provider. It has been at least 4 years since people started reporting problems with the use of angle brackets around the url. I know someone must really like the look of them, but honestly can’t we let functionality win for once and just eliminate them from core altogether?

If the link has to be surrounded by symbols (to deal with the need for a visual queues where the url might wind up continuing across a couple of lines in a word-wrapped message) why not pick something that isn’t actually used in HTML, like square brackets (“[]”) or (almost insufferably ugly, I admit) braces (“{}”)?

As it stands we’re all going to have to keep hacking that core code to eliminate it ourselves. Is that really what anyone wants?

How do you have things configured on the plugin’s settings panel?

Also, have you tried this with 4.3.1? We didn’t become aware of this plugin until a couple of weeks ago, so we’ve been doing all our testing on 4.3.1 and really haven’t had any issues — other than selecting the “redirect to OpenAM” box resulting in user’s getting an annoying double challenge.

FYI we’re using Red Hat Enterprise Linux 6,7 with Rackspace’s IUS Repository builds of php 5.4, as well as direct pear module updates.

Feel free to obfuscate the settings values like urls to preserve your operational security.

Sorry for the delayed response. I doubt my search and replace did this: I’m basically using a perl one-liner against the mysqldump output:

perl -pi -e 's/oldsite.example.com/newsite.example.com/g' dump.sql

My own idea after seeing this happen multiple times is that this might be due to the snapshots being done while the instance is “hot”, that is while still connected to the web server and receiving traffic. One of the things I’ll try the next time around is to shut down the web server to prevent any access to the instance during the time mysqldump is running.

Just to update everyone: I’ve directed that HyperDB be removed from all our sites and am now working with our engineering team on developing a MySQL (actually MariaDB Galera) cluster to provide a more reliable (and better documented) solution.

Sadly I have to report that I’m having the same “Big Issue” that Commeuneimage reports (on WP 3.8.1 trying to import images from an original blog on WP-MU 2.9.1.1). Testing in my dev environment resulted in src values in all blog img tags being stripped out and no images imported. I suspect something is really squirrelly about the originating site (it’s really old and has been exhibiting weird behavior for awhile), but having some kind of debugging output or greater verbosity as suggested above would be very helpful. FYI, only took a few seconds to restore things (mysqldump is your friend, always), so no harm done.

Thanks Handoko, at least we know we’re not alone! Of course at my shop we already had a fairly easy to use backup solution in place: a perl script that does a mysqldump every night and that can be kicked off at will by my developers from a webmin console. At this point my concern isn’t so much the loss of backup functionality in an otherwise stellar plugin, but whether it’s a symptom of a problem with my platform or WordPress configuration. Around here we like to uncover root cause as a way of heading off future trouble (which is always just around the corner!).

I learned a long time ago never to accept the defaults during install of any system management/security software. When installing something like this it’s always best to go the most conservative route at first. In the case of Better WP Security that means avoiding “One Click Protection” at all costs, and initially not even giving it permission to change your core WP files. After it is set up you should spend some time studying just what each option does (the documentation is actually quite good) before enabling anything.

I’ve installed Better WP Security in five different WordPress instances successfully. The backup function on just one is misbehaving exactly as nemof describes. Its twin is working just fine. Both these installs are multisite enabled and only accessible on our intranet. We’re running WP 3.51 on RHEL 6.3 with shipping Apache configured with multiple virtual hosts, and IUS php 5.4.13-1. The site whose plugin isn’t able to do backups is behind a BigIP LTM. We’ve checked to make sure that everything else is identical: file system permissions, php.ini settings, etc.

Can someone suggest some diagnostic procedures we can follow to find the root cause of this problem? Any assistance would be much appreciated.

On a hunch I decided to try installing and configuring another MultiSite instance directly to the server hostname (newserver.example.com) with WP as DocumentRoot, and then reconfiguring it to use the BigIP name (topsite.example.com). The reconfiguration was done by editing wp-config.php and the database to replace the actual hostname with the BigIP name. The latter was accomplished by doing a mydsqldump to a text file, searching and replacing, and then restoring.

It worked. Apparently whatever was going wrong with the WP install through the BigIP is something specific in the install process (whacky rewrites/redirects?), not the final site configuration.