WordPress website maintenance & support
in Dubai

A maintenance plan starts with a question that sounds trivial. When is the site quietest? For a site whose visitors and editors live in the UAE, the answer moved in 2022. The national government switched to a Saturday and Sunday weekend, and many private employers followed. A schedule written for the old Friday and Saturday weekend may now run updates while offices are busy.

Friday deserves its own line in the plan. Government offices work a shorter day, and many businesses slow down around midday prayers. Traffic on a business site often reflects that. Check the analytics before choosing a slot.

Ramadan changes the day more than anything else in the calendar. Working hours in the private sector are shorter by law, offices close early, and activity shifts late into the evening after iftar. Shops and delivery sites often peak close to midnight. An update slot that was safely quiet at eleven at night in other months can land in the middle of peak traffic.

So the month needs its own settings. Move routine plugin updates to the early morning, after suhoor and before the shortened working day begins. Freeze larger releases unless they are urgent. Make sure backups do not start during the evening peak, because a full database export on a busy shop slows every page.

Eid holidays add another wrinkle. Their dates follow the sighting of the new moon. The exact days off are confirmed only shortly before, and the Islamic calendar moves earlier against the Gregorian one each year, so last season is no guide.

A support contract should say what happens then. Who is on call if the site breaks on the first morning of Eid? Which changes are frozen in the week before? Campaign pages for Eid offers are usually built in advance. They need a final check once the date is announced. Countdown timers and scheduled posts trust whatever date was typed in.

Arabic versions of the site need the same care in every window. A right-to-left layout depends on the theme loading its mirrored styles, on the direction set for each language and on plugins that respect it. A routine update can quietly break any of those. A slider that ignores direction. A form with labels on the wrong side. A menu that opens off the screen.

Multilingual plugins are the most sensitive part. An update can reset string translations, change how the language switcher builds its links or alter the addresses of translated pages. Test each update on staging with real Arabic content, on a phone and on a desktop. English pages passing a check says little about their Arabic twins.

Write the calendar into the support agreement. Review it every year. UAE time has no daylight saving, so the offset stays stable for a support team in another time zone.

Every WordPress site runs on PHP, the language the server uses to build each page. PHP versions have a fixed life. Each release gets active support for a period, then security fixes only, then nothing. A site left on an old version keeps working. That is exactly why it gets forgotten.

The host usually raises the subject first. An email arrives saying an old version will be switched off on a certain date. Some hosts move sites across automatically. Others charge extra to keep the old one alive. Either way, the upgrade happens on their timetable unless the support plan gets ahead of it.

WordPress core tends to cope well with new PHP releases. The risk sits in plugins and in the theme. Code written long ago may call functions that were removed, rely on behaviour that is now an error, or pass values of the wrong type that older versions quietly accepted. The result ranges from a line in a log file to a blank white screen.

A sensible upgrade follows the same order each time. Copy the site to staging. Switch staging to the new version. Turn on error logging and read the log, because many problems print deprecation notices long before they break anything. Then click through the pages that matter: checkout, forms, search, the member area and anything else that runs custom code.

Automated compatibility scanners help, within limits. They read code and flag known problems. What they cannot see are code paths that run only on a specific action, such as a monthly export, a payment callback or a scheduled import. Those need a person who knows what the site actually does.

Some findings have no easy fix. An abandoned plugin with no release for a long time is the usual culprit. The choice is then between replacing it, patching it inside a small custom plugin, or delaying the upgrade. Delay should come with a date. An unsupported PHP version stops receiving security fixes, and the host will not wait forever.

Speed is often a pleasant side effect. Newer PHP releases generally run WordPress faster and with less memory, so an upgrade can reduce server load without any other change. That is a good reason to schedule it. It is never a reason to rush it.

After the switch, keep the previous version available for a quick rollback for a few days if the host allows it. Watch the error log and the contact forms closely. Then record the new version in the support notes, along with any plugin that caused trouble, so the next upgrade starts from knowledge instead of guesswork.

Many WordPress sites depend on paid plugins. A form builder, a page builder, a backup tool, a shop extension. Each comes with a licence key, and the key is what delivers updates. When a licence lapses, the plugin usually keeps running. It simply stops receiving new versions, security fixes included.

That silent failure is the problem. Nothing on the site looks wrong. The update screen may show nothing pending, because the plugin can no longer see that a newer release exists. Months later a vulnerability is published, and the site runs a version nobody can update without first sorting out the payment.

Support starts with an inventory. List every premium plugin and theme with its vendor, the account that bought it, the renewal date, the price and what the licence covers. Some licences are per site, some cover a set number of installs, some include staging and some do not. Note what stops when a licence ends, since a few vendors switch off paid features as well as updates.

Ownership matters more than it seems. Licences bought by a former developer on a personal card sit in an account the business cannot reach. When that person moves on, renewals fail and nobody sees the reminder. Move each licence into an account the business controls, with a shared billing mailbox instead of a personal address.

Nulled plugins deserve a flat rule. These are copies of premium plugins passed around for free with the licence check removed. They are a common way malware reaches WordPress sites, and they never update. If an audit finds one, replace it with a licensed copy or an alternative the same week.

Renewal dates are also a good moment to ask questions. Does the site still use this plugin? Has a core feature taken over its job? Do two paid tools now overlap? Paying for another period by default keeps code on the site that nobody would choose today.

Lifetime licences need a note of their own. They look cheap. Vendors get sold, change terms or close, and a lifetime deal lasts only as long as the company behind it. Keep a copy of the terms at purchase and watch the changelog for signs of neglect.

Finally, put every renewal into one shared calendar with a named person beside it. Nobody should learn about a lapsed licence from a failed update.