This evening I was reading an article by Giles Fraser on The Guardian website and I was intrigued to understand how they coded the drop-cap at the top of the article:
I smiled when I saw, at the top of the HTML code, written in a comment in a combination of text and ASCII art:
At work yesterday I discovered that the localhost Apache web server on my PC wouldn’t start; it was running XAMPP.
Each time I tried to start Apache from the XAMPP control panel I got these error messages in the console:
08:59:34 [Apache] Attempting to start Apache app…
08:59:35 [Apache] Status change detected: running
08:59:35 [Apache] Status change detected: stopped
08:59:35 [Apache] Error: Apache shutdown unexpectedly.
08:59:35 [Apache] This may be due to a blocked port, missing dependencies,
08:59:35 [Apache] improper privileges, a crash, or a shutdown by another method.
08:59:35 [Apache] Press the Logs button to view error logs and check
08:59:35 [Apache] the Windows Event Viewer for more clues
08:59:35 [Apache] If you need more help, copy and post this
08:59:35 [Apache] entire log window on the forums
Reinstalling XAMPP didn’t fix the issue. But this did, spotted on the ever-wonderful Stackoverflow:
Press Windows + R to bring up the Windows Run… dialog.
Type services.msc and click OK.
Scroll down the list of services to find World Wide Web Publishing Service.
Right-click it and select Properties.
Change the Startup type to Manual.
Click Stop and wait for the service to stop.
That fixed it. Now Apache is running, as evidenced by the green light on the XAMPP control panel:
A couple of weeks ago I was setting up a new laptop and kept putting off installing Sublime Text (my code editor of choice) because I knew that it would also involve about fifteen minutes patiently working through my curated list of packages (add-ons / plugins), installing each one by one.
There’s got to be a simpler way, I suddenly thought. Sublime Text saves me so much time doing other stuff automatically, surely they’ve thought about this too.
Over the last few months in the evenings and at weekends, I’ve been working on redesigning the Pittenweem Properties website for friends here in Anstruther. The site launched a couple of weeks ago.
Pittenweem Properties offers high-quality self-catered holiday accommodation and property management services in and around Pittenweem. They currently manage properties in Carnbee just outside Anstruther and Pittenweem. But their portfolio is growing and for good reason — the properties they own and manage are to a very high standard and in a beautiful part of Scotland: the East Neuk of Fife.
I’m currently building a website for a friend of Jane, using the Divi theme from Elegant Themes. The website is for a holiday property letting company. This post explains how I changed the built-in Projects content type to Properties, and how you can change it to anything you want.
Divi is a great theme to use: it’s very flexible, it’s responsive (so it works equally well on smartphones as well as huge desktop monitors), and it has the easiest, drag-and-drop editor that I’ve ever used for WordPress.
Divi comes with a built in content type called Projects; WordPress calls them ‘custom post types’. I use this content type on my own website to list the various projects that I’ve been involved in over the years.
As you can see from the WordPress admin menu ‘Projects’ appears on the list beneath Posts, Media, Pages, and Comments:
Divi also ships with a number of attractive ways to display your projects using its Portfolio and Filtered Portfolio modules. You can even display these full-width or as a grid, such as this:
These are exactly the features that I’d like to use on the property letting website:
Keep properties separate from pages and posts, using a custom post type.
Display all properties in a grid.
Allow users to filter properties based on the categories that are assigned to them.
So, I want all the features of Divi’s built-in Projects custom post type, but I don’t want them to be called Projects. I want them to be called Properties.
Use a child theme
First, I strongly recommend that you use a child theme when customising Divi (or indeed any other WordPress theme). A child theme inherits the functionality and styling of another theme, called the parent theme, and allows you to make local customisations to it which will not be overwritten when the theme updates.
I copied the code, added it to the functions.php file in my child theme, and set about editing it.
remove_action / add_action
In a nutshell the code from Elegant Tweaks does two things:
It defines a new function — called child_et_pb_register_posttypes() — that will redefine the characteristics of the Projects content type.
It removes the default Projects custom post type contained in Divi, and replaces it with our one in the child theme.
This last point, I believe, is simply to be tidy: rather than clumsily overwriting the existing ‘project’ custom post type it gracefully removes the old one, and creates a redefined version in its place.
In that Elegant Themes post the author was only concerned with changing the URL from /projects/ to /photos/. So in his example, the names used in the WordPress admin screens still referred to projects: Edit Project, Add New Project, etc. But I want to change these too.
In the code for a custom post type these are referred to as ‘labels’ and are defined in the $labels array. This is what my code looks like now:
As you can see, something I find useful is to list the elements alphabetically. Personally, I find it easier to work this way; your mileage may vary.
Obviously, if you are customising this for your own requirements simply edit this to reflect your needs.
Custom post type options
Next, we define the arguments to be passed to the register_post_type function. These define not only how the custom post type is used but also how it is displayed in the WordPress admin menu: where it sits and what icon it uses.
The most important option here, for our purpose of customising it, is the 'slug' key. You must set its value (in single quotes) to whatever you need it to be. In my case 'slug' => 'property'. I’ve highlighted this in the snippet below.
Just make sure you don’t set the slug to the same name as an existing page.
Menu icon and position
One useful new addition to the code provided by Elegant Tweaks are the options to set the menu icon and where it sits on the menu.
This tells WordPress to apply all of these options to the ‘project’ custom post type.
Because we are redefining this existing custom post type (by changing the URL, the menu labels, the menu icon and position) it means that everything else (the default project page layouts and portfolio modules) will work as expected without any further customization.
Categories and tags
The rest of the code I left untouched. This code defines the categories and tags to be used with the projects/properties custom post type.
How it looks now
Adding all the code (see below for the complete script) this is what my WordPress admin menu looks like:
That’s now working as I expect it. Job done.
Here is the full code that I have in my child theme’s functions.php file: