Category: #wordpress

There may be a variety of reasons for having to do this, despite how daunting it may seem, it’s actually not that big of a deal.

If we want to change oldnetworkname.com to newname.com on a domain mapped WordPress Network, we just have to modify a few settings in WordPress, all records manually in the database, and then write a rewrite for external links pointing to the old domain.

wp-config.php

Change the network domain name in wp-config.php:

PHP MyAdmin

There’s a few options here – it depends on the scale of your network, and how many plugins your networks site use that store information in serialized strings.

The main* records that will allow your network domain change are:

However beyond that, you will need to modify all instances of oldnetworkname.com in the database because when you change the main mapped domain, your domain mapping plugin will not modify the hard-coded urls anymore (i.e., in TinyMCE if you add a link, the link will be oldnetworkname.com/sitename/linkpage, on the front end, the domain mapper will change oldnetworkname.com/sitename to sitename.com). When switching primary domains, the detection of the old network url is lost, and must be fixed).

So instead of modify records individually, I’d recommend exporting the entire database, doing a find+replace of the domains (don’t bother with http:// or trailing /, as some records don’t include this, keep it simple, just the domain names) with a text editor, wipe the remote database, then importing the altered .sql file.

Note: I mentioned serialized strings because they may break when doing the find+replace because the string length of the domains. Please take extra care into making sure things like widgets are preserved.

.htaccess

For anything external, write a redirect in your .htaccess file. The 301 will fix these links overtime for indexing on Google etc.

Longevity

I recommend holding onto the old domain as long as possible (to preserve these external urls, maintaining SEO ratings).

Nothings worse then getting an email about someone being unable to upload a 6mb .PDF because it “exceeds the upload file size limit”

Here’s the fix – but important note: raising postmaxsize increases the possibility of DoS attacks on your server:

In functions.php add:

If that doesn’t work, it could be a apache restriction, in .htaccess add:

If you’re still unable to it could be a php restriction, in php.ini add:

Obviously change the 32mb/32000kb as needed.

Update:

The above worked for me 99% of the time, but I had once instance where I need to add the following into functions.php as well:

WordPress makes it super simple to run cronjobs.. To add one, just place the following code in your functions.php file and change the function/action prefix’s to your relevant plugin name/functions.

A little break down for those unfamiliar: the first action runs mypluginschedulecron() on each load. If your cronjob (myplugincronjob) is not registered, it‘s scheduled into WordPress’s cron and becomes a hook. Once it’s registered/schedualed with WordPress, the second action myplugincronjob is usable and runs your cronjob function (myplugincronfunction).

If you want your cronjob to occur less frequent than ‘daily‘, you need to add a additional timespan. Since what I’m writting this for has dynamic timespans, I’ve added several intervals for weekly, monthly, quaterly, biyearly, and yearly cronjobs:

If you’re uncertain if your cron function is working and want to test it, you can uncomment the third action and refresh the page (to run what WordPress cronjob will run on it’s intervals). If you’re uncertain if your cronjob is actually scheduled you can install Cron View, a plugin that displays the available schedules and the scheduled tasks.