For opengraph and similar social sharing protocols, you’ll want to include graphics with your post and pages whenever possible for blatantly obvious reasons. Often these images are scraped from the webpage and made selectable by the share’r, which is why you’re able to specify which image you’d like to show when shared.
Sometimes (and with some WordPress setups) it’s hard to say whether the post will have a featured image, an inline image, an attached image, a gallery of images, or none at all. Furthermore, some featured images are on the webpage but shown with CSS instead of scrap-able <img alt=“” /> tags.
For that problem, I wrote this solution:
Where logo.png is your fallback image, if your post/page has nothing else. You can change the order of the if/else conditions to prioritize what you’d like (i.e. attached images to be found before inline images).
Pro tip of the day: Need more images on your text-heavy blog? unsplash.com.
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).
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.