This is the first lesson in the WordPress Theme Development Course. In this video we cover how to set up a local development environment for WordPress using Local by Flywheel.
If you already have a local development environment set up that you like (using Vagrant, MAMP, Valet, or something else), feel free to skip to the next video. There’s nothing in this series that requires you to use a specific development environment set up. Continue reading
I just started work on video course for learning WordPress theme development. It’s designed for folks who are familiar with using WordPress and would like to start building themes professionally (for clients or for their own work). The plan is to release the entire video series for free.
Since the focus is on professional development, I’ll be covering developer tools as much as actual theme development. Introducing topics like local environments, version control and build tools all together as it relates to WordPress themes will (I think!) be really useful for new developers getting up to speed.
If you or a friend has been looking to move into WordPress theme development, get on the mailing list and I’ll let you know when the first video is available.
If you want to make a few design tweaks to a WordPress theme (and don’t see an option for it in the Customizer), you’ll likely need to use some custom CSS. Thankfully, WordPress has a great built-in Custom CSS module that allows you to safely add CSS code or override existing styles. This gives you almost unlimited design control over a site!
This video explains how to find the selectors in your theme using the Chrome developer tools and then add your own custom styles in WordPress.
A few times I’ve gotten into a situation where I have access to WordPress files (via SFTP or other means) but I’m otherwise locked out of the site (my user hasn’t been created or was accidentally deleted). In those cases, the quickest option is generally just to create a new admin user with code.
If I know which theme is active, I’ll generally just drop this code into the bottom of functions.php for that theme, refresh the site once or twice in the browser, and then delete the code (important: make sure to delete it!)
| <?php | |
| add_action( 'init', function () { | |
| $username = 'admin'; | |
| $password = 'password'; | |
| $email_address = 'webmaster@mydomain.com'; | |
| if ( ! username_exists( $username ) ) { | |
| $user_id = wp_create_user( $username, $password, $email_address ); | |
| $user = new WP_User( $user_id ); | |
| $user->set_role( 'administrator' ); | |
| } | |
| } ); |
I’ve been working with a “Trial Product” in a WooCommerce store which needs to be the only item in the cart during checkout due to shipping requirements (and because it doesn’t make sense to order a trial if you’re also going to order the actual product).
To make this clear to the customer, I’ve restricted what can be added to the cart in specific situations:
1) If the “Trial Product” is already in the cart, additional products should not be added. WooCommerce will instead display a notice asking the customer to remove the “Trial Product” from their cart if they wish to add different products.
2) If products are already in the cart, and the customer attempts to add the “Trial Product”, a notice will display asking the customer to remove the other items from their cart first. Continue reading
Ever since Medium popularized the concept of the read times on articles, I’ve been seeing it as a design element in more WordPress projects.
Getting a great estimate for average read time is complicated, but if you just need a blunt tool for calculating it, you can use:
amount of words in the post / average reading speed
According to Medium, people read about 275 words per minute. Medium also adds 12 seconds for each inline image, but I didn’t get that fancy.
Here’s the snippet:
| <?php | |
| /** | |
| * Estimates the reading time for a given piece of $content. | |
| * | |
| * @param string $content Content to calculate read time for. | |
| * @param int $wpm Estimated words per minute of reader. | |
| * | |
| * @returns int $time Esimated reading time. | |
| */ | |
| function prefix_estimated_reading_time( $content = '', $wpm = 300 ) { | |
| $clean_content = strip_shortcodes( $content ); | |
| $clean_content = strip_tags( $clean_content ); | |
| $word_count = str_word_count( $clean_content ); | |
| $time = ceil( $word_count / $wpm ); | |
| return $time; | |
| } |
To output the read time in your post, use something like this:
| <div class="reading-time"> | |
| <?php echo prefix_estimated_reading_time( get_the_content() ); ?> min read | |
| </div> |
If you prefer to use a plugin, there’s a few around. This snippet is mostly borrowed code from Reading Time WP, which is also on GitHub.
When you’re developing a WordPress site locally or testing in staging, you’ll generally want to prevent the site from sending out emails to customers or users.
I’ve noticed that a number of other WordPress developers are fans of MailHog (great write up by Jonathan Christopher), but in many cases it’s easier if you don’t have to install anything additional on the server.
I use two plugins to block and then log emails:
“Disable Emails” prevents the emails from sending from WordPress, and “Email Log” is able to capture their contents in case you need to view them.
Since I sync my production environment to staging and local quite frequently, I have a script in my theme that activates these plugins when it detects the new environment.
There are a lot of good reasons to require a customer account on checkout:
However, the checkout process for first time customers should still be as seamless as possible. This is why I like to create accounts automatically if the email hasn’t been used before. WooCommerce has this functionality built-in. Continue reading