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 mappedWordPress 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.
Change the network domain name in wp-config.php:
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.
For anything external, write a redirect in your .htaccess file. The 301 will fix these links overtime for indexing on Google etc.
I recommend holding onto the old domain as long as possible (to preserve these external urls, maintaining SEO ratings).
I used the following below to create a widget in Panic’s Status Board.
To start, we’ll need to configure top to show more than one core. To setup top to reveal all CPU’s by default, login w/ ssh to your server and run the following:
1 reveals all cores. shift+W saves the current screen as default. Exit top once complete w/ $ cntl+C.
Next we’ll add a cronjob to make top output to a text file every minute. Launch the crontab editor
add at the bottom:
Where ‘/…/’ is a real path to somewhere on your server. I recommend keeping it 1-below your public /httpdocs/ directory so the world can access it but your scripts can. Then to save changes: ZZ. You can double check that it’s installed with crontab -l
should show your new addition. That’s it. Now every minute top will write to your top.txt file.
Now on to scripting.
We need to use some PHP to import and parse the top output data, and jQuery to reload the import/parse portions of the page for a continual update.
Make a php file, and add the following JS to the head:
Where http://…/this_file.php is the URI of your current file.
Where /var/www/…/top.txt is the path to your top output, and 16 is the number of cores you have on your server (if unsure, count them in the top.txt output). The “load time %” is a percentage out of 5 seconds. 0% being 0 load time, 100% being 5 second load time.
Once this is setup, done, and working you’ll now have a file that continually refreshes your servers output. From there you can use tools like gauge.js to animate some gauges, or create your own.
Say you have an element #banner with a background-image. On a responsive design that’s width:100%; you’ll notice your image will be auto croped by the viewport change. The solution is simple: background-size: cover; but a pain that follows is the height of the element will not scale down or up with the width change, leaving this weird empty vertical gap or a very cropped image.
Here’s a fix to figure out and change the height end_h based on the current window width, keeping background-image ratio making it responsive/scalable:
This resize happens when your script is loaded, as well as on any browser resize event.
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.