Tag: WordPress
Move WordPress posts with media files
I’m currently working on a website revamp for one of our clients and it’s a full redesign/restructure.
This means that almost everything will be changed, structure, pages, content, media files, etc. Only the articles will remain as they are and will be moved on to the new website.
At this point, I want to move all the articles from live site.com to the staging version that we created at staging.site.com.
Here are the steps that I took in order to move the posts and images correctly.
1. Export and import posts with WordPress Importer
The easiest thing you can do is use the WordPress Importer. Export the posts from the live site and import them into your staging version. Works like a charm.
Now that you did that you notice that there is an issue.
It will import your articles without the media files. All the media files in the articles will still point to your live site. So you’ll have images with src=”site.com/wp-content/uploads/2020/01/image.jpg”.
2. Move the media files via FTP or cPanel
You should move the media files to your new WordPress install. Do so by using FTP or directly cPanel if it’s on the same server.
The point is to move the whole uploads folder.
Don’t do it file by file, archive the folder on the server, move the archive via FTP and just unpack where you need it to be. It will save you a lot of time.
3. Search and replace the old URL in the articles
Get the Better Search Replace and run a Dry search first for your live address and see what it returns. In my example, it will be www.site.com.
Your goal is to make the images point to your current address. You will end-up running a search and replace after www.site.com and replace it with staging.site.com in my case.
Yours can be www.site.com and replace with www.newsite.com.
You’re only interested in replacing the main domain because the file structure for the media files will stay the same.
Once you’ve completed this successfully you will see the images from your posts are pointing to the new address on the current install.
Now you will stumble upon another issue: the media files are not displayed in your Media Library.
4. Add your images into the Media Library
For this step, you’re going to use a plugin called Moving Media Library.
Install this plugin on the first site (from where you want to export), export the JSON format file with this plugin, and import the file on the new site.
This will migrate all details related to images and make them available in your Media Library.
It will maintain:
- ID
- user ID
- Date and time
- Folder structure
- File name
- Dimensions
- Thumbnails
- Exif data
- Alternative Text
- Caption
- Description
- Comments
At this point, you’re done with your posts transfer and media files.
You should have all the media files in Media Library and also correctly linked in the posts.
There is an extra step that you can do.
5. Remove unused Media files
In my example, we’re doing a full revamp of the website. All things will be re-done and the content will change on pages, product pages, any other assets will be replaced.
By moving the whole uploads folder I also moved a lot of files that will not be used anymore on the new site.
I’m interested in keeping only the files that are attached to the blog posts.
Media Cleaner Pro is the tool you’ll want to use for this.
You can go with the free version, but the Pro has a few amazing features.
Once you run the Media Cleaner Pro you’ll be able to get rid of all the extra media files that are not related to articles.
To give you an example, I moved 3.6GB of media files. After I run Media Cleaner Pro and kept only those that are actually used, I ended-up with 0.9GB of media files.
Warning!
Make sure you have a backup before using the Media Cleaner Pro and that you also activate the Trash option in this plugin. Once those files will be deleted they are gone.
Store libraries locally
I have one example in mind that really annoyed me.
One of our clients needed some features really quick and I wasn’t around at that time to help with it. They got someone from UpWork to do the job and they did it, it worked as expected.
All good until the client mentioned that the loading time is quite high now. We started to look at the code and how it was created to find out that all the libraries were embedded from 3rd party CDNs/servers. Not even the minified versions, the full ones.
We ended up with OwlCarousel twice on the site (and now loaded everywhere), we ended up with Bootstrap twice and some other JS library being delivered from 3rd parties.
Keep libraries locally
My main focus here is the CDN libraries.
This is something that I noticed a lot in WordPress development projects. Mostly when it comes to someone working on an existing project.
Clients will come in and ask for improvement, or some feature to be added on their existing website. This means you need to deal with the code that someone else created, the folder/file structure, re-use some functions/scripts, etc.
This is tedious and it takes time, you just want to have that thing done and ship it. It’s totally understandable, but you also need to make your adjustment robust.
Linking the libraries in the <head> directly from a CDN or server is not a good practice.
It’s perfect for the development environment where you want to quickly test and see if it does the job and you don’t have to worry about adding the library into the compile process or enqueue it on a specific component.
But for the real-world, when you ship that solution, you should store that library locally in the folder of your project. If the project will use a CDN and that asset will be delivered from there, then perfect.
Do not rely on a 3rd party CDN or server to deliver your library.
Reasons
- It might get an update and break your production site (in most cases they are version controlled, but it can happen)
- It can get deleted at some point
- The CDN/server link my go down
- Multiple requests on page load
- Slowing the loading time
- Offers details on what libraries you’re using. Might be easy to target some exploits.
Build things that are durable, robust, and don’t need any external help to run.
How to easily create multiple Custom Taxonomies in WordPress?
The main point of this article is to show you how to create multiple Custom Taxonomies using a more easy and re-usable approach.
We’re going to create a file called custom-taxonomies.php and place it a folder called ‘config’ inside your theme.
In custom-taxonomies.php we’re going to create a class that will generate Custom Taxonomies. It will be called DM_Project_Custom_Taxonomy.
<?php
class DM_Project_Custom_Taxonomy {
} // End class
new DM_Project_Custom_Taxonomy;
In here we create 3 fuctions: a __construct, one to define the custom taxonomies and one that will register them.
<?php
class DM_Project_Custom_Taxonomy {
public function __construct() {
}
public function all_custom_taxonomies() {
}
private function dm_register_custom_taxonomy( $data ) {
}
} // End class
new DM_Project_Custom_Taxonomy;
In the all_custom_taxonomies function we define all the custom post types that we want to use and will pass that data into the dm_register_custom_taxonomy.
public function all_custom_taxonomies() {
$custom_taxonomies = [
[
'taxonomy_type' => 'custom_taxonomy',
'singular' => 'Custom Taxonomy',
'plural' => 'Custom Taxonomies',
'slug' => 'custom-taxonomy',
'custom_post_type' => 'post',
],
[
'taxonomy_type' => 'second_custom_taxonomy',
'singular' => 'Second Custom Taxonomy',
'plural' => 'Other Custom Taxonomies',
'slug' => 'second-custom-taxonomy',
'custom_post_type' => 'my_custom_taxonomy_type',
],
];
foreach ($custom_taxonomies as $key => $custom_taxonomy) {
$this -> dm_register_custom_taxonomy( $custom_taxonomy );
}
}
And the dm_register_custom_taxonomy will look like this
private function dm_register_custom_taxonomy( $data ) {
$singular = $data['singular'];
$plural = ( isset( $data['plural'] ) ) ? $data['plural'] : $data['singular'] . 's';
$custom_taxonomy = $data['taxonomy_type'];
$slug = $data['slug'];
$custom_post_type = $data['custom_post_type'];
$labels = array(
'name' => _x( $plural, 'post type general name', 'dm-artillerie-theme' ),
'singular_name' => _x( $singular, 'post type singular name', 'dm-artillerie-theme' ),
'menu_name' => _x( $plural, 'admin menu', 'dm-artillerie-theme' ),
'name_admin_bar' => _x( $singular, 'add new on admin bar', 'dm-artillerie-theme' ),
'add_new' => _x( 'Add New', $singular, 'dm-artillerie-theme' ),
'add_new_item' => __( 'Add New ' . $singular, 'dm-artillerie-theme' ),
'new_item' => __( 'New ' . $singular, 'dm-artillerie-theme' ),
'edit_item' => __( 'Edit ' . $singular, 'dm-artillerie-theme' ),
'view_item' => __( 'View ' . $singular, 'dm-artillerie-theme' ),
'all_items' => __( 'All ' . $plural, 'dm-artillerie-theme' ),
'search_items' => __( 'Search ' . $plural, 'dm-artillerie-theme' ),
'parent_item_colon' => __( 'Parent ' . $plural . ':', 'dm-artillerie-theme' ),
'not_found' => __( 'No ' . $plural . ' found.', 'dm-artillerie-theme' ),
'not_found_in_trash' => __( 'No ' . $plural . ' found in Trash.', 'dm-artillerie-theme' )
);
$args = array(
'labels' => $labels,
'description' => __( $singular .'.', 'dm-artillerie-theme' ),
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array( 'slug' => $slug ),
'capability_type' => 'post',
'has_archive' => false,
'hierarchical' => false,
'menu_position' => null,
'supports' => array( 'title', 'author', 'thumbnail', 'excerpt', 'comments' )
);
register_taxonomy( $custom_taxonomy, array($custom_post_type) , $args );
}
If you want to do a small adjustment you can also define a variable from ‘textdomain’. In my case that is ‘dm-artillerie-theme’ and it’s hardcoded in there.
Now in the __construct we make sure to init the all_post_types function
public function __construct() {
add_action( 'init', array( $this, 'all_custom_taxonomies' ) );
}
Your final code in the custom-taxonomies.php file should look like this:
<?php
class DM_Project_Custom_Taxonomy {
public function __construct() {
add_action( 'init', array( $this, 'all_custom_taxonomies' ) );
}
public function all_custom_taxonomies() {
$custom_taxonomies = [
[
'taxonomy_type' => 'custom_taxonomy',
'singular' => 'Custom Taxonomy',
'plural' => 'Custom Taxonomies',
'slug' => 'custom-taxonomy',
'custom_post_type' => 'post',
],
[
'taxonomy_type' => 'second_custom_taxonomy',
'singular' => 'Second Custom Taxonomy',
'plural' => 'Other Custom Taxonomies',
'slug' => 'second-custom-taxonomy',
'custom_post_type' => 'my_custom_post_type',
],
];
foreach ($custom_taxonomies as $key => $custom_taxonomy) {
$this -> dm_register_custom_taxonomy( $custom_taxonomy );
}
}
private function dm_register_custom_taxonomy( $data ) {
$singular = $data['singular'];
$plural = ( isset( $data['plural'] ) ) ? $data['plural'] : $data['singular'] . 's';
$custom_taxonomy = $data['taxonomy_type'];
$slug = $data['slug'];
$custom_post_type = $data['custom_post_type'];
$labels = array(
'name' => _x( $plural, 'post type general name', 'dm-artillerie-theme' ),
'singular_name' => _x( $singular, 'post type singular name', 'dm-artillerie-theme' ),
'menu_name' => _x( $plural, 'admin menu', 'dm-artillerie-theme' ),
'name_admin_bar' => _x( $singular, 'add new on admin bar', 'dm-artillerie-theme' ),
'add_new' => _x( 'Add New', $singular, 'dm-artillerie-theme' ),
'add_new_item' => __( 'Add New ' . $singular, 'dm-artillerie-theme' ),
'new_item' => __( 'New ' . $singular, 'dm-artillerie-theme' ),
'edit_item' => __( 'Edit ' . $singular, 'dm-artillerie-theme' ),
'view_item' => __( 'View ' . $singular, 'dm-artillerie-theme' ),
'all_items' => __( 'All ' . $plural, 'dm-artillerie-theme' ),
'search_items' => __( 'Search ' . $plural, 'dm-artillerie-theme' ),
'parent_item_colon' => __( 'Parent ' . $plural . ':', 'dm-artillerie-theme' ),
'not_found' => __( 'No ' . $plural . ' found.', 'dm-artillerie-theme' ),
'not_found_in_trash' => __( 'No ' . $plural . ' found in Trash.', 'dm-artillerie-theme' )
);
$args = array(
'labels' => $labels,
'description' => __( $singular .'.', 'dm-artillerie-theme' ),
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array( 'slug' => $slug ),
'capability_type' => 'post',
'has_archive' => false,
'hierarchical' => false,
'menu_position' => null,
'supports' => array( 'title', 'author', 'thumbnail', 'excerpt', 'comments' )
);
register_taxonomy( $custom_taxonomy, array($custom_post_type) , $args );
}
} // End class
new DM_Project_Custom_Taxonomy;
In functions.php add the PHP file that you just worked on:
require_once('config/custom-taxonomies.php');
Using this code you’ll be able to generate multiple custom taxonomies without having to repeat the code and easily assigning the post type.
This is also a very clean way of keeping your code and not putting everything in functions.php. Use separate files and just call them from function.php.
You can find a similar article on how to create multiple Custom Post Types with the same approach.
Stop Divi from overwriting your shortcode or element CSS rules
I ran into an issue while using Divi and it’s getting a bit annoying.
You might have clients that use Divi for their sites or maybe it’s your favorite way of creating pages. It’s a very powerful visual composer/builder and you can easily create pages without a lot of coding knowledge.
But it can come to a point where you need to display something more complex on the page, grab some specific data from somewhere, a certain type of element that Divi doesn’t have, etc. For that you create shortcodes and you add the shortcode into the page, et voilà: you have rendered whatever it was you needed on the page.
In Divi you’ll have to go an extra step because it will mess with all your CSS that comes with the shortcode.
Divi does this annoying thing where everything is wrapped in .et-db #et-boc and overwrites style added to <div> elements, <a> elements and others.
.et-db being added at the <body> level and #et-boc at the Divi container level, it will apply to all elements that are inside a Divi container.
This kind of forces you to use the Custom CSS from Divi or add CSS in the page, I hate doing that. It might be great and easy for a person that doesn’t understand code, but I don’t find it useful at all. Especially if you have created a global element like a shortcode and you want to be able to use it on different pages and don’t worry about how it renders because of the builder used on that page.
One way to deal with this is by using Sass or SCSS on your shortcode component. You will define your CSS rules for the component but also for the component when it has a parent, in this case the classes mentioned above.
The end result will look something like the code below, notice that we refer to a parent by using &. (you can learn more about the parent selector here)
.my-element-class {
/*add the proprieties in here;*/
}
.my-element-class {
.et-db #et-boc & {
@extend .my-class;
}
}
or you can do it like this
%my-element {
/*add the proprieties in here;*/
}
.my-element-class {
@extend %my-element;
.et-db #et-boc & {
@extend %my-element;
}
}
This way you will not duplicate your code in the SCSS file and you can keep everything clean in there, the shortcode style rendering correctly in Divi or used outside Divi.
I didn’t run into this particular issue when using WP Bakery for example. That’s one of the reasons I prefer it over Divi.
How do you set-up a WordPress Staging environment?
What is a staging environment?
It’s an exact copy of your production site but in an “offline” mode. And by “offline” I mean that it will not be accessible for users or search engines. Its purpose is to provide you with a playground in order to make adjustments/changes to the existing site without possibly breaking the live version in the process.
Why do you need a WordPress Staging environment?
The purpose of a staging environment is to make certain changes that you want to test before having them on the live version.
When it comes to small changes, adjusting the color in a CSS file or changing the submit button value, you can do it without creating a staging environment. You shouldn’t go through that process just for a small change, unless you have a very active site and you don’t want to take any kind of risk.
When should you create a staging environment?
- You are about to make major changes to the site and everything needs to be tested; A new theme is developed, a new custom plugin created, new 3rd party implementation and so on.
- You want to fix a bug and it needs a lot of testing and errors might appear on the front-end or certain workflows might get broken;
- There is an ongoing process of changes on the site and you always need a staging that will test new changes before having them sent to production. This might happen if you have long term projects/clients and it’s a great idea to have a pipeline in place staging to production.
How to create a WordPress staging environment?
There are 3 ways of creating a staging environment:
- using tools from your hosting provider
- using a plugin
- manually create a staging environment
No matter the option you choose, I recommend using a subdomain that is located in a different folder compared to the actual production site. If the staging version bursts on fire, you don’t want it touching the production site. This being said you can also have it on a different server, but you’ll want to have the same server configuration.
1. Using tools from your hosting provider
Hosting providers now offer tools to create staging environments on WordPress. WPEngine and Siteground have this staging feature available. I only worked with those, but I’m sure there are many others that do the same thing.
They let you create a staging on a subdomain and then push from that staging back to production when you’re done with the changes.
2. Using a plugin
My go-to plugin when it comes to migration is All in One Migration. It’s an amazing tool and it works perfectly. It’s good to know that this plugin doesn’t have an option to push from the staging to live once you’re done with the changes. You will have to create a copy and move it again through its interface.
On the downside, it’s not as fluid as you might like it.
Another plugin that does this and is created with the staging environment approach in mind is WP Staging. This will allow you to create a staging in a subfolder on your main site in a few moments and on the premium version you also have the option to push changes to the live version.
3. Manually creating a staging environment
This is the most complex way of creating a staging environment. You will have to do everything from creating the subdomain, moving the files, moving the DB, changing the address/path in the DB, etc. It’s not that pretty, but it’s also the one in which you have the most control.
Do the push to live manually
I recommend option #1 or #2, but without the push to live from the hosting provider tools or from the plugin. From my experience, those options are good if you have a stating environment, if you have an e-commerce, membership site or an active blog community, you don’t want to push from staging to live using those tools.
The fact that you can risk overwriting or losing transactions, articles, registration that happened between the 2 moments in time, is something that I wouldn’t take a chance on.
Use the tools from hosting providers and plugins to create a staging environment.
Do the file updates on production directly with a theme/plugin update, have a deploy bot maybe once you do a pull request into the master Github branch or via SFTP.
The WordPress option/settings that you’ve done on staging, you’ll pretty much have to replicate those by hand.
I know that easy staging set-up with push to live sounds good, but it doesn’t always work. Or at least it doesn’t work for every project.
To have in mind
- Remove any cache system on staging. If you have to do a lot of changes or work on a completely new component, the cache will become frustrating. You can activate it once you’ve finished and tested with it.
- Make sure crawlers can’t get to the staging version. Update the robots.txt and block all kinds of foreign access to the staging subdomain.
- Try to use a similar server configuration to what you have on production. Don’t have the staging environment on your own machine (localhost), because you want to test it against the real-world situations.
- Make sure you share the staging link with the client or tester. (you won’t be able to do this if you host it locally)
Things to check before going live with a WordPress site
You started the project, moved along through all the revision checkpoints, your client is happy and you’re ready to move it on a live environment with the proper domain, server, and so on.
Even if the project works well on your development environment, there are a few things you might want to look over before making it live and ready to be accessed by visitors and search engine bots.
Dynamically deliver assets
On long projects or because you want to do a quick test, there might be assets that are hardcoded in your project.
Some bits might need to be hardcoded, but be sure it’s dynamically made so when you change the domain it will still work.
An example from the top of my mind is when you add a background image in CSS with the URL from WP Media Library. You want to quickly test something, the image is in Media Library and you just add it in your CSS to test.
You forget about it and when you delete the dev version of the site you end up with broken content.
Search from your IDE in the project folder after the dev URL address to be sure nothing is left in there.
Server details
In most cases, this shouldn’t be an issue if you have a good hosting company.
- Check the PHP version on the server and what you need for everything to work properly
- Check if there is any kind of restriction on the number of requests and files that you can have
Basically do a full run of your functionalities on the new server just to be sure no surprises appear.
Clean any test data
You tested and tested the site for all the edge cases and now it’s ready to go live.
Make sure all the test data is removed when the site goes live. Sure, some data needs to stay in there (you might have standard pages or users that should be in there), but everything else should be removed and the database to be as clean as possible.
Content ready
If you cleaned the database and removed all the extra users, posts, pages, etc, now add in the content.
Be sure the right content is on the pages before making it live, or else you risk having search engine bots crawl on your site and index pages with “Lorem ipsum” text on them – this is not very professional.
Forms functionality
In most cases, contact forms are your way to get customers or feedback. This might not seem like such an important thing, but from your client’s point of view, forms not working means the site is not functional. If this part is broken and fails on sending the message, you and your client are losing business.
For example, in Contact Form 7 (or any other contact plugin) you might need to install an SMTP or else the emails will not go out.
Of course, not only contact forms, but any other ways of gathering the data should be tested on the live environment again.
Conversion rate is very important when you invest money in promoting the site or certain landing pages. Having the potential customer landing on the page but failing the conversion part, it’s just bad business.
Security
Always keep an eye on the security details. There is no need to explain how important this is regardless of how big or small your website is or if you have other users or just the administrator.
The most important and easy things to do:
- Change the default administrator user to something else. Usually, you get the standard “admin”, don’t stick with that.
- Change the password to something complex. I use the WordPress auto-generated password all the time, because it’s simple and helps me not having to create a password on the spot. Your client might want something that they can remember – suggest them to be a strong password (case sensitive, numbers, symbols, all that stuff).
- Change the default login URL for WordPress. The standard login address from WordPress can easily be targeted by bots. You should change the wp-login.php to something personalized. Don’t do this by hand (you altering the code), just use a plugin like WPS Hide Login.
- Install a security plugin. Wordfence should do the trick, it’s easy to use and it’s very popular.
A backup system in place
Periodical backups are a must: the files and database should be backed at least once a week. You can also go for twice per week, it really depends on the site and how much activity there is on it. If the content stays pretty much the same and there are no transactions happening, then you can set a longer period between backups.
A good option is UpdraftPlus – Backup/Restore. It’s one of the most used WordPress plugins and it does the job really well.
The hosting provider might also offer a backup system, use that too if you want to be sure nothing gets lost.
Make sure search engines can access the site
When you have the WP site (or any site) in development, the robots.txt is denying access for bots on your site. Or at least that’s the way it should be.
In WordPress, there is the option of Discourage Search Engines from crawling in Settings > Reading.
You should uncheck this after you cross all the points from above. Having the robots.txt still blocking search engines will make the site invisible for potential customers.
How to easily create multiple Custom Post Types in WordPress?
We’re going to create a more easy to manage the way of generating multiple Custom Post Types.
First of all, we’re going to create a file that we’ll call it post-types.php and place it in a folder inside your theme called ‘config’.
In post-types.php we’ll create a class that generates Custom Post Types. I’ll call it DM_Project_Post_Types.
<?php
class DM_Project_Post_Types {
} // End class
new DM_Project_Post_Types;
In here we create 3 fuctions: a __construct, one to define the custom post types and one that will register them.
<?php
class DM_Project_Post_Types {
public function __construct() {
}
public function all_post_types() {
}
private function dm_register_post_type() {
}
} // End class
new DM_Project_Post_Types;
In the all_post_types function we define all the custom post types that we want to use and will pass that data into the dm_register_post_types.
public function all_post_types() {
$post_types = [
[
'post_type' => 'director',
'singular' => 'Director',
'slug' => 'director',
],
[
'post_type' => 'photographer',
'singular' => 'Photographer',
'slug' => 'photographer',
],
];
foreach ($post_types as $key => $post_type) {
$this -> dm_register_post_type( $post_type );
}
}
If you need to add custom data for ‘plural’ or other arguments, you can add them in the all_post_types function and pass them in dm_register_post_type to be used.
And the dm_register_post_type will look like this
private function dm_register_post_type( $data ) {
$singular = $data['singular'];
$plural = ( isset( $data['plural'] ) ) ? $data['plural'] : $data['singular'] . 's';
$post_type = $data['post_type'];
$slug = $data['slug'];
$labels = array(
'name' => _x( $plural, 'post type general name', 'dm-artillerie-theme' ),
'singular_name' => _x( $singular, 'post type singular name', 'dm-artillerie-theme' ),
'menu_name' => _x( $plural, 'admin menu', 'dm-artillerie-theme' ),
'name_admin_bar' => _x( $singular, 'add new on admin bar', 'dm-artillerie-theme' ),
'add_new' => _x( 'Add New', $singular, 'dm-artillerie-theme' ),
'add_new_item' => __( 'Add New ' . $singular, 'dm-artillerie-theme' ),
'new_item' => __( 'New ' . $singular, 'dm-artillerie-theme' ),
'edit_item' => __( 'Edit ' . $singular, 'dm-artillerie-theme' ),
'view_item' => __( 'View ' . $singular, 'dm-artillerie-theme' ),
'all_items' => __( 'All ' . $plural, 'dm-artillerie-theme' ),
'search_items' => __( 'Search ' . $plural, 'dm-artillerie-theme' ),
'parent_item_colon' => __( 'Parent ' . $plural . ':', 'dm-artillerie-theme' ),
'not_found' => __( 'No ' . $plural . ' found.', 'dm-artillerie-theme' ),
'not_found_in_trash' => __( 'No ' . $plural . ' found in Trash.', 'dm-artillerie-theme' )
);
$args = array(
'labels' => $labels,
'description' => __( $singular .'.', 'dm-artillerie-theme' ),
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array( 'slug' => $slug ),
'capability_type' => 'post',
'has_archive' => false,
'hierarchical' => false,
'menu_position' => null,
'supports' => array( 'title', 'author', 'editor', 'thumbnail', 'excerpt', 'comments' )
);
register_post_type( $post_type, $args );
}
By default I added a $plural variable that will just add an ‘s’ at the end of the custom post type single in case you don’t define a plural in all_post_types.
If you want to do a small adjustment you can also define a variable from ‘textdomain’. In my case that is ‘dm-artillerie-theme’ and it’s hardcoded in there.
Now in the __construct we make sure to init the all_post_types function
public function __construct() {
add_action( 'init', array( $this, 'all_post_types' ) );
}
Your final code in the post-types.php file should look like this:
<?php
class DM_Project_Post_Types {
public function __construct() {
add_action( 'init', array( $this, 'all_post_types' ) );
}
public function all_post_types() {
$post_types = [
[
'post_type' => 'director',
'singular' => 'Director',
'slug' => 'director',
],
[
'post_type' => 'photographer',
'singular' => 'Photographer',
'slug' => 'photographer',
],
];
foreach ($post_types as $key => $post_type) {
$this -> dm_register_post_type( $post_type );
}
}
private function dm_register_post_type( $data ) {
$singular = $data['singular'];
$plural = ( isset( $data['plural'] ) ) ? $data['plural'] : $data['singular'] . 's';
$post_type = $data['post_type'];
$slug = $data['slug'];
$labels = array(
'name' => _x( $plural, 'post type general name', 'dm-artillerie-theme' ),
'singular_name' => _x( $singular, 'post type singular name', 'dm-artillerie-theme' ),
'menu_name' => _x( $plural, 'admin menu', 'dm-artillerie-theme' ),
'name_admin_bar' => _x( $singular, 'add new on admin bar', 'dm-artillerie-theme' ),
'add_new' => _x( 'Add New', $singular, 'dm-artillerie-theme' ),
'add_new_item' => __( 'Add New ' . $singular, 'dm-artillerie-theme' ),
'new_item' => __( 'New ' . $singular, 'dm-artillerie-theme' ),
'edit_item' => __( 'Edit ' . $singular, 'dm-artillerie-theme' ),
'view_item' => __( 'View ' . $singular, 'dm-artillerie-theme' ),
'all_items' => __( 'All ' . $plural, 'dm-artillerie-theme' ),
'search_items' => __( 'Search ' . $plural, 'dm-artillerie-theme' ),
'parent_item_colon' => __( 'Parent ' . $plural . ':', 'dm-artillerie-theme' ),
'not_found' => __( 'No ' . $plural . ' found.', 'dm-artillerie-theme' ),
'not_found_in_trash' => __( 'No ' . $plural . ' found in Trash.', 'dm-artillerie-theme' )
);
$args = array(
'labels' => $labels,
'description' => __( $singular .'.', 'dm-artillerie-theme' ),
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array( 'slug' => $slug ),
'capability_type' => 'post',
'has_archive' => false,
'hierarchical' => false,
'menu_position' => null,
'supports' => array( 'title', 'author', 'editor', 'thumbnail', 'excerpt', 'comments' )
);
register_post_type( $post_type, $args );
}
} // End class
new DM_Project_Post_Types;
Now in functions.php add the PHP file that you just worked on:
require_once('config/post-types.php');
You will be able to generate as many custom post types you want and control the aspect of each of them without repeating the code. You also endup with a clean functions.php file and it will be easier to read in the future.
You can use this approach on other customizations that you’re doing on the site, creating a separate PHP file and call them from inside functions.php.
You can find a similar article on how to create multiple Custom Taxonomies with the same approach.
WordPress speed optimization tips 2019 – part 2: Optimization tools
In the first article, we talked about test tools for your website. In this article, we’re going to continue and provide solutions for some of the most common issues when it comes to site speed/loading time.
Tools for WordPress speed optimization
1. Cache
There are a lot of plugins that will help you with cache in WordPress. I will go through some of my favorites.
WP Fastest Cache
It’s very simple to use. This is why I like it.
You install the plugin, activate it, enable cache, Gzip compression, Browser caching and you’re set.
Other features:
- it allows you to preload posts, pages, categories
- combine and minify for CSS, combine for JS
- minify HTML
More features are available on the paid version. I’m perfectly ok using the free version and it goes really well with Autoptimize if you want to handle minify and combine separately.
Hyper Cache
It has more or less the same features that you will find in any cache plugin. The main thing is that it has a double cache for desktop and mobile version. This is great!
If you end up using something like wp_is_mobile() in your code, you know that it won’t work correctly when cached. This plugin will solve that issue because it will render each page and cache it individually for mobile and desktop.
The plugin is very well optimized and uses only PHP to do the job and you will be able to use it on a hosting service with low resources.
Cache Enabler – WordPress Cache
This plugin has a different approach when it comes to caching the pages. It will create HTML static files for your pages and store them on the server. When your visitor access the page the server will deliver the static HTML and avoid any backend process that will require extra resources.
One reason to use this plugin is for the integration with “Optimus”.
“Optimus” it’s a plugin that will allow you to deliver .webp images into your pages and “Cache Enabler” will allow you to cache those pages. It will create 2 HTML files for each page: one with the standard images that you have and one with all images replaced to .webp.
Why does it need to do that? Because some browser will not read your .webp files and people will not see any images on those pages. This way “Cache Enabler” will deliver the correct cached version based on the visitor’s browser.
There are a lot of other cache plugins, but these are the top 3 most used by us.
Like any other thing, you might need to test with multiple cache plugins until you find the right one.
2. Minify/Combine
You will want to minify the CSS and JS files but also combine them into as few files as possible to get rid off those requests.
Some cache plugins already have this option (like WP Fastest Cache does), but I prefer to use a dedicated plugin for that.
Autoptimize
This is my to go plugin when it comes to minify and combine.
Some of the features:
- Optimize JS/CSS
- Aggregate JS/CSS files
- Exclude scripts/style files from Autoptimize. This is very useful because you’ll see that some functionalities might break and you want to remove those scripts from being combined. Same for style.
- Inline and Defer CSS. This will allow you to add “above the fold CSS” until the main optimized CSS is loaded. Is a great way to remove all request and provide some styling for the site until the actual resources are loaded. The content will start to be displayed without having to wait for the actual style file.
- Combine Google Fonts and load them asynchronously
- Remove query strings
This plugin works with every other cache plugin that I worked with. Just make sure you don’t have to minify and combine enabled on the cache plugin. Same for Divi themes. Divi themes will enable minify and combine by default, check if you want that or not.
3. Image Optimization
Smush Image from WPMU DEV
Very easy to use and it visually it looks very pleasing.
It’s a very good plugin all around, just 2 things that you need to know for the free version:
- it optimizes in batches of 50 files, so if you’re planning to optimize a lot of images you will need to click the button to continue the process after each 50 file.
- it has a limit of 1MB per file
reSmush.it Image Optimizer
Works great and it has a limit of 5MB per file. You can run the process for all the images, no limit on the batch.
Optimus – WordPress Image Optimizer
Apart from the image optimization, this plugin will allow you to deliver WebP images into your page.
It will generate .webp files automatically and will replace those from your page. You need to use it with the “Cache Enabler” plugin that I mentioned above to offer support for old browsers also.
You will need the HQ (paid) version for WebP image conversion.
Another notable mention: EWWW Image Optimizer. I run into issues with it on different servers and I stopped using it.
4. CDN
If you still don’t know what a CDN is, Cloudflare has a is a very comprehensive explanation for you.
Cloudflare
First of all, it’s free.
You get:
- SSL certificate. Note: This is a “Full” secure connection between your visitor and Cloudflare, and secure connection (but not authenticated) between Cloudflare and your web server. In order to have a “Full Strict”, you need an SSL certificate on your server also.
- Firewall
- Details about traffic and attacks
- Stats about performance and how much bandwidth Clouflare saved you
Cloudflare also has some tools for Auto Minify and Rocket Loder that will combine and minify your CSS and JS. I don’t recommend using them if you’re already doing this on the server side.
In a recent update, they added a similar feature to the delegation. You can add multiple users to your account. In case you have another developer that needs to work and have access to clear the cache or put the whole thing in developer mode, you can do that without sharing your login credentials.
Conclusion
Alongside with Part 1, these 2 articles will help you get started on optimizing your website.
Some aspect might change in the months/years to come, but these are very core and basic things that you will need regardless of the new tweaks added by Google to the algorithm.
WordPress speed optimization tips 2019 – part 1: Test tools
Starting from mid-2018 Google takes into account your site speed when ranking in for mobile search results. This should be enough for you to get started on optimizing your existing website.
Besides that, having a fast website (with a very quick loading time) will guarantee you more traffic, sales, and better bounce rate.
I will go through some tools that we use to test the websites that we’re working on and I will also mention some of my favorite solutions to fix the most important issues in part 2.
Tools to test your site speed
1. Google PageSpeed Insight
This might be the number one tool used for testing website speed and there is a good reason for that: it’s made by Google. You will notice that from time to time, the facts that are taken into account by PageSpeed Insight will change/adjust.
For example, right now you can’t get a break from “Lazy image loading” and “Using next-gen image format” that appears in the test results. Lazy loading is great and I will talk about it in part 2, you need to use this if you’re not doing it already. I will also talk in there about next-gen image format, so make sure to give it a read.
I do find the PageSpeed Insight a bit too aggressive when it comes to the mobile score and recommendations. For some of them, I feel like you need to strip the site or find a lot of different ways to deliver files in a way that it will please Google.
It provides you with enough details on how to fix most of the issues and also points to specific assets that need attention.
2. Chrome Audit
Very useful and comes with your Chrome browser or other Chromium-based browsers.
Using CTRL+SHIFT+I you can access the Inspector and from there you have an Audit tab that will allow you to run tests on the page you’re on.
You will get results for Performance, Progressive Web App, Best practices and Accessibility, so it’s nice that you have some extra things in there and you can go over all the details in the Audit results.
One thing to take into account: the tests are run from your machine.
If you’re using Bitdefender as an antivirus you will notice that all the assets on the site are delivered via HTTP/1.1 instead of 2.0. This will cause the Audit report to show you an issue that you are not delivering files using HTTP/2. Just deactivate the antivirus when you do that and it will work correctly. Make sure that your PC will not slow down the test or have another 3rd party that does that.
3. GTMetrix
I really like GTMetrix because it provides you with more specific details on your test runs. You will get details like file names, correct sizes for images, it will even provide the images already optimized for you if you’re too lazy to do it on your own.
- It shows you the score based on two tests: PageSpeed Score and YSlow
- It keeps a record of your site tests
- You get details if the score when up or down
- A nice waterfall that shows the loading times of assets and status during the loading
In some cases, I use the GTMetrix tool more than the other 2 from above.
4. WebPageTest
This is another tool that will get you in-depth details about your site speed/loading times and the best thing is that you can select location and browser on this one.
GTMetrix has a similar feature but it’s in the PRO version they sell.
WebPageTest is maintained on Github with around 130 contributors, they do have recent updates so you can use it without worries.
It has a lot of customizations in the Advanced section: a number of tests to run, capture video, connection type, disable JS, stop the test when document complete, emulate for mobile, etc. I never messed with the settings, just left it as it is and selected the location that I wanted and it worked very well.
5. Pingdom
I moved it to the last place because I feel like the free version doesn’t provide you with a lot of details. You have a very nice waterfall and you get a lot of information on what assets are loaded, how are they loaded, status, etc. but not that much info on the other issues.
You get details like “Compress components with gzip” or “Add Expires headers” but you never get the actual files that have this issue. I feel like it’s very vague and you can’t do debugging or improvement based only on these suggestions.
They do have a paid plan and on that paid plan you get a lot more details. I assume this is the reason and the selling point for the product. It’s fair enough. If you don’t want to purchase a tool like this, you can easily use one of the others from above.
Conclusion
You can use any of the tools above to test your site loading time/speed. The main thing that I can recommend is not sticking just to one tool.
If you’re using PageSpeed Insight on your daily basis, try mixing things up by having also GTMetrix and WebPageSpeed as your tools. You will get a better understanding of what might be wrong and how you can improve it.
In the next part, we’ll talk about WordPress speed optimization tools that you can use to solve some of the most common issues.
Most used WordPress plugins in our projects
As web developers, we like to create a lot of things from scratch. For different reasons: it will do exactly what you want it to do, you can put your name on something (this is always a nice feeling), and so on. Sometimes there is no need to reinvent the wheel. If a thing works don’t question it or change it. That’s why I’ll get on with a list of our most used WordPress plugins.
We noticed some plugins that we used frequently on our projects. They definitely help us make the final product better and also finish it faster (deadlines are always a pain in the ass). Continue reading “Most used WordPress plugins in our projects”