Category Archives: Uncategorized

WordPress Multisite Error

A very open headline for what was a confusing WordPress Multisite Error. A more accurate headline after the event might be WordPress Multisite migration to a new server or domain url.

Scenario: An older wordpress site was migrated to a new server with PHP7.3 but was using PHP 5.6 on the old server and was not working on the new server. The problem was that the old server had been decommissioned.

At this point I was asked to review and fix if possible. I tried a number of processes just to see if an in-place fix was possible, including turning off the multi-site function for the site copy on the new server and processing wordpress updates, but turning the multisite back on failed to run the site.

So I created a ‘dev’ copy on a PHP5.6 enabled server, copied in the database, and the files, configured the options settings to change the live url to the dev url, and then stepped through the following:

First issue was that the url of https://dev.insertdomainnamehere.com/ would process but come up with a result of ‘server not found’ with the url modified to show as https://http//dev.insertdomainnamehere.com// which looked weird, was obviously broken, but why was it happening?

It seemed like a mod_rewrite issue, which pointed at the .htaccess setup so I reviewed that. Reference https://wordpress.org/support/article/multisite-network-administration/#htaccess-and-mod-rewrite
and compared all the lines, and the (potential) version matching issues, and I used the settings for 3.5+ which seems to still hold true for WordPress 5+. Nothing seemed wrong here.

Next I checked in the wp-config.php file and confirmed the database settings and then the various WordPress multisite parameters and in particular the define(‘DOMAIN_CURRENT_SITE’, ‘ https://dev.insertdomainnamehere.com/’) which I had modified from the live site url. I found that if I modified this setting then the broken url changed to correspond to this domain setting.

Why the weird url? Because this parameter should not include the protocol or the trailing slash. The correct format of this parameter would be:

define( 'CURRENT_DOMAIN_SITE', "dev.insertdomainnamehere.com"); 

So I turned off multisite setting with define(‘MULTISITE’, false) in the wp-config.php file and found that the access to the site was working, albeit without the Network option or subsites available. This just confirmed that the database connection was working and that the site configuration was ok, at least in part.

Checking the content of the database I noted that the subsites had table prefixes of wp_2_ and wp_3_ consistent with a multisite database, except there was no wp_1_ which made me wonder if the primary site was not configured correctly (strange as it had been working previously).

But that is correct. From one of the pages I reviewed ” It’s not supposed to make wp_1_* tables anymore. That was only done in WPMU and as of WordPress 3.0, you start with wp_* and all subsequent sites get numbers. ” So the wp_2 and wp_3 are correct.

Reviewing some more WordPress commentary searching for wp_1 gave up this reference at Stackoverflow on a WordPress database issue and while the problem was not the same, one of the replies slapped me as I had missed one of the multisite settings (or lack of it) in the wp-config.php.

define( 'WP_ALLOW_MULTISITE', true ); 

This is not the same as

define('MULTISITE', true);

and the wp-config.php file was missing the WP_ALLOW_MULTISITE parameter. (Why and for how long?) In any it was now added.

Not so much second, but just somewhere in the mix, I found that with some setting combinations, I would get a “Error establishing database connection” as a WordPress formatted error page. Which made me think that the database connection was wrong, but as mentioned above, swapping to multisite = false worked ok, so not database as such.

Next reference was found while I looked at Stackoverflow results again with https://stackoverflow.com/questions/19724781/wordpress-multisite-error-establishing-a-database-connection-in-localhost in which another comment not directly relevant to the issue was about checking the wp_blogs table.

Noting that I had modified all the wp_options tables to use the ‘dev’ site url, I checked the wp_blogs table only to find that these were (naturally) still pointing to the live site url’s. A quick modification to each of the primary and two subsite urls and the site was running smoothly.

In summary, for multi-site to work, we must have:

  • wp-config.php with both WP_ALLOW_MULTISITE and MULTISITE parameters defined as True.
  • update the wp_options tables AND the wp_blogs table to reference the new site url.
  • update or at least check in the wp_site_meta table for the ‘network admin’ access
  • correct format of the parameter for CURRENT_DOMAIN_SITE

Now, I should be able to get on with security patching and reinstatement as a live site.

Ebay turning off ‘Active Content’

eBay has been nagging about turning off ‘Active Content’ for about a year now.

“From June 2017, you’ll no longer be able to use active content when creating your listings. Find out how it affects your listings.”

During that time I have had a ‘look’ at and they quote:

“Examples of active content include JavaScript, Flash, plug-ins and form actions.”

BUT…. and it is a big BUT for me, when you get into the ‘fine print’ this also includes a number of standard HTML4 tags like center and table… 

AND THEN….  (yes I am shouting) we are “Mobile Non-Compatible”… GASP, SHOCK, HORROR….

Ok, I have had a Valium and calmed myself from apoplexy… (Exaggeration level = 2.6)

I do a lot with eBay for various reasons, including my redundant household items that I need to dispose of and I have been using eBay since 2000 to vend my reproduction toy boxes, ephemera, and toy car spare parts. It is a hobby but has been a major aspect of my life for almost 30 years. 

So if you have read this far, you are probably looking at trying to fix your eBay listings for the first time in a decade. While you were ‘warned’ ages ago, the eBay communications have been sadly lacking in being explicit, resulting in it now being June 2017 and your listings will be changed even though you never had any ‘active content’ in the first place. BUT… you did, ‘wo is me’, use HTML4 and it is now time to use HTML5….  Argghhh… 

OK, so now that my rant is ended. What to do ?

Perhaps the easy way is to get someone else to help, the old ‘phone  friend’ technique. 

There are a number of sites that appear reputable and offer themes or designs for ebay templates. 

http://www.i-ways.net offer (and is linked from ebay) a mobile-friendly testing service. 

Try http://www.i-ways.net/mobile-friendly/en-au/ to test one of your listings…  mine failed miserably. 

The following links are to the posts that I have created as I step through the minefield that is ‘creating compliant listings for ebay’.

First up this is the eBay seller information page on Active Content. http://sellercentre.ebay.com.au/activecontent

Which details lots of stuff about Java, hit counters, etc. and buried down towards the end of the page is the, oh yeah, stop using these HTML4 Elements as well and a list of the dozen tags that will no longer be supported. 

Among these are the common ones for centering your ad and setting font styles, etc. There are some that I would not have used anyway., like ‘<applet>’

So eBay then recommend the i-ways.net “Free eBay Template Service” but be warned that they want to know everything about you in exchange for the service, so the “price” is your information and a direct connection to your eBay account. I opted to register but did not connect my ebay store at this stage. 

If you are doing the same, have some images ready! (png or jpg formats)

Store Logo 400 x 140px (3Mbyte max file size) and Store Banner 1200x550px (5Mbyte max file size).  

 

[links coming soon…]

 

 

WordPress MainWP BackWPUp job creation

For WordPress administrators WordPress MainWP BackWPUp job creation should be a simple process.

MainWP is a very handy console for those of us managing lots of WordPress sites.

BackWPUp is a very popular plugin to assist with managing those sites.

My experience has been not so supportive of either notion.

WordPress MainWP BackWPUp job creation proved to be a lengthy process of diagnosis of multiple bugs and ‘features’ that were eventually worked out but with a lot of time wasted.

This was using MainWP with MainWP Child and BackWPUp plugin in both the MainWP central dashboard and the child site.

MainWP and Child Utility

I use MainWP as a centralised management tool and it offers a connection or interface to manage BackWPUp from the central dashboard. In the main it works, but there are a number of gotcha’s.

Modifications are not Sync’d

The first is when you modify a backup job in the child site (the client site) and you sync from the child site to the MainWP dashboard. The changed configuration of the BackWPUp job is NOT changed in the MainWP dashboard from what was previously configured. (At least this is the case with fields in the FTP transfer and job name fields. I did not test every setting field)

So you must make changes only from the MainWP dashboard as a ‘sending’ sync will transfer the details from MainWP to the child site, but my testing shows that it will not ‘get’ or receive setting changes from the child site. So management is only one way for BackWPUp at least. I trawled the MainWP documentation but cannot find any precise description of what a Sync Data process is meant to do.

Allowed Tags Do not Transfer

Secondly, the instructions in MainWP for BackWPUp are really misleading (I wasted hours on this task alone because what seemed clear and concise was completely misleading).

The MainWP BackWPUp page setting for the backup job name and archive name state that you can use variable tags:

Allowed tags: %sitename%, %url%, %date%, %time%

and this would appear to be straight-forward. You should be able to make the date / time variable in the archive name in order to retain multiple day backups where needed.

So I confidently applied an archive name of daily-%sitename%-%date%-%time% with the expectation that MainWP would pass this to the child site in the archive name field for the BackWPUp job.

Gotcha !! MainWP takes the variables and converts them at the time that you save the job in MainWP and transfers the resulting archive filename to the child site for the BackPWUp job !

So in the child site we now have an archive filename that does NOT get a changing date / time stamp and will replace the archive on a daily basis. Nasty if you think you have 7 days of backups.

Allowed Tags are Inconsistent

Finally, I tried copying and pasting the daily-%sitename%-%date%-%time% parameter for the archive file name field value directly into the child site job. But the was perplexed as I got some crazy file name that included % signs etc…… but another Gotcha!

Yep, the MainWP “Allowed Tags” only apply within MainWP, which would be fine if they worked, but they don’t.  So the %sitename% parameter is interpreted in BackWPUp as %s (for seconds as in time) and the ‘seconds’ is inserted in the archive name along with “itename%-“.

The rest of the archive filename consists of correctly interpreted but clearly invalid ‘tags’. This is because BackWPUp provides for a completely different set of parameters or allowed tags that are completely inconsistent with the MainWP configuration.

So as a last resort, I configured the child site job for BackWPUp with something like daily-thowden.com.au-%Y%m%d-%H%i so that I get a changed date / time within the archive file name.

I then manually copied that from the child site to the MainWP dashboard.  (Yes, manually, remember that the sync process is one-way!). From that point on I now have a working backup cycle.

BackWPUp

Ok, so I now have a configured BackWPUp job ready to test and schedule on my child site.

BackWPUp Date Time Stamp Issue

Now that the backup would run I got to check the BackWPUp logs and found that they are incorrectly date / time stamped with the system date being ignored and using UTC / GMT time instead. Painful when trying to confirm local time of events. The date/time issue also impacts on the scheduling which must be done as at UTC 0000 to get the right timing for the schedule.

When an Error is not!

If we get over the date / time stamp issue, the log reports an ERROR: as 2 errors when in fact it completed successfully!!!

If an FTP transfer attempt fails, an initial error is flagged with ERROR: and then a 2nd (and a third) attempt will be made for the FTP transfer.

If that second transfer attempt is successful the job completes, but because of the first upload ERROR: condition existing the whole job is flagged as ERROR: Failed.

The crazy thing is that the last line ERROR: condition is also counted so that 2 errors are reported in the summary from a successful completion!

Arghhh… this of course wastes a heap of time checking what are in fact successful backups.

It works ! but…. it would be a whole lot easier and better if all the above had worked as expected.

Issue Summary

1. MainWP need to correct their process so that the sync is bi-directional.
2. MainWP need to correct the description of the allowed tags so that they are consistent with what BackWPUp actually uses.
3. MainWP must pass the ‘tagged’ version of the archive file name to the job and not do the conversion.
4. BackWPUp really should fix the date / time issue so that the logs and schedules are accurate and consistent with the WordPress site configuration so that they make sense.
5. BackWPUp should fix the ERROR reporting so that successful backups that may have contained one FTP transfer error but do complete successfully are not flagged as ERROR (twice)

Shellshock BASH Vulnerability: Debian, CentOS, Synology Busybox

Ok, so Heartbleed did as it said, and Shellshock is about to do the same.

I manage some CentOS, some Redhat, some Debian, and other servers. From what I have found so far, and assuming that the patches applied to the latest release of BASH are sufficient, then most servers and devices can be patched / fixed so that they are not vulnerable quite easily.

According to most sources, the test for a vulnerable BASH environment is the following line of code:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

So I quickly hit one of each server / Linux flavour I could think of and these are the results:

SME Server / CentOS based

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

so I ran

# yum update

which updates a number of tools including bash-3.2-33.el5.1.i386.rpm which appears to be the correct update version and re-testing after updating the server (includes other updates as well) gives the ‘not vulnerable’ response.

CPanel on CentOS

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
#

which appears to tell me that it is not vulnerable.

I also had a similar message but without the warning from a second CPanel / CentOS server which is configured slightly differently:

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
#

The lack of a warning in the above appears to indicate that it is not vulnerable.

Debian

Some of my Debian servers have not been upgraded from stable Squeeze, which I should be updating to Wheezy. I found different responses depending on which version of Debian existed on the server.

To check the Debian version use:

# cat /etc/debian_version
# 6.0.6

Checking the Debian version just as a confirmation of what patch release the server is using.

Debian Squeeze 6.0.6

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
#

Vulnerable, so update BASH

# apt-get update
# apt-get install bash

A second test shows:

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
#

<h2>Debian Squeeze 6.0.10</h2>

This one is a work in progress......


<h2>Debian Squeeze 7.4</h2>

This version of Debian was straightforward and 


# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
#

Oops!

# apt-get update
# apt-get install bash

A second test shows:

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
#

<h2>Synology Busybox</h2>

Synology Busybox uses ASH not BASH but testing can still be done


# env x='() { :;}; echo vulnerable' ash -c "echo this is a test" 

Gave an all clear message on my recently updated Synology unit.