My Wordpress Theme Hell!
A long-standing client I hadn't dealt with for a while rang up: "Help," he begged, "My IT Director paid a Wordpress Developer to write us a bespoke Theme!"
"Good grief!" I replied, "How bad is it, man?"
"It's been three months since we fell out with him and now we can't update the site and half the text is missing.."
"Okay, just keep calm, it'll be fine. Send me the login and the FTP."
As no-one had given the client the admin password for the site, I had to login to the database and manually change it to gain access. It transpired that some unruly CSS had turned the text in various areas of the site white, rendering it invisible. That was the easy bit and at least got the site visibly working again. The back-end was a different story though..
The custom Theme had been set up to overwrite certain Wordpress functions to display a Portfolio but a newer Wordpress version was no longer keen on doing things that way and stalled every time someone tried to edit the site.
I had to flush out the error, remove the offending code, then find an alternative method of displaying the Portfolio. This was actually successful but we all knew the site was on borrowed time.
"Rebuild using a well-known commercial Theme disguised to resemble the bespoke layout?" asked the client eventually.
"You took the words right out of my mouth," I quoted pithily in return.
Problems with Legacy Development?
Consult the King of Debug for help!
Invasion of the Weird Ads
Rogue adverts for vacuum cleaners (no, I'm not making this up) had suddenly appeared at the bottom of every page in a client's Wordpress website. They had their own cPanel hosting so I had to wait to be given access - hopefully before a GoogleBot noticed and labelled the site as dodgy..
On inspection it turned out that a hidden file had installed an official Wordpress plugin from Russia used to set up backlink networks. I deleted this 'sape.ru' plugin, cleaned up the installation, increased the site security and added live monitoring - just in case. Client bailed out, job well done.
A month later, after an unusual activity alert, I went into the site dashboard and discovered the plugin was back! The only good news was that our increased security had stopped it activating and no weird adverts had appeared.
The bad news was that it needed another clean-up operation, though..
Looking through the server logs it seemed that a Wordpress user was logging in from a malware-infected computer and re-infecting the site whenever they uploaded anything. I deleted every Wordpress user account except for the main admin and passed the details on to the client to sort out.
Nasties all over your site?
Stamp them out with the King of Debug!
Form Has No Function
"The forms have stopped working on the website," the client complained.
This was unusual, as the site was hosted on our own Plesk server, but can it happen. I took a look; nothing obvious had been changed since it was working correctly.
On firing the form, the tests all behaved as it should and I quickly received a copy. "Nothing here," said the client.
I reconfigured the form and sent a copy to a Gmail address. It arrived without a problem. "Didn't get a copy." said the client.
I took a delve into the mail logs and had a good dig.
And there it was: "550 Message from (theclient).com failed sender's DMARC policy, REJECT".
So I went and had a look at an online DMARC record analyser:
And there it was: "v=DMARC1; p=reject; pct=100; rua=mailto:rua@theclient.com,mailto:etcetc@e-shot.net". The client's IT department had quietly altered their DNS DMARC record without telling anyone and it wouldn't let the server send anymore.
So I told the client to ask if their IT department would change the p=reject or add our webserver's IP to the spf, but they refused saying "a business shouldn't use its main domain name for marketing"..
Well who could argue with that?!!. In the end we compromised and used a different domain entirely to email from the forms.
Code all broken?
Get it fixed by the King of Debug!
You Can't Be In My Group
The client had a brand-new logo, an idea of a Group website and a number of legacy sites.
"Explain the hierarchy, please," I asked in the briefing
"Caribsave is our original project, Intasave is the main project name, Intasave Africa will be a new project and we have Intasave China which will become Intasave Asia-Pacific."
"Ah, OK," I ventured tentatively, "And the new Group?".
"The new Group will be named The Intasave Caribsave Group and Caribsave will become Caribsave: Intasave Caribbean.."
"Well I can see how you got here," I explained carefully, "but are you really sure it's where you want to be?"
I definitely wasn't going to start building anything until a diagram could be produced that could be signed off but I also knew that the very act of drawing this structure would lay bare the antagonistic relationships within the group.
Strong personalities served up with plenty of internecine politics meant that it would be a long and tortuous journey to get everyone happy with a final result.
After much redrawing we ended up creating one group domain - intasave.org - and three subdomains based simply on location: africa.intasave.org, caribbean.intasave.org and asia.intasave.org.:
So in the end, the site structure illustrated the story of the organisation in a much clearer way than the actual identities of the Group members
Site journey all confused?
Seek direction from the King of Debug!
The Email's Dead, Jim(do)
A client referral emailed desperately, saying, "Our website is currently on Jimdo and the domain is held by 123-reg. Every time we try to get the website to go live we lose our emails!"
The problem in a nutshell turned out to be:
Their new website was at thisclient.jimdosite.com.
The thisclient.com domain was held at 123-reg.
Their IT guy had followed the Jimdo instructions to point thisclient.com to Jimdo and it immediately knocked out the emails, so he had had to revert. On the Jimdo dashboard it says the domain is 'pending'.
The 123-reg problem was "Warning: If you have an @ record set to a CNAME, all other @ records (including MX) will be ignored and set to the same domain to which it points." Ah, there's the rub.
It also fitted badly with.the Jimdo problem: "We do not support forwarding via A-Record." Drat.
Now I knew that this problem had been resolved on other DNS providers by the use of an ALIAS record, which is basically a CNAME record for apex domains that lets you keep your MX records. Unfortunately 123-reg don't let you create them on the control panels. Double drat.
So what to do?
A/ - switch to a DNS provider with the ability to configure ALIAS records (you get to keep email and Jimdo)
B/ - only use a subdomain (such as "www.thisclient.com") on the Jimdo site, set the A record to 123-reg, then create a 301 forward to www.thisclient.com.
C/ - sack Jimdo and start again basically
The client wouldn't switch registrars and didn't want to lose the work done on the Jimdo site so Option B turned out to be a perfectly equitable solution. Phew.
DNS records in a twist?
untangle them with the King of Debug!