New: Group Mentorship for WordPress Developers and Agencies

Over the past few years I’ve been receiving a steady flow of incoming inquiries for mentorship, coaching, consulting and general assistance coming from WordPress freelancers, consultants, developers, agency owners and tech leads in WordPress agencies.

A technical presentation on WordPress Code Architecture at WordCamp Netherlands

Currently, I work with a small group of people who reach out once or twice a month and ask for strategic decisions, sales strategy, technical advice on building a reliable infrastructure, marketing help, getting involved with the WordPress community and so forth. Some of my peers are actively growing and I’m super stoked to see ongoing progress, reports on closing large clients, signing long-term retainers and improving their technical and business skills on the way.

More often than not, when I receive a random question or any of my peers asks for help with a specific problem, I’ve already discussed that in details over a podcast interview, a guest post for a major outlet, a technical talk or elsewhere online – including Quora as of the past few months.

As a result, I regularly have to postpone responses or simply reject mentorship requests due to practical reasons (a.k.a. lack of time).

Since I’m following some smart and experienced folks on Quora, I have bookmarked a couple of brilliant responses regarding mentorship and coaching opportunities. Here are the two nuggets by David S. Rose and Gordon Miller:

The essential paradox is that the very people you would want as mentors are exactly the same people who simply don’t have the time to serve in that role, because they’re doing the things that make them good mentors in the first place. Therefore, the best that we can do is try to figure out ways to ‘scale’ our mentoring so as to positively affect the largest number of potential mentees. That is why I spend probably half my time:

Answering questions here on Quora (nearly 6,000 of them)
Creating and publishing free videos (over 1,000,000 views)
Speaking at conferences and panels (dozens of them each year)
Doing TEDtalks (at TED itself, and in half a dozen TEDx events)
Judging business plan competitions (dozens of them each year)
Running online webinars (for NASVF/NCET2, New York Angels, etc.)
Running in-person open training sessions (NYA Educational Meetup)
Teaching at colleges and business schools (Yale, Harvard, NYU, Columbia, Stevens, Rutgers, Carnegie Mellon, IESI, etc.)
Founding and teaching at an entrepreneurship program (Singularity U)
Founding and running a tech accelerator program (AREA)
Doing group events like StartUp Grind, FreeLunchFridays, and others
Writing two New York Times best selling textbooks, one on angel investing and the other on starting a company.
Blogging, tweeting and commenting on others’ blogs

David S. Rose on Quora

 

I have learned over the years that my time is more valuable than money. The only reason that people work for a living is that the money they get paid is enough for them to justify the time they spend doing the work. And that is great if you are an employee. But when you are an entrepreneur, there is the “opportunity cost” to be considered and the “time value of money”.

For example, If I were to meet with the over 100 people that have asked me to mentor them, and even if I only spent 30 minutes a week with each of them, then that is 50 hours a week. That is 125% of the time that I have to work on new opportunities. It might help the 100 of you, but it doesn’t help me or any of my other existing businesses.

Gordon Miller on Quora

Other entrepreneurs and consultants receive mentorship inquiries as well and can’t handle each and every ask for help. Most of them also retract these to a side medium – their blog, videos of talks they have presented, or books they have written.

With that in mind, I’m starting an experimental “group mentorship” program for developers and agency owners as well. The format would be an email newsletter 2-4 times a month including tips and strategies from me and relevant links to publications I’ve written online, interviews suitable for the audience, and other helpful resources that I stumble upon over the month.

Here are some of the main topics and goals that would be targeted in my emails:

  • How to improve your skills and provide professional development services to your customers
  • What strategies do other communities employ in technical architecture and business development
  • How to structure the sales and planning processes and ensure financial stability
  • What marketing strategies are instrumental in building trust and reputability
  • How to develop a unique business model that resonates with your customers and positions you in the top charts
  • What challenges do enterprises and large businesses face while looking for a professional team or consultant for their large project
  • How to explain problems in a way that is related to the business implications

My friend Marius has suggested a Q&A panel once a month or so. That sounds reasonable and given the right volume, I can send a monthly email answering some of the general questions that most freelancers, consultants, and agency owners struggle with.

The main target group is WordPress professionals providing development and other relevant services to their business peers. Building high-quality solutions is absolutely mandatory so keep that in mind before enrolling in the experimental email mentorship program.

If you have any questions regarding the program, don’t hesitate to reach out in the comments area or via email.

The post New: Group Mentorship for WordPress Developers and Agencies appeared first on Mario Peshev on WordPress Development.

Reminder: Google Hates Widget Links

In a blog post last year, Google reminded users that widgets are cool, but widget links are the suxxor.

Widgets can help website owners enrich the experience of their site and engage users. However, some widgets add links to a site that a webmaster did not editorially place and contain anchor text that the webmaster does not control. Because these links are not naturally placed, they’re considered a violation of Google Webmaster Guidelines.

If you look at the examples, they highlight things that many plugin (and theme) developers would consider acceptable links.

What does this mean for you? It means your powered-by link may adversely impact your users. Be smart. Make your links no-follow.

Also as a reminder: Any and all powered-by links and credits must be opt-in. That is a site owner must make the conscious and informed decision to display your credits. You cannot have them show by default, you cannot have them be opt-out, and you cannot hide them in display:none code or any other way that embeds a clickable link. Code comments like <!-- Powered by WordPress --> is fine.

WordPress 4.8 Will End Support for Internet Explorer Versions 8, 9, and 10

Over the weekend, Matt Mullenweg announced that the upcoming WordPress 4.8 release will drop support for IE versions 8, 9, and 10. Core contributors have been discussing browser support for the past two months in relationship to setting technical requirements for the new editor.

Microsoft discontinued support for IE 8, 9, and 10 in January 2016, which means these versions no longer receive security updates. Mullenweg said that attempting to continue supporting these browsers is holding back WordPress development.

“I realize that folks still running these browsers are probably stuck with them because of something out of their control, like being at a library or something,” Mullenweg said. “Depending on how you count it, those browsers combined are either around 3% or under 1% of total users, but either way they’ve fallen below the threshold where it’s helpful for WordPress to continue testing and developing against.”

In an effort to determine how many people are still using these insecure and obsolete browsers, Jonathan Desrosiers collected data from three different sources. The following are numbers for global IE usage published by StatCounter’s GlobalStats, which Desrosiers said are nearly identical to WordPress.com’s numbers:

  • IE8: 0.41%
  • IE9: 0.26%
  • IE10: 0.26%
  • IE11: 3.79%

WordPress will not stop working entirely in these browsers, but after the 4.8 release contributors will no longer test new features against older versions of IE. Some capabilities in wp-admin may be more limited. Mullenweg confirmed that the next versions of TinyMCE will no support older IE versions.

Global IE usage has declined from 7.44% in March 2016 to 4.18% in March 2017. IE marketshare has been shrinking as mobile device usage has gone up. October 2016 marked the first month in history that mobile and tablet traffic exceeded desktop usage worldwide. As this trend of declining desktop usage continues, IE will likely be buried within a couple of years.

“I have been hard pressed to find a U.S. government agency running a version of IE less than 11,” WordPress lead developer Andrew Nacin commented on the announcement. “Government agency websites similarly see negligible traffic from IE < 11.”

The decision to drop support for IE 8, 9, and 10 was met with celebration from the WordPress developer community. Focusing on browsers that still receive security updates is a better use of open source contributors’ time and resources. Developers who do client work can also refer to WordPress’ IE support policy when pressured by clients to support insecure browsers.

Naturally, the topic of raising minimum browser requirements resulted in developers lobbying to drop support for PHP 5.2, which reached end of life more than six years ago. In March 2015, WordPress stats estimated PHP 5.2 usage at 16.6%, but that number has dropped steadily to 5.1% today. The task of updating a browser to the latest version was designed to be easy for users, but upgrading PHP versions is still somewhat complicated for those who are not receiving help from their hosting companies. The 5.1% on PHP 5.2 represents millions of users who would need to cross a significant hurdle into order to stay current with the latest version of WordPress.

New Plugin Offers Better Plugin Recommendations in the WordPress Admin

If you work with WordPress every day you may have learned to tune out the recommended plugins in the admin by now, but the “Add Plugins” screen is an important part of the new user experience. WordPress developers Joey Kudish and Nick Hamze have released a plugin that brings better recommendations to the admin.

Hamze contends that the first plugins that appear in the featured section have a smaller, niche audience, and are unlikely to be useful to the majority of new users.

The recommended plugins are slightly better, as they are based on plugins that the user and other users have installed. However, Hamze believes they could be tweaked even further to display plugins that specifically benefit new users. The Recommended tab was introduced two years ago to display results based on plugins that are commonly used together. It excludes plugins that users already have installed.

“I really want to help WordPress but I think what is most needed isn’t a new editor or more guidelines but rather someone to take all the stuff in this fractured ecosystem and bring it together,” Hamze said. “Get rid of all the crap and only show people the stuff worth using.”

Hamze said he doesn’t know if WordPress can solve this problem diplomatically with code. He believes manual curation is required to deliver the best new user experience. A ticket for re-thinking the default ‘Add Plugins’ tabs/filters was is open on WordPress trac, as the plugins that appear in these screens have remained unchanged for some time. The ticket hasn’t received much discussion yet.

The Better Plugin Recommendations plugin removes the default and featured recommendations tabs and includes a new recommendations tab curated by Hamze to appeal to new users. Below is an example of the first 10 recommendations the plugin includes:

Hamze uses the following criteria to select the recommended plugins:

  • Price (Free)
  • Numbers of users
  • Average Rating
  • Last Updated
  • Support Given

When asked why the recommendations don’t include Jetpack, Hamze said it didn’t seem necessary, given its high position in the popular tab and the fact that it already comes pre-installed with many hosts.

Hamze and Kudish created a web service that delivers the recommendations to sites where the plugin is installed. The node server is powered by hapi.js and is open source on GitHub

“If the idea is well received in the community, I’d love to expand on it further and include some plugins from outside the WordPress.org plugin repository in our recommendations, as I think there’s some great third-party plugins that new users should definitely know about,” collaborator Joey Kudish said.

Hamze said he doesn’t expect there to be many regular users who will find and install the plugin but hopes that hosting companies will integrate it by default for their WordPress customers.

“What I’m hoping is that I can convince the hosting companies to preinstall this (maybe in the MU folder) for their customers,” Hamze said. “The app blends in seamlessly with WordPress. There are no ads or branding. The plugin is designed solely to help new users find great plugins to help them on their WordPress journey.”

WordPress 4.7.4 Fixes 47 Issues

WordPress 4.7.4 is available and is a maintenance release that fixes 47 issues reported against 4.7. This update includes a visual editor compatibility fix for an upcoming version of Chrome.

Uploading video and audio files no longer result in broken thumbnails and the REST API received a few enhancements related to data handling. WordPress 4.7.4 also restores the ability to Shift-click a range of checkboxes.

Auto updates are rolling out but if you’d like to update immediately, browse to Dashboard > Updates and click the update button.

To see a full list of changes visit the release notes page on the Codex. Since December, WordPress 4.7 has been downloaded more than 60 million times.

How to Fix Render-Blocking JavaScript and CSS in WordPress

Do you want to eliminate render-blocking JavaScript and CSS in WordPress? If you test your website on Google PageSpeed insights, then you will likely see a suggestion to eliminate render-blocking scrips and CSS. In this article, we will show you how to easily fix render blocking JavaScript and CSS in WordPress to improve your Google PageSpeed score.

How to fix render blocking JavaScript and CSS in WordPress

What is Render-Blocking JavaScript and CSS?

Every WordPress site has a theme and plugins that add JavaScript and CSS files to the front-end of your website. These scripts can increase your site’s page load time, and they can also block rendering of the page.

A user’s browser will have to load those scripts and CSS before loading rest of the HTML on the page. This means that users on a slower connection will have to wait a few milliseconds more to see the page.

These scripts and stylesheets are referred to as render-blocking JavaScript and CSS.

Website owners who are trying to achieve the Google PageSpeed score of 100 will need to fix this issue to attain that perfect score.

What is Google PageSpeed Score?

Google PageSpeed Insights is an online tool created by Google to help website owners optimize and test their websites. This tool tests your website against Google’s guidelines for speed and offers suggestions to improve your site’s page load time.

It shows you a score based on the number of rules that your site passes. Most websites get somewhere between 50-70. However, some website owners feel compelled to achieve 100 (the highest a page can score).

Do You Really Need the Perfect “100” Google PageSpeed Score?

The purpose of Google PageSpeed insights is to provide you guidelines to improve speed and performance of your website. You are not required to follow these rules strictly.

Remember that speed is only one of the many SEO metrics that help Google determine how to rank your website. The reason speed is so important is because it improves user experience on your site.

A better user experience requires a lot more than just speed. You also need to offer useful information, better user interface, and engaging content with text, images, and videos.

Your goal should be to create a fast website that offers great user experience.

We recently redesigned WPBeginner, and we kept our focus on speed as well as improving user experience.

We recommend that you use Google Pagespeed rules as suggestions, and if you can implement them easily without ruining user experience, then that’s great. Otherwise, you should strive to do as much as you can and then don’t worry about the rest.

Having said that, let’s take a look at what you can do to fix render blocking JavaScript and CSS in WordPress.

We will cover two methods that will fix the render blocking JavaScript and CSS in WordPress. You can choose the one that works best for your website.

1. Fix Render Blocking Scripts and CSS with Autoptimize

This method is simpler and recommended for most users.

First thing you need to do is install and activate the Autoptimize plugin. For more details, see our step by step guide on how to install a WordPress plugin.

Upon activation, you need to visit the Settings » Autoptimize page to configure the plugin settings.

Autoptimize Settings

You can start by checking the box next to JavaScript Options and CSS Options and then click on the save changes button.

You can now test your website using PageSpeed tool. If there are still render blocking scripts, then you need to come back to the plugin’s settings page and click on ‘Show Advanced Settings’ button at the top.

Advanced JavaScript Options

Here you can allow plugin to include inline JS and remove scripts that are excluded by default like seal.js or jquery.js.

Next, scroll down to CSS option and allow plugin to aggregate inline CSS.

Click on the ‘Save changes and Empty Cache’ button to save your changes and empty plugin cache.

Once you are done, go ahead and check your website again with the PageSpeed tool.

Make sure that you thoroughly test your website to see that nothing is broken by optimizing your JavaScripts or CSS.

How does it work?

Autoptimize aggregates all enqueued JavaScript and CSS. After that, it creates minified CSS and JavaScripts files and serves cached copies to your website as async or deferred.

This allows you to fix the render blocking scripts and styles issue. However, please keep in mind that it can also affect the performance or appearance of your website.

2. Fix Render Blocking JavaScript using W3 Total Cache

This method requires a little more work and is recommended for users already using W3 Total Cache plugin on their website.

First you will need to install and activate the W3 Total Cache plugin. If you need help, then see our guide on how to install and setup W3 Total Cache for Beginners.

Next, you need to visit Performance » General Settings page and scroll down to Minify section.

W3 Total Cache enable minify

First you need to check ‘Enable’ next to Minify option and then select ‘Manual’ for minify mode option.

Click on the save all settings button to store your settings.

Next, you need to add the scripts and CSS that you want to minify.

You can get the URLs of all the scripts and stylesheets that are render blocking from Google PageSpeed Insights tool.

Under the suggestions where it says: ‘Eliminate render-blocking JavaScript and CSS in above-the-fold content’, click on ‘Show how to fix’. It will show you the list of scripts and stylesheets.

Get JavaScript and Stylesheet URLs from Google PageSpeed tool

Take your mouse over to a script and it will show you the full URL. You can select this URL and then use your keyboard’s CTRL+C (Command+C on Mac) keys to copy the URL.

Now head over to your WordPress admin area and go to Performance » Minify page.

First you need to add JavaScript files that you want to be minified. Scroll down to JS section and then under the ‘Operations in areas’ set the embed type to ‘Non-blocking async’ for the <head> section.

Add scripts to minify

Next, you need to click on the ‘Add script’ button and then start adding script URLs that you copied from Google PageSpeed tool.

Once you are done, scroll down to CSS section and then click on the ‘Add a stylesheet’ button. Now start adding stylesheet URLs you copied from Google PageSpeed tool.

Add stylesheets to minify

Now click on the ‘Save settings and purge cache’ button to store your settings.

Visit the Google PageSpeed tool and test your website again.

Make sure that you also test your website thoroughly to see that everything is working fine.

Troubleshooting

Depending on how the plugins and your WordPress themes uses JavaScript and CSS, it could be quite challenging to completely fix all render blocking JavaScript and CSS issues.

While the above tools can help, your plugins may need certain scripts at a different priority level to work properly. In that case, the above solutions can break your plugins or they could behave unexpectedly.

Google may still show you certain issues like optimizing CSS delivery for above the fold content. Autoptimize allows you to fix that by manually adding inline CSS required to display the above fold area of your theme.

However, it could be quite difficult to find out what CSS code you will need to display above the fold content.

That’s all, we hope this article helped you learn how to fix render blocking JavaScript and CSS in WordPress. You may also want to see our ultimate guide boost WordPress speed and performance for beginners.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Fix Render-Blocking JavaScript and CSS in WordPress appeared first on WPBeginner.

Submitted a Plugin? Please Check Your Emails!

Currently ~30% of all new plugins are approved within 7 days of submission.

Why so low? People don’t reply to their emails. We have over 100 plugins waiting on replies from developers. At this precise moment (10:30 am US Pacific Time, Sunday April 16) there are ZERO plugins pending review. That means everyone who submitted a plugin between April 1 and today has been emailed.

If you didn’t get the email, please go check your spam. Free email clients like Hotmail, Yahoo, and Google tend to file us as ‘automated’ emails, which is not true, but whatever. Put plugins@wordpress.org in your whitelist (actually put @wordpress.org in a filter to have it never treated as spam and always important) because if you’re not getting emails from WP and you’ve submitted a plugin or a theme, you’re going to have a bad time.

Again. Everyone’s been emailed. I promise. Check your emails. Drop us a line if you can’t find it. Remember to whitelist us.

#reminder

Disable WordPress Responsive Images

[ Bruce Lee ] WordPress responsive images are awesome. But some people want to use their own methods to implement. This post explains how to disable WordPress responsive image functionality so that you can use your own methods. It makes things easier when you don’t have to wrestle with what WordPress is doing.

tl;dr

Grab the plugin.

WordPress responsive images

If you haven’t looked under the hood of your WP-powered site recently, you may be surprised at some of the new liberties that WordPress is taking with your images. As of version 4.4, WordPress is executing its own responsive-image functionality behind the scenes. Specifically, there are two things that WordPress does with its built-in responsive-image feature:

  1. Creates an additional copy of your image that is 768px
  2. Adds srcset attributes to your image markup on the frontend

Again, this is great news for those who want automated responsive images. But for those of us who prefer our own solutions, it’s counter-productive. For example, The additional 768px image happens behind the scenes, with no corresponding option in the WP Admin (under Settings > Media). And further, srcset attributes are not always optimal or required. Consider the typical markup required to display an image:

<img src="http://example.com/wp/wp-content/uploads/2017/03/photo-600x471.jpg" alt="Whatever">

Here is what that image markup looks like after WordPress gets ahold of it (unfolded for clarity):

<img 
class="wp-image-944 size-medium" 
src="http://example.com/wp/wp-content/uploads/2017/03/photo-600x471.jpg" 
alt="photo" 
width="600" 
height="471" 
srcset="http://example.com/wp/wp-content/uploads/2017/03/photo-600x471.jpg 600w, 
http://example.com/wp/wp-content/uploads/2017/03/photo-1024x804.jpg 1024w, 
http://example.com/wp/wp-content/uploads/2017/03/photo.jpg 1600w" 
sizes="(max-width: 709px) 
85vw, (max-width: 909px) 
67vw, (max-width: 984px) 
61vw, (max-width: 1362px) 
45vw, 600px" />

Again, sweet for those who need it; not so much for those who don’t. I mean, that’s a LOT of extra markup just to display a responsive image. Imagine 10 or more images on the same page.. the extra bytes can really add up and chew into site performance.

Behind the scenes

Before looking at how to disable WordPress’ responsive image functionality, let’s examine what’s happening under the hood. First, here is the array of image data that is accessible via the intermediate_image_sizes_advanced filter hook:

array(4) {
	["thumbnail"]=> array(3) { 
		["width"]=> string(3) "150" 
		["height"]=> string(3) "150" 
		["crop"]=> string(1) "1"
	}
	["medium"]=> array(3) {
		["width"]=> string(3) "300" 
		["height"]=> string(3) "300" 
		["crop"]=> bool(false) 
	}
	["medium_large"]=> array(3) { 
		["width"]=> string(3) "768" 
		["height"]=> string(1) "0" 
		["crop"]=> bool(false) 
	}
	["large"]=> array(3) {
		["width"]=> string(4) "1024" 
		["height"]=> string(4) "1024" 
		["crop"]=> bool(false)
	}
}

So that means we can access the array and modify it however we would like. Here is a function that demonstrates this:

function shapeSpace_customize_image_sizes($sizes) {
	unset($sizes['thumbnail']);
	unset($sizes['medium']);
	unset($sizes['medium_large']);
	unset($sizes['large']);
	return $sizes;
}
add_filter('intermediate_image_sizes_advanced', 'shapeSpace_customize_image_sizes');

Here we are hooking into intermediate_image_sizes_advanced and unsetting (removing) each image size data from the $sizes array. Of course, this is just an example to illustrate the concept. Now let’s use this information to disable WP’s responsive image functionality.

Step 1: Disable the extra image

Using the above technique, we can prevent WordPress from auto-creating the additional 768px (medium_large) image:

function shapeSpace_customize_image_sizes($sizes) {
	unset($sizes['medium_large']); // 768px
	return $sizes;
}
add_filter('intermediate_image_sizes_advanced', 'shapeSpace_customize_image_sizes');

No modifications are required. Adding this function restores the pre-4.4 default image sizes, which also correspond to the settings provided on the WP Settings > Media screen:

  • Thumbnail (default 150)
  • Medium (default 300)
  • Large (default 1024)

Note that you can skip this step if you want to keep medium-large copies of your uploaded images. You can implement only the next step, only this step, both, or none. Your call.

Step 2: Disable the srcset attributes

After disabling the auto-generated medium-large 768px image, the final step in disabling WordPress’ responsive functionality is to disable the srcset markup that is added to every <img> tag on the frontend. We can do that with the following slice of code:

// disable srcset on frontend
add_filter('max_srcset_image_width', create_function('', 'return 1;'));

And done. No modifications are required, just add to functions.php and enjoy the results. Which, by the way, you can verify by examining the source code of your web pages.

Disable via plugin

If you would rather use a plugin to disable WP’s responsive images, here you go:

<?php
/*
Plugin Name: Disable Responsive Images Complete
Plugin URI: https://plugin-planet.com/
Description: Disables WP's responsive-image feature
Author URI: https://plugin-planet.com/
Author: Jeff Starr
Version: 1.0
*/

// disable srcset on frontend
add_filter('max_srcset_image_width', create_function('', 'return 1;'));

// disable 768px image generation
function shapeSpace_customize_image_sizes($sizes) {
	unset($sizes['medium_large']);
	return $sizes;
}
add_filter('intermediate_image_sizes_advanced', 'shapeSpace_customize_image_sizes');

This plugin combines the two steps above into a simple plugin. I use this on several of my own sites, including this one. It just works. If and when WordPress changes how it handles responsive images, I’ll update this code accordingly. So if you know of any changes, or if I’ve missed anything, please let me know in the comments or directly via email.


Display bbPress Posts without a Plugin

[ Display bbPress Posts without a Plugin ] I recently redesigned my .htaccess site, htaccessbook.com. Before the redesign, I was using bbPress for the forum functionality. It worked okay for a few years, but along the way there were all sorts of really nasty bugs and important things breaking. It seemed like, no matter what, each updated version of the bbPress plugin caused serious problems, like replies not working, permalinks changing, and all sorts of other issues. Eventually, I got tired of spending hours after each bbPress update to try and fix things. It was time to find a better way.

No plugins required

After researching possible replacements for bbPress, I felt unimpressed and uninspired. There just weren’t any good fits that met all of my requirements, which honestly were fairly modest. So I gave up on existing “solutions” and decided to roll my own. After some investigation and planning, it turned out that all I needed was a way to display all of the forum topics and replies. Didn’t need any other functionality, just a way to display existing forum content.

Currently the forum is closed to new replies, which is why I needed only to display content. At some point in the future I will reopen the forum and use USP Pro to enable logged in users to submit new topics and replies. But for now, I’m simply displaying the existing forum content publicly on the front-end.

And so that’s what this tutorial is all about: displaying your bbPress content without using a plugin. This may be useful if you are ditching bbPress or in the process of finding another forum solution (which unfortunately is easier said than done).

Before diving in, please understand that this technique is not really meant to be a full-fledged solution. It’s simply a way to access your forum content from the database and display it on the front-end of your WordPress-powered site. With that in mind, here are the steps (and code) required to make it happen.

Step 0: Back up your database and files

Before making any changes, take a moment to ensure that you have a good working backup of your site files and database. This is entirely a precautionary measure and just good practice in general. So if anything unexpected or weird happens, you can restore your site’s functionality as quickly as possible.

Step 1: Add support for Topics and Replies

First, we need to add support for a couple of Custom Post Types (CPTs). When bbPress was installed, it provided the support required for its various CPTs. Now bbPress is removed, but all of that CPT data remains in the database. For this tutorial, we want to display Topics and Replies, so we need to add CPT support accordingly. To do so, add the following template code to your current theme’s functions.php file:

// add support for topic cpt
function shapeSpace_topic_cpt() {
	$labels = array(
		'name'               => __('Topics', 'shapeSpace'),
		'singular_name'      => __('Topic', 'shapeSpace'),
		'menu_name'          => __('Topics', 'shapeSpace'),
		'name_admin_bar'     => __('Topics', 'shapeSpace'),
		'add_new'            => __('Add New', 'shapeSpace'),
		'add_new_item'       => __('Add New Topic', 'shapeSpace'),
		'new_item'           => __('New Topic', 'shapeSpace'),
		'edit_item'          => __('Edit Topic', 'shapeSpace'),
		'view_item'          => __('View Topic', 'shapeSpace'),
		'all_items'          => __('All Topics', 'shapeSpace'),
		'search_items'       => __('Search Topics', 'shapeSpace'),
		'parent_item_colon'  => __('Parent Topics:', 'shapeSpace'),
		'not_found'          => __('No topics found.', 'shapeSpace'),
		'not_found_in_trash' => __('No topics found in Trash.', 'shapeSpace'),
	);
	$args = array(
		'labels'              => $labels,
		'taxonomies'          => array(),
		'public'              => true,
		'publicly_queryable'  => true,
		'show_ui'             => true,
		'show_in_menu'        => true,
		'query_var'           => true,
		'rewrite'             => array('slug' => 'topic'),
		'capability_type'     => 'post',
		'has_archive'         => true,
		'hierarchical'        => false,
		'menu_position'       => null,
		'supports'            => array('title', 'editor', 'author', 'excerpt', 'custom-fields'),
		'exclude_from_search' => false, 
	);
	register_post_type('topic', $args);
}
add_action('init', 'shapeSpace_topic_cpt');



// add support for reply cpt
function shapeSpace_reply_cpt() {
	$labels = array(
		'name'               => __('Replies', 'shapeSpace'),
		'singular_name'      => __('Reply', 'shapeSpace'),
		'menu_name'          => __('Replies', 'shapeSpace'),
		'name_admin_bar'     => __('Replies', 'shapeSpace'),
		'add_new'            => __('Add New', 'shapeSpace'),
		'add_new_item'       => __('Add New Reply', 'shapeSpace'),
		'new_item'           => __('New Reply', 'shapeSpace'),
		'edit_item'          => __('Edit Reply', 'shapeSpace'),
		'view_item'          => __('View Reply', 'shapeSpace'),
		'all_items'          => __('All Replies', 'shapeSpace'),
		'search_items'       => __('Search Replies', 'shapeSpace'),
		'parent_item_colon'  => __('Parent Replies:', 'shapeSpace'),
		'not_found'          => __('No replies found.', 'shapeSpace'),
		'not_found_in_trash' => __('No replies found in Trash.', 'shapeSpace'),
	);
	$args = array(
		'labels'              => $labels,
		'taxonomies'          => array(),
		'public'              => true,
		'publicly_queryable'  => true,
		'show_ui'             => true,
		'show_in_menu'        => true,
		'query_var'           => true,
		'rewrite'             => array('slug' => 'reply'),
		'capability_type'     => 'post',
		'has_archive'         => false,
		'hierarchical'        => false,
		'menu_position'       => null,
		'supports'            => array('title', 'editor', 'author', 'excerpt', 'custom-fields'),
		'exclude_from_search' => true, 
	);
	register_post_type('reply', $args);
}
add_action('init', 'shapeSpace_reply_cpt');

You can add this code wholesale without any modifications, or you can consult the WP Codex and customize everything according to your needs. Note that some of the parameters defined in these two functions are required in order to properly display the bbPress Topics and Replies.

Step 2:

Once the Custom Post Types are defined, we need a template to display their content. The easiest way to do this is to create a new Page and assign a custom template that contains the following code:

<?php 
	/* Template Name: Forum Posts */ 
	/* 
		This is a temporary Page template for looking up old forum posts
		See also functions.php for creation of related custom post types
	*/
?>
<?php get_header(); ?>

<div class="content" id="content">
	<article class="wrap">
		
		<?php if (current_user_can('manage_options')) : ?>
			
			<?php // Topics
			
			$paged = (get_query_var('paged')) ? get_query_var('paged') : 1;
			
			$args = array('post_type' => array('topic'), 'posts_per_page' => 1, 'paged' => $paged, 'order' => 'ASC'); // forum, topic, reply
			
			$temp = $wp_query;
			$wp_query = null;
			
			$wp_query = new WP_Query();
			$wp_query->query($args);
	
			if ($wp_query->have_posts()) : while ($wp_query->have_posts()) : $wp_query->the_post(); ?>
			
			<h1><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h1>
			<div class="meta">Post ID: <?php echo $post->ID; ?> &bull; Forum: <?php echo get_the_title($post->post_parent); ?> &bull; Posted by <?php the_author_posts_link(); ?> on 
			<time datetime="<?php echo the_time('Y-m-j'); ?>" pubdate><?php the_time('l, F jS, Y'); ?></time></div>
			<div class="the-content"><?php the_content(); ?></div>
				
				
				<?php // Replies
				
				$topic = $wp_query->post->ID;
				
				$replies_args = array('post_type' => array('reply'), 'posts_per_page' => -1, 'order' => 'ASC', 'post_parent' => $topic); 
				
				$replies = new WP_Query();
				$replies->query($replies_args);
				if ($replies->have_posts()) : while ($replies->have_posts()) : $replies->the_post(); ?>
					
					<h4><?php the_title(); ?></h4>
					<div class="meta">Post ID: <?php echo $post->ID; ?> &bull; Reply to: <?php echo get_the_title($post->post_parent); ?> &bull; Posted by <?php the_author_posts_link(); ?> on 
					<time datetime="<?php echo the_time('Y-m-j'); ?>" pubdate><?php the_time('l, F jS, Y'); ?></time></div>
					<div class="the-content"><?php the_content(); ?></div>
					
				<?php endwhile; ?>
				<?php endif; ?>
				
				
			<?php endwhile; ?>
			<?php wp_reset_postdata(); ?>
			<?php previous_post_link('<div class="prev">%link</div>', '&larr;&nbsp;%title'); ?>
			<?php next_post_link('<div class="next">%link</div>', '%title&nbsp;&rarr;'); ?>
			<?php wp_reset_query(); ?>
			<?php endif; ?>
			
		<?php endif; ?>
		
	</article>
</div>

<?php get_footer(); ?>

This is a complete page template that can be added directly to any custom page (e.g., /mytheme/page-custom.php). Here is a rundown of what it does:

  1. Gets the theme header template
  2. Checks that the current user can manage_options, so only admin-level users can view the forum posts. If desired, you can remove this line and just set the Page visibility to Private or Password Protected. Or if you want to give all users access, you can remove this line (and the last closing endif; statement).
  3. Begins the Loop for forum topics: we set the $paged variable so that paged navigation will work. This will enable the navigation links to work, so you can browse through each forum topic.
  4. Begins the custom loop for the topics. This loop first displays the topic title, date, forum, and other metadata. After displaying the topic content, a second, nested loop is started for the topic replies.
  5. The second loop for replies is similar to the first, parent loop. We grab the topic ID from the parent loop, and then use it to run the replies loop. Inside of the replies loop, we display the reply title, ID, content, and other related information.
  6. After closing each of the two loops, we use wp_reset_postdata() to restore the global $post variable of the main query loop.
  7. Then navigation links are added via previous_post_link() and next_post_link(), enabling navigation through each forum topic.
  8. Lastly and just to be safe, we use wp_reset_query() to restore the $wp_query and global post data to the original main query.

Wrapping thoughts..

Again, this is not meant as any type of permanent solution, but rather just provides an interface for you to access your forum content. It’s meant to give you an idea going forward, to build from and customize as needed to display your topics and replies as needed. You can see my implementation of this basic technique at .htaccess made easy.


Customizer Team Proposes Image Widget for WordPress 4.8

WordPress contributors to the customizer have published a merge proposal for a new JavaScript and REST API-powered core image widget. The new widget interfaces with the WordPress media library to provide a simpler, more intuitive experience for adding images. No new widgets have been added to core since the Custom Menu widget was included in 3.0 nearly seven years ago.

Image widget demo optimized

The current method of inserting images into widgets is a multi-step process that many plugins have attempted to simplify. Hundreds of thousands of WordPress users have installed a plugin with this feature. The Image Widget plugin, created by Modern Tribe, is one of the most popular with more than 500,000 active installs.

Widget architecture in WordPress currently relies on PHP and AJAX, but the new image widget will follow the recent trend towards JavaScript interfaces.

“In the time since WP_Widget was introduced in 2.8, WordPress has made dramatic shifts toward developing interfaces in JavaScript, including with the Customizer in 3.4 and the Media Library in 3.5, and more recently with the focus on the REST API,” Mel Choyce said in the proposal. “Given that the media widgets are naturally interfacing with the media library JS, it is necessary that the media widgets make use of JavaScript to construct their UI instead of relying on PHP.”

Customizer component co-maintainer Weston Ruter noted in the comments that the new proposed image widget also allows for external images to be embedded by URL. This is a feature that Jetpack offers in its image widget. The new core widget will support both use cases that WordPress users are already familiar with from popular plugins.

The image widget is the first of several planned JS-powered media widgets, including video, audio, galleries, and slideshows. Ruter said progress on the video widget is coming along well and he anticipates it will likely land next. Contributors have begun work on the audio widget, but Ruter said galleries and slideshows are a higher priority.

Matt Mullenweg, who is leading core development this year, confirmed in his quarterly update today that the image widget will be considered for 4.8.

“The plan is for the larger block-driven customization work to kick off in June,” Mullenweg said. “Prior to that, we’re focusing on widgets and other low-hanging fruit. Lack of developers slowed us down the last few months, now doing better but could still use more help there. Media widgets + WYSIWYG on text widget seem simple but will have a big user impact.”

Contributors on the Customizer team are asking for developers and users to test the new image widget. The latest version of the plugin is available on GitHub. The Core Media Widgets plugin is also available on WordPress.org.

WordPress .htaccess file

[ WordPress .htaccess file ] The WordPress core uses .htaccess for two things: Permalinks and Multisite. This means that .htaccess is only required if you have enabled either of these features. Otherwise, .htaccess is entirely optional for default WordPress installations. Beyond the WP core, many plugins also use the .htaccess file for custom directives involving rewrites, redirects, custom headers, file compression, and much more. In many cases, such plugins add their .htaccess rules to your .htaccess file automatically, behind the scenes.

So even if you haven’t enabled Permalinks or Multisite, your site may be using .htaccess rules added by WordPress plugins for various types of functionality. That’s one of the cool things about .htaccess: it can be configured and customized to improve your site’s performance, security, and usability. To help you get started, this tutorial provides a collection of .htaccess techniques that are useful for any WordPress-powered site. Combined into a blank .htaccess file, these techniques serve as a great starting point for creating your own custom .htaccess file for WordPress.

Before diving in..

Before making any changes to your site’s .htaccess file(s), remember to make a backup copy. That way you can quickly restore original functionality should anything unexpected happen. These rules are all well-tested and commonly used, but in this line of work anything can happen, so it’s best to be prepared with good working backups just in case.

Disable directory views

With this technique, we increase security by disabling directory views, which also are known as “directory indexes” or “directory listings”. Many web hosts disable directory views by default, but it’s important to know for sure. If your files are visible, here is an effective way to lock things down.

# Disable directory views
Options -Indexes
<IfModule dir_module>
	DirectoryIndex disabled
	DirectoryIndex index.php
</IfModule>

Here we disable Indexes via the Options directive. Then we specify the DirectoryIndex just in case. So technically it’s fine to just do this:

# Disable directory views
Options -Indexes

I include the additional dir_module rules because they are related, and some people may find them useful. To learn more about customizing directory views, check out my tutorial, Better Default Directory Views with HTAccess.

Set default encoding

Setting your site’s default encoding as UTF-8 helps browsers and devices correctly interpret your page content.

# Set default encoding
AddDefaultCharset UTF-8

This directive helps to improve the accuracy and consistency of your web pages. It’s also possible to set the character encoding for specific file types. For example, here we are setting UTF-8 encoding for all CSS and JavaScript files:

# Set encoding for CSS & JS
<IfModule mod_mime.c>
	AddCharset utf-8 .html .css .js
</IfModule>

For more possibilities, check out the “Add mod_mime suport” section of my tutorial, Useful .htaccess rules for all websites.

Add Vary header

According to Google and others, publicly cacheable, compressible resources should include the following header:

Vary: Accept-Encoding

This is to prevent certain public proxy services from delivering compressed versions of your files to clients that do not support compression. Sending a Vary header for compressed resources helps resolve this issue by instructing the proxy to cache both compressed and uncompressed versions. To implement, add this code to your site’s root .htaccess file:

# Add Vary header
<IfModule mod_headers.c>
	<FilesMatch ".(css|js|gz|xml)$">
		Header append Vary: Accept-Encoding
	</FilesMatch>
</IfModule>

This code sends the necessary Vary header for CSS, JavaScript, gzip, and XML files. If your site serves other compressed resources, you can add their respective file types to the list, like so:

.(css|js|gz|xml|zip)$

Here we have added the ZIP file format, zip.

Add security headers

There are lots of useful headers that can be added to any website. For example, here are three headers that provide some great security benefits:

  • Protect against XSS attacks
  • Protect against page-framing and click-jacking
  • Protect against content-sniffing

Amazingly, you can add these security benefits with a simple slice of .htaccess:

# Add Security Headers
<IfModule mod_headers.c>
	Header set X-XSS-Protection "1; mode=block"
	Header always append X-Frame-Options SAMEORIGIN
	Header set X-Content-Type-Options nosniff
</IfModule>

No edits need made for this code. Simply add to root .htaccess and enjoy the extra protection. You can learn more about this technique by visiting my tutorial, Increase Security with X-Security Headers.

Protect sensitive files

By default, all WordPress installs include the following files:

  • wp-config.php – WP configuration file
  • license.txt – WP license information
  • readme.html – WP install & version information

Of these, wp-config.php should by default NOT be publicly accessible. The other two files, license.txt and readme.html, are by default publicly accessible. All three of these files contain information about your WordPress-powered site. By blocking public access to these files, you prevent bad actors from obtaining and using the information when crafting their attacks. Here is the code to make it happen:

# Protect sensitive files
<FilesMatch "^(wp-config.php|license.txt|readme.html)">
	Order Allow,Deny
	Deny from all
</FilesMatch>

This simple technique uses FilesMatch to target each of the files that should be denied access. You can protect any other loose or sensitive files by adding them to the FilesMatch directive.

Leverage browser caching

Browser caching plays an important role with all websites, especially WordPress. This technique ensures that your site is taking advantage of browser caching by setting optimal ExpiresByType HTTP headers.

# Leverage browser caching
<IfModule mod_expires.c>
	ExpiresActive on
	ExpiresDefault "access plus 1 month"
	#
	ExpiresByType image/jpg  "access plus 1 year"
	ExpiresByType image/jpeg "access plus 1 year"
	ExpiresByType image/gif  "access plus 1 year"
	ExpiresByType image/png  "access plus 1 year"
	ExpiresByType text/css   "access plus 1 month"
	#
	ExpiresByType text/javascript        "access plus 1 month"
	ExpiresByType application/javascript "access plus 1 month"
	ExpiresByType text/x-javascript      "access plus 1 month"
	#
	ExpiresByType image/x-icon "access plus 1 year"
</IfModule>

This code helps to optimize performance by setting expires headers for the most common file types. You can adjust the cache times to suit your needs, and add more file types as required. For more information, check out Google’s article, Leverage Browser Caching.

Enable file compression

File compression reduces the amount of data that is sent to the client, so it is a great way to improve performance. Fortunately, Apache enables compression via its Deflate module, which can be implemented with the following slab of .htaccess:

# Enable file compression
<IfModule mod_deflate.c>
	AddOutputFilter       DEFLATE css js
	AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
	AddOutputFilterByType DEFLATE application/vnd.ms-fontobject application/x-font-ttf font/opentype
	AddOutputFilterByType DEFLATE application/javascript application/x-javascript text/javascript text/x-js
	AddOutputFilterByType DEFLATE text/html text/plain text/richtext text/css application/json text/xsd text/xsl
	AddOutputFilterByType DEFLATE text/xml text/x-component application/xml application/xhtml+xml application/rss+xml application/atom+xml
</IfModule>

This code first enables compression for all CSS and JavaScript files. It then enables compression for many other types of files. Feel free to customize the file formats that should be compressed. For more information, check out .htaccess enable compression.

Block external POST requests

POST requests are required when submitting certain forms. For example, the comment form, login form, and most contact forms all submit their data via the POST request method. Normally, POST requests are initiated by users who are visiting your site. But it’s also possible for bad actors to submit malicious POST requests from another domain or source, in an attempt to hack your stuff. To prevent this, we can deny access to all POST requests that are not initiated from your domain. This can be accomplished with the following slice of .htaccess:

# Block external POST
<IfModule mod_rewrite.c>
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} (wp-comments-post|wp-login).php [NC]
	RewriteCond %{HTTP_REFERER} !(.*)example.com [NC,OR]
	RewriteCond %{HTTP_USER_AGENT} ^$
	RewriteRule .* - [L]
</IfModule>

Remember to change example.com to match your own domain. Once implemented correctly, this code does the following:

  1. Checks if the request is POST
  2. Checks if the request is for the comments form or the login form
  3. Checks if the request is not from your domain, or if the user agent is empty
  4. If these conditions are true, the request is denied via 403 “Forbidden” response

In doing this, the above technique helps to keep your site secure by blocking any POST requests that do not originate from your domain. This helps to reduce spam, brute-force login attacks, and lots of other malicious mischief.

Note that you can protect other POST forms as well. For example, if you have a contact form located at http://example.com/contact/, you can add it by modifying the REQUEST_URI directive like so:

RewriteCond %{REQUEST_URI} (wp-comments-post.php|wp-login.php|/contact/) [NC]

Remember to test well before going live with any changes. More info: Block Spam by Denying Access to No-Referrer Requests.

Enable WordPress permalinks

Last but not least, if you have enabled Permalinks for your site, you must include the required .htaccess directives. There are two possibilities here: WordPress installed in the site’s root directory, or WordPress installed in a sub-directory. Depending on where WordPress is installed, you will want to include one of the following sets of directives.

WordPress in site root directory

Here is the code to use if WordPress is installed in the site’s root directory:

# BEGIN WordPress
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /
	RewriteRule ^index.php$ - [L]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule . /index.php [L]
</IfModule>
# END WordPress

No modifications are required for this code.

WordPress in a subdirectory

Alternately, here is the code to use if WordPress is installed in it’s own (sub) directory (e.g., a subdirectory named /wordpress/):

# BEGIN WordPress
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /wordpress/
	RewriteRule ^index.php$ - [L]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule . /wordpress/index.php [L]
</IfModule>
# END WordPress

For this code, you will need to edit both instances of wordpress with the path/directory in which WordPress is installed. For example, here at Perishable Press, WordPress is installed in a directory named /wp/, so I replaced wordpress with wp.

For more information about either of these techniques, check out my tutorial, The htaccess Rules for all WordPress Permalinks.

Bonus tip!

As a bonus, you can add the following directive (just after the first RewriteRule) to automatically redirect all login requests to the actual WP Login Page:

RewriteRule ^login/?$ /wp-login.php [QSA,L]

For more information on this trick, check out Chris Coyier’s DigWP post, Simpler Login URL. This is a useful technique for client sites :)

Download ’em all

The techniques presented in this article are not dependent on each other. So you can use them separately, as desired; or you can combine them all into a single .htaccess file to create a solid .htaccess file for WordPress. To make things easier, here is a text file that contains all of the techniques from this tutorial:

WordPress .htaccess file – Version 1.0 (3 KB txt)

Going further

Intentionally, the techniques provided in this article are kept as general and as widely applicable as possible. There are thousands more useful techniques that could be added, but keeping it simple with only the essentials is optimal when first getting started. I encourage you to go further with your .htaccess file. Here are some recommended resources that are worth exploring.

Questions and comments always welcome :)


WordPress Editor Experience Survey Shows 75% of Respondents Don’t Use Distraction-Free Writing Mode

The WordPress Editor Experience survey results have been published with data from 2,563 participants, a significantly larger sampling than the 50 who responded to the recent customizer survey. Both the editor and the customizer are included in Matt Mullenweg’s three main focus areas for core development in 2017. The purpose of the surveys is to find out how WordPress users are using or not using the current features.

More than half of the survey respondents (66%) identified themselves as developers (in addition to other roles). Since this category of users dominated the survey results, Mark Uraine decided to break it down further to display other categories developers selected.

Based on these results, it isn’t surprising that more than 85% of respondents use the markup text editor and 35% of those use it exclusively. Support for syntax highlighting is also a popular request.

The distraction-free writing mode received quite a bit of feedback on the survey. More than 75% of respondents said they do not use it.

The current implementation of the distraction-free writing mode was introduced in WordPress 4.1 at the end of 2014. The idea was to minimize distractions without having to go through a clunky transition to access the admin menu or meta boxes. Moving the cursor to the right or left of the editor brings them back into view, but many people find the admin interface sliding in and out of view to be distracting. Several who commented suggested that the feature could use some major improvements.

The survey also revealed that the majority of respondents (72%) install plugins that add features to the editor. These most commonly include shortcodes, Advanced TinyMCE, Tables, and Visual Composer. The results indicate that users often extend the editor to get more basic advanced layout capabilities for presenting their content.

The Editor Experience survey was a good first start, but it doesn’t accurately represent WordPress’ global user base. The results are heavily skewed towards developers’ needs and experiences. Developers are users, too, but there has to be a way to get these surveys into the hands of a more diverse sampling of users. Reopening the survey and circulating it beyond the WordPress developer community might help to paint a more accurate picture of users’ experiences with the editor.

A more diverse sampling would reveal whether or not the vast majority of users have no use for the current implementation of the distraction-free writing mode, as developer feedback seems to suggest. It could also provide more feedback on the visual editor features that 35% of respondents to this survey never use.

How to Fix “Missing a Temporary Folder” Error in WordPress

Are you seeing ‘Missing a temporary folder’ error on your WordPress site? This error makes it impossible to upload images, update themes and plugins, or update WordPress core. In this article, we will show you how to easily fix “Missing a temporary folder” error in WordPress.

How to fix 'Missing temporary folder' error in WordPress

What Causes The ‘Missing a Temporary Folder’ Error in WordPress?

This error is caused by incorrect PHP settings on your WordPress hosting environment. There is a specific PHP setting that defines a temporary folder to be used by apps like WordPress to temporarily store data before saving it to the desired location.

WordPress needs access to this temporary folder when you upload an image, install or update a theme or plugin, or update WordPress core.

If the location of this folder is not defined in your server’s PHP configuration, then WordPress will be unable to do any of these things and will show you ‘Missing a temporary folder’ error.

Missing temporary folder error

Having said that, let’s see how to easily fix the ‘Missing a temporary folder’ error in WordPress.

Fix Missing Temporary Folder Error in WordPress

For this tutorial, you will need to edit wp-config.php file in WordPress. If you haven’t done this before, then please see our guide on how to edit wp-config.php file in WordPress.

First, you will need to connect to your website using an FTP client or File Manager in cPanel dashboard of your hosting account.

Next, you will need to locate the wp-config.php file and edit it.

Editing wp-config.php file using an FTP client

You need to paste this code to the file just before the line that says ‘That’s all, stop editing! Happy blogging’.

define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');

Save your changes and upload the wp-config.php file back to your website.

Next, you need to go to /wp-content/ folder and create a new folder inside it. You need to name this new folder temp.

Creating temp folder

That’s all, you can now visit your WordPress admin area and try uploading an image.

Troubleshooting

If this method doesn’t work, then check the directory permissions for your wp-content folder.

Note: This error is caused by poorly configured hosting environment. The solution described above is just a workaround. You should still ask your hosting provider to fix this. If they don’t, then you should switch to one of these top WordPress hosting companies.

We hope this article helped you fix the ‘Missing a temporary folder’ error in WordPress. You may also want to bookmark our ultimate list of the most common WordPress errors and how to fix them.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Fix “Missing a Temporary Folder” Error in WordPress appeared first on WPBeginner.

Plugin Submissions Open

It took a little longer than expected or desired, due to a couple serious issues. Not everything is perfect yet, but submissions are open.

Some things are different. Most are the same.

Zips are required (not links)

Instead of a link, you will now upload your zip directly. In doing so, the plugin slug will be assigned for you. If your zip isn’t valid, if your plugin headers aren’t valid, you’ll get an error message. Read it carefully. If you get a message that says your plugin URL and Author URL can’t be the same, that’s exactly what it means.

* Plugin URI: https://example.com/plugin

  • Author URI: https://example.com/

Those have to be different.

Slugs are determined from plugin headers

That’s right, the name you get is based on your Plugin Headers. That means this:

* Plugin Name: My Cool Plugin

That will give you a plugin slug of my-cool-plugin and that will get you an email from us telling you not to use “Plugin” in your URL, and is “my-cool” okay? Please do read the emails and reply properly. If it’s a simple typo, we’ll just fix it for you. If we’re not sure what’s best, we’ll email.

No more 7-day rejections

Since the new and pending queues are now split, we won’t be rejecting plugins after seven days. If you don’t reply to the email, your plugin just sits there and waits for you. But the good news here is that you can’t resubmit. You’ll get a warning message that the plugin already exists.

Release and iterate

All of this is going to be iterated on and improved. We have goals to make the add page list everything you have pending, for example, and we’ll be implementing a limit of how many plugins you can upload at once to prevent things like one person submitting ten at once. Since our queue is rarely more than a week, that’s no hardship.

I’m primarily concentrating on making the back-end of the directory work better and documenting the process so we can get down to the business of expanding the team. Divide and conquer as they say.

What about new reviewers?

Soon! This year! Hopefully by summer. My modest goals are as follows:

  1. Get all the current reviewers up to speed
  2. Invite a couple select people to join as guinea pigs
  3. Train them up good and work out the kinks in that
  4. Post an open call for new members
  5. Accept some and train them
  6. Go back to step 4

By limiting how many new members we take at a time, we can release and iterate our training methods and documentation faster.

As always, remember to whitelist the plugins@wordpress.org email address and follow this blog for updates.

Thank you for your patience!

Contributing to WordPress as a designer

A few weeks ago, I went to my first proper WordCamp, in London. I went as a designer, and I wasn’t expecting to learn very much, but spoiler warning: I was wrong. In this post, I will explain why going to a WordCamp is worthwhile as a designer, why WordPress needs more designers, and how designers reading this can start applying their skills to the WordPress design right now.

Wordcamps are not just for programmers and bloggers

You may have noticed I said ‘proper WordCamp’ in the opening, because technically my first one was WordCamp NL last year, but I’m not counting that one since I only went because Yoast had a booth there. And back in 2016, I didn’t think I had much business being at a WordCamp neither. Not because I thought I knew everything, but precisely the opposite; I hardly used WordPress. I wasn’t writing content, I just used it to upload comics I had drawn. Terms like conversion rate and cornerstone content didn’t mean much to me. It all seemed very technical. And especially the thought of contributing to the core of WordPress seemed very daunting (even writing my own theme took me ages). But WCLDN17 proved that I was wrong about all these things. 

For good SEO, you need a good user experience. Learn about UX & Conversion! »

UX & Conversion from a holistic SEO perspective$ 19 - Buy now » Info

There has never been a better time for design to shine

Almost a year after WCNL16, I became the UX designer at Yoast. I still didn’t know all the intricacies of WordPress, but I was using it a lot more, making sure our stuff integrated well and looked good. So maybe I could get some value out of a WordCamp this time around? I wasn’t sure yet. But off I went to WCLDN17.

Looking at the schedule, there were a lot more talks about design and UX than I had expected; Crispin Read talked about the value of testing and hard data over opinions; Sarah Semark talked about how modern web design all looks the same (and why); Graham Armfield talked about how some simple design measures can make sure your site is accessible to almost everyone; and Dave Walker‘s talk was especially interesting to me, because he’s also an illustrator using WordPress. It was clear that design was coming to the forefront, and rightly so.

This was all good info for me to apply at Yoast, but that I could be of value to WordPress was an unexpected discovery during Contributor Day.

WordPress needs designers too

Contributor Day is meant to focus the attention of everyone at a Wordcamp towards improving WordPress in some way. Naturally, I sat down at the Design table, and there I met Tammie Lister. She is a UX designer at Automattic – that’s the company behind WordPress.com, Akismet, Gravatar, WooCommerce, and Simplenote (which I drafted this in!). She was easy to talk to, and very enthusiastic about design. But more importantly, she had prepared a few simple tasks for us to tackle that day. It made my entrance into the whole WordPress ecosystem pretty smooth.

My chosen task was to make a mockup for the mobile image editor; Something had gone really wrong in there, lots of overlapping panels and redundant buttons. By simply designing a fix in Photoshop, I helped move this problem closer towards being solved.

In doing so, I started to understand why Tammie kept wishing that more designers would start to look at WordPress itself. There are many design issues like this hanging around, waiting for a designer to solve them. Doing so may not seem like a big contribution, but WordPress is used by nearly 80 million sites – that’s almost 30% of the web. So whatever you end up doing, it’s guaranteed that at least a few people are going to be happy with it.

And I can understand why designers maybe don’t flock to this calling. Getting started can seem daunting – I was a prime example of this mindset. If that’s you too, then read on, I’ve outlined three simple steps to get you started.

Ways a designer can start improving WordPress

If you use WordPress and like designing interfaces, these are some quick ways to combine those two passions:

1. Go to a Contributor Day.

This may seem like a big first step, but I promise you it’s not. You’ll get set up way faster than you would at home by yourself, there are tons of people who can help, and everyone is super nice. I would have never known where to begin if it wasn’t for Tammy’s guidance. There are tons of WordCamps all around the world, so guaranteed that there is one near you and within your budget. If not, perhaps you’re lucky like me and your company works with WordPress, get them to send you out to one!

2. Join the design channel in the WordPress Slack.

I could tell you to go to make.wordpress.org/design, but to be honest that site could use a UX update itself. No, I feel like it’s better just to get in touch with the people on the frontlines of WordPress design on Slack. Slack is a chat app, and you can join the WordPress team on there by going to this page. And when you’re in, simply introduce yourself in the design channel and ask how you can help, and somebody will get you started.

3. If you’re not a designer…

…show a passionate designer some of the issues on this list. Hopefully, there’s a good chance they’ll get triggered to fix these little design problems. Sometimes even just posting feedback is enough to get the ball rolling again. Together with this article, I’m sure they can take it from there.

Bonus: Submit design tickets

If your own projects are keeping you busy enough (and I can relate), here’s a really simple way you can still help out: for every weird design issue you encounter, just make a ticket on the site I linked above. Leave the work to others, but at least let them know what they should fix. You’re helping them out, and when they fix it they’re helping you out. Everybody’s happy.

So if all this has motivated you to contribute your design expertise to WordPress: great! I hope to see you at a WordCamp or on Slack someday. Together, we can make WordPress even better, for everyone.

Photo by the talented Pradeep Singh.

Read more: ‘WordPress Core Contributions’ »

Reminder: How SVN on WordPress.org Works

Now that the new directory is out, it’s time for a couple quick reminders on how the SVN repositories work on WordPress. We have documentation on how SVN works here, but the information can be overwhelming.

Use readme.txt (not .MD)

A readme.md file is not the same as our readme.txt format. If you try to use one and expect everything to work right, you’ll have a bad day.

Your Stable Tag matters

This has always been the case, but it’s now more important than ever. If you say that your plugin’s stable tag is 1.2.3 but you do not have a /tags/1.2.3/ folder, your plugin will absolutely not behave as expected. If you’re not using tags folders, your stable tag should be trunk and that’s it. (But we would rather you use tags.)

Don’t use a folder for your MAIN files

Do not put your main plugin file in a subfolder of trunk, like /trunk/my-plugin/my-plugin.php as that will break downloads. You may use subfolders for included files.

The Assets folder is special

We have a dedicated folder for your plugin screenshots and banners. Want a faster, smaller, plugin? Put your assets in /assets/ and not /trunk/assets/ please. Your users will thank you. Screenshots and banner images go in that folder. It’s special. Use it wisely.

SVN is a release repository

One of the guidelines is that frequent commits to your plugin should be avoided.

Unlike Git, our SVN repository is a release repository, not a development one.  Every single commit triggers a regeneration of the zip files associated with the plugin. All the zips. That can be pretty brutal on the system. No one likes it when a plugin download breaks because the server’s down. Please be nice to our servers.

It’s okay to update your readme within reason

That said, if you need to update your readme to fix a critical public typo, do it. And if you want to update the readme to bump the version of WordPress you’ve tested up to, that’s fine too. Just keep it to the major releases. A plugin that is tested on 4.7 will show as tested up to 4.7.2 as well, after all.

 

Vision for the theme directory: Part 1

I’ve now been involved in some form or another with the theme review team at WordPress.org since late 2010. Some of that has been as an author, reviewer, and administrator. I’ve been a part of every aspect of the process. I’ve been frustrated as a theme author. I’ve been worried by code quality as a reviewer. I’ve spent numerous hours thinking about solutions as an admin.

I joined the team because I wanted to improve the process so that both other theme authors and I could get our themes out there without a lot of fuss.

What I found was that over the years, there are really a lot of people doing some sneaky things. There are a lot of security issues. And, many authors include code or assets that are not compatible with the GPL.

When you see that, you get in the mindset of assuming everything’s bad. Starting from that assumption is not always a good thing. Guilty until proven innocent. My vision of the theme directory is to come from a more optimistic viewpoint.

The ideas presented in this post are by no means all my own. They’ve been shaped and reshaped by users, theme authors, and reviewers over the years.

“That” feeling

There’s this slightly euphoric feeling when you first finish a theme. You’ve done the work and finally decided it’s time to share your work with the world. If you’re a theme or plugin author, you know what I’m talking about.

There’s a ticking clock on this feeling. If you’re not able to share your project within that window, you lose that small bit of joy of sharing your theme.

The theme review process has been killing that feeling for theme authors. When you wait for months for your theme to go live, all you’re left with is a meh feeling. There’s no more excitement about your theme. You’ve most likely already moved on to another project.

Meh

For first-time theme authors, this is even worse. Some of us have been there and done that, but for the new theme author, the process can be a huge stumbling block to someone who might become the Picasso of the theme world one day.

The theme review process

Over the past couple of years, it’s been painfully obvious that the manual review system (in its current state) simply cannot keep up with the high volume of themes.

As a reviewer, I know that many theme authors are not educated enough in a few areas:

  • Basic security, particularly with output escaping.
  • Licensing and understanding what’s compatible with the GPL.
  • Core WP functions or features that already exist.

The question has been about finding a balance. Security and licensing are definite blockers. I think everyone can agree that themes should be secure and that anything promoted on WordPress.org needs to be GPL or compatible. But, the other stuff is not so clear cut.

Should theme reviews require that theme authors use the core-bundled jQuery script? I know many plugin authors who certainly think so.

Should theme reviews require that the core WP the_content() is used in favor of some custom function to show post content? Again, it’d break numerous plugins if it didn’t.

Should reviews check that theme options actually work? I’m sure there are users who appreciate it.

That’s where a whole boatload of time is going. A lot of people are in favor of scaling back theme reviews to security and licensing. Then, allow users to up-/down-vote themes using the .ORG ratings system. It makes sense in many ways.

Long term, it may be the only way to make the process work without a fulltime, paid staff handling theme reviews.

I’m absolutely certain that this will break more plugins. I’m absolutely certain that it’ll increase .ORG support forum posts. But, if users truly use the ratings system, it could correct itself to some degree.

We can also continue building on the Theme Check plugin to block unwanted code. If we open the floodgates, it could have the benefit of us building the best code sniffs in existence.

Right now, it takes at least an hour to do a full check of some of the more basic themes. It can take several hours to check a poorly-coded theme. That’s not a good use of volunteer time. That time would be better spent improving the theme directory in other concrete ways.

Where do we go from here?

As a user, I appreciate that themes are checked for my benefit. However, I know how to give 1-star ratings.

As a theme author, I want to open things up. Check only security and licensing.

As a plugin author, I weep at the thought of all the themes that will break my plugins while relishing in the freedom that some theme authors have never known.

As a reviewer, I’m tired. We have too many reviewers who get burnt out trying to keep up with the load.

My official recommendation is for the WordPress.org theme review team is the following:

  • Only manually check security, licensing, and any other egregious issues.
  • Keep building on the guidelines because theme authors really need those.
  • Continue to iterate on the new Theme Check to catch the stuff we don’t want.
  • Give users the freedom to rate themes as good or bad.

Relying on Theme Check

We’re programmers. We write code.

It doesn’t make sense that we’re manually checking for code issues when there are tools available to automatically handle most of the load.

In order for us to make sure that themes are secure, it means making the “escaping” check an error-level notice. Basically, this means that anything Theme Check notes as an escaping issue will automatically block a theme from being submitted.

Previously, I was in favor of leaving this as a warning and manually verifying something as an issue. That puts work on the reviewer. Making it an error-level notice will put the responsibility back with the theme author, where it rightly belongs.

Even if we have false-positives, it means that theme authors will be forced to rethink how they write their code, which is mostly a good thing.

Building the guidelines

We should not do away with the guidelines. These should be the official recommendations of the team. They should also help us mold Theme Check so that it continues improving to catch the bad.

The guidelines should also be the basis for the entire handbook. The handbook should be filled with code examples of best practices.

Primarily, security and licensing guidelines should be front and center. Reviewers should manually check those. The rest are there for theme authors to follow on their own and for the team to build into Theme Check.

Side note: There’s also a scenario where theme authors might request a full “guideline review” to get a seal of approval or some sort of badge for their themes if we wanted to go that route.

Featured themes

Currently, featured themes on the WordPress theme directory are randomly chosen. This was done to make things fair. This is in large part due to some gaming of the system in the past.

I’m in favor of the admins and/or moderators of the theme directory making the decision about what themes appear in the featured themes list. This would be a curated list of themes that we think represent the best of the WordPress theme world.

No, this is not fair to everyone. I’m not arguing for fairness. I’m arguing for some of the brightest developers and designers in the WP community to hand-pick awesome themes that they notice coming through the system.

Right now, too many great themes get lost because they can’t get noticed. A big part of the team’s job should be making sure users can find these diamonds in the rough.

Trusting users to rate themes

Most of this comes down to users making liberal use of the ratings system. When they come across a theme breaking their plugins, they need to give bad ratings. When they come across a theme that works perfectly, they need to give a good rating.

The theme review team has spent much of its time protecting users from a lot of bad code and practices. But, we have to put a little responsibility into users’ hands too. In my experience, users are pretty quick to let you know about problems.

So, let’s give them the chance to do it.

If things will be bad, why do it?

I’ve outright stated that if the review team only checks for security and licensing issues, themes will absolutely break plugins. There’ll be many things that simply don’t work as they should.

Why in the world would I want that?

Because for every X number of bad themes, we’ll have a truly amazing theme that we might not get otherwise. If that’s 1 in every 100, it’s worth it to me.

I want us to open the process up and see what people can come up with.

Steps to achieve the vision

First, we need a solid Theme Check plugin that can find more security issues. That’s primarily a matter of getting the new sniffs finished.

Second, we need to complete the guidelines rewrite project. Even though reviewers wouldn’t manually check all of these, the guidelines should still be a guide to coding quality themes.

Then, it’s just a matter of pulling the trigger. Pick a date and make the switch to only reviewing the absolute essentials.

I’m ready. I know most theme authors would jump for joy at such a drastic change. Now, it’s just a matter of whether the team goes for it or can build upon this vision.

The post Vision for the theme directory: Part 1 appeared first on Justin Tadlock.

WP-CLI Names Alain Schlesser New Co-Maintainer

WP-CLI has hired Alain Schlesser as a new part-time co-maintainer. The position was made possible by sponsorships from Automattic, Bluehost, DreamHost, SiteGround, WP Engine, and more than 60 individuals who contributed to the project.

“With Alain joining the project as a co-maintainer, the WP-CLI project is restoring capacity to meet current demands (e.g. support), and ramping up on new feature development and evangelization,” WP-CLI co-maintainer Daniel Bachhuber said. “We’ve already improved the build time by 33%!”

Schlesser first became involved in the project after Bachhuber contacted him last March for input on solving some outstanding issues with Composer, which WP-CLI uses for external package management. Schlesser said he couldn’t afford the time to actively work on the issue at that time but tried to offer meaningful input for the right angle for solving the remaining issues.

“This short collaboration changed my perception about WP-CLI and helped me realize that there is a push to use modern and modular code to improve the tool and prepare it for future requirements,” Schlesser said. “So, already at that point, I wanted to contribute to the project. However, I was already involved in a different part of WordPress contribution (which is now the Nextgen Bootstrap/Load Feature Project), and I had to prioritize my volunteer work and keep a few hours left for paid client work as well.”

Schlesser said taking on the role of a maintainer became an option once it was a paid position made possible by the project’s 2017 sponsors. Prior to that he would not have been able to financially afford the additional time investment that WP-CLI requires. The new role enables him to work for 5-10 hours per week on general user support, development of new and improved features, writing documentation, managing the issue backlog, reviewing pull requests and working on the project’s infrastructure.

In joining WP-CLI as a co-maintainer, Schlesser brings a fresh perspective from developing for other platforms and years experience managing and contributing to dozens of open source projects.

“WP-CLI is in a unique place in terms of what it tries to achieve and how it does it (out of necessity),” Schlesser said. “For most other web platforms, the command line interface is a regular part of the core of the system itself, often building what is known as a Hexagonal Architecture. WP-CLI, on the other hand, achieves most of the same benefits even though it has no direct control over the Core source code, and that source code is not meant to support such an architecture. Given the obstacles, the current results are quite an achievement!”

After its 1.0.0 release, WP-CLI shifted to focus on its package ecosystem. New features are now built as standalone packages instead of rolling everything into WP-CLI core. The eventual goal is to better distribute the project’s maintenance burden among package maintainers.

“I think the most important change in the upcoming release is that all the bundled commands have been extracted into separate packages, and we’re currently in the process of getting rid of all the issues that this move has uncovered,” Schlesser said. “So, when it comes to making WP-CLI easily extensible and improving the tools and interfaces, we’re now eating our own dog food. In the longer term, I expect this change to have a significant impact on the onboarding experience for developers who want to create their own commands.”

During his years contributing to open source projects, Schlesser said he has become well-acquainted with the unique challenges and emotional toll of maintainership, a topic that Bachhuber has spoken about in the past.

“Maintenance of a popular open source project is at the intersection of the hard logic of technology and deeply human group dynamics,” Schlesser said. “I’ve become more aware of all the difficulties that come with such a role, but I wouldn’t necessarily state that I know anything more now on how to navigate around them. What I know for sure is that it is a burden that should be shared amongst several people when at all possible. It comes with constant pressure and churn, and doing this work as a single person puts both the project and the person at risk.”

Schlesser plans to keep an eye out for any avoidable friction points in hopes of making the experience of maintainership as smooth as possible for all involved.

“Daniel has already done a great job with this, and I can’t wait to see where the project will take us as a team,” Schlesser said.

Plugin Submissions ETA Reopening Early Next Week

really want to say “We’ll reopen on Monday!” but right now we’re aiming for Monday.

What’s going on?

We found some bugs that didn’t happen in testing.

For example, when we did the final import of all the pending plugins, they were in a maybe-wrong state. That meant we had to go through all our emails and logs to make sure we’d emailed everyone about their plugin status or not. That took us until Friday afternoon.

At the same time, we found some process flow bugs that were just going to make things worse all around and had to address those. It doesn’t do you any good to submit a plugin if we can’t review it, or if approvals don’t generate your SVN folder, for example! We had to document all of those to make sure things would get fixed in the right order (some of them we can live with, obviously).

The good news is that we did clean out the queue, so everyone who had a submission pending has now been emailed. Some of you twice. Sorry about that. If you didn’t get one and you think your plugin is pending, email us at plugins@wordpress.org and we can look.

Thank You Systems/Meta

Systems and Meta have been wonderful, plowing through the tickets raised. Right now, we’re prioritizing “Fix what’s broken” so the only tickets you see in the Plugin Directory v 3.0 milestone are items we feel must be fixed as soon as possible. If I’ve moved your ticket out, it’s simply because it’s not deemed mission critical at this moment, and not that it will never be addressed. It’s triage, and we were just as brutal about it on ourselves.

Thank You Too

I really do appreciate everyones patience and understanding.

Obviously things didn’t go perfectly, but considering the magnitude of this change, it’s gone smoother than I predicted (I may owe people dinner now). If you want to help us out, right now please spread the word to your fellow developers. Remember, if you can get everyone to read this blog first before they email/dm/ping for status, you make reviews go faster!

#directory, #repository

The New Directory Is (Mostly) Live

Sorry about the post-facto notice, there were a lot of moving parts and we got some things out of order when communicating between the multiple teams.

Current Status

  • Pending plugins are imported
  • Approved (but not yet committed) plugins are being imported
  • Rejected plugins have not yet been imported (though they will be … all 23k of them)

Known Issues

Beside everything listed on Meta Trac, we are aware of the following issues:

  • Header images are pixelated
  • Plugin submissions are disabled

Plugin Submissions are Currently Closed

THERE ARE NO PLUGIN APPROVALS GOING ON AT THIS TIME

You can’t submit a new one for approval, and we won’t be approving anything until possibly tomorrow at the earliest.

I will post here (make/plugins) as soon as we reopen and start things moving along, but please don’t ask for a status update. If it’s not posted here, we don’t have one, and you’ll just make everything take longer.

Plugins Will No Longer Be Rejected After Seven Days

Before you panic, we’re not going to reject plugins after 7 days anymore. The queue will be handled differently so having old plugins with no replies is less of a problem. Also? We’ll be able to rename your plugin slug before approval, so that will take care of most things like `google-analytics-by-faro` 😁 and other obvious typos.

However. This means the onus is now even more on you to make sure you whitelist emails from `wordpress.org` in your email servers. A high volume of people never see the first email (the ‘please fix’) and only see the followup of 7-days, so now you won’t be getting that anymore.

#announcement

Ask Yoast: Impact of host location on SEO?

Do you want to set up a brand new website or move your website to a new host? Choosing a web host can be hard, because there are thousands of hosting companies out there. So it’s a tough decision to make, but a very important one too. When you’re comparing various hosting aspects, should you consider the location of the web host too? Is the geographic location of their web server important for SEO? Hear what we have to say about this, in this Ask Yoast.

Gerardo Garcia emailed us, asking:

“Do you consider the location of the web server as something important for SEO?”

Check out the video or read the answer below!

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO for WordPress pluginBuy now » Info

Impact of server location on SEO

“Gerardo Garcia is from Spain and he has found web servers in Germany and England that are cheaper than the ones in Spain. He’s wondering if the location of a web server is important for SEO.

First of all, no, not really. But that’s not the entire truth. Because for your visitors you want the most speed, and you’ll get the most speed by hosting as close as possible to them. And you can achieve that by hosting your site in the country where your visitors are coming from.

We’re Dutch, but our main servers are in the US. Why? Well, because the majority of our visitors are from the US. We also have a server in Europe, because we get many visitors from Europe too. So think about that. Of course, we are on a slightly more expensive set up than you would probably be, and need to be. So focus on the country you think is the most valuable.

To be honest, if you’re looking at price too much for you hosting, you probably not doing yourself any service anyway. Don’t go for the cheapest hosting, go for the best hosting. Paying a couple of bucks more per month, really is worth it, When your site is down otherwise, stuff is just not working.

So, I would suggest going with a host that has servers in Spain or at the very least have people that can service you in Spanish in Spain. And then, whether these servers are located in Barcelona or in London, the technical existence of these servers doesn’t make too much of a difference.

Good luck!”

Ask Yoast

In the series Ask Yoast we answer SEO questions from followers. Need some advice about SEO? Let us help you out! Send your question to ask@yoast.com.

Read more: ‘Yoast’s WordPress hosting list’ »

How to Create a Local WordPress Site Using XAMPP

Do you want to create a local WordPress site on your computer using XAMPP? Installing WordPress on your computer helps you try out WordPress, test themes / plugins, and learn WordPress development. In this article, we will show you how to create a local WordPress site Using XAMPP.

Create a local WordPress site using XAMPP

Why Create a Local WordPress Site?

Creating local WordPress sites is a common practice among developers and site owners. It allows you to test WordPress without creating an actual website on the internet.

Local websites are only visible to you on your computer. You can try different WordPress themes and plugins, test their features, and learn the WordPress basics.

If you already have a WordPress website, then you can create a local copy of your website on your computer to try out new plugin updates before implementing them on your live website.

Important: Local website will only be visible to you on your computer. If you want to build a live WordPress site, then you will need a domain name and WordPress hosting. Follow the step by step instructions in our how to start a WordPress blog guide when you are ready to create a live website.

Having said that, let’s check out how to install WordPress locally on Windows, Mac, or Linux using XAMPP.

What is XAMPP?

In order to create a local WordPress site, you will need to set up a web server software (Apache), PHP, and MySQL on your computer.

PHP is a programming language and MySQL is a database management software. Both of them are required to run WordPress.

Installing each of these software separately is quite difficult for beginners. This is where XAMPP comes in.

XAMPP makes it easy for you to build WordPress websites locally. It is available for Windows, Mac, and Linux based computers.

Let’s get started.

Installing XAMPP on Your Computer

First, you need to visit the XAMPP website and click on the download button for your operating system.

Download XAMPP

Depending on your operating system, your installation wizard and the application interface may differ from the screenshots here. For the sake of this article, we will show you the Windows version of the software.

After downloading XAMPP, you will need to click and run the installer.

XAMPP setup wizard

XAMPP will ask you where you want to install the software and which packages you’d like to install. The default settings will work for most users. Keep clicking on ‘Next’ to finish the setup wizard.

After finishing the wizard, check the ‘start the control panel now’ option and then click on the finish button.

Setup finished

This will launch the XAMPP control panel. Go ahead and click on the start button next to Apache and MySQL.

Start Apache and MySQL

XAMPP will now start Apache and MySQL. You may see a Windows Firewall notification, it is important that you click on ‘Allow Access’ button for both applications to run on your computer.

Allow firewall access to Apache and MySQL

Once both applications are started their names will be highlighted in Green.

You have successfully installed XAMPP on your computer.

Now you are ready to create a local website and install WordPress using XAMPP.

Creating a Local WordPress Site with XAMPP

First, you will need to download WordPress. Visit the WordPress.org website and click on the ‘Download WordPress’ button.

Download WordPress

After downloading WordPress, you need to extract the zip file, and you will see a wordpress folder. You need to copy this folder.

Copy WordPress folder

Next, head over to your XAMPP installation folder.

On Windows it would be C:/Program Files/XAMPP/htdocs or C:Xampphtdocs folder.

On Mac, it will be /Applications/XAMPP/htdocs folder.

Paste the wordpress folder you copied earlier inside htdocs.

Rename WordPress folder

We recommend renaming the wordpress folder to website1. This will help you easily identify your local site.

Next, you need to open your favorite web browser and visit localhost/website1. You will see a page like this:

WordPress pre-setup

This page will tell you that WordPress needs a database name, database username, password, and host information.

Let’s create a database for your WordPress site.

You’ll need to open a new browser tab and visit localhost/phpmyadmin/. This will launch phpMyAdmin app that comes pre-installed with XAMPP. It allows you to easily manage your databases using a simpler interface.

You would need to click on Databases, provide a name for your new database, and then click on the create button to continue.

Creating a MySQL database for your local WordPress site

Now that you have created a database, you can use it for your WordPress site.

Switch back to /localhost/website1/ browser tab and click on the ‘Let’s Go’ button.

On the next screen, you will be asked to provide your WordPress database information.

Enter the database name you created earlier. Your username is ‘root’ and you should leave the password field blank. For the database host field, you need to use localhost.

See the screenshot below:

Connect your WordPress database

Once you are done, click on the ‘Submit’ button to continue.

If you are on Windows or Linux, WordPress will now store these settings in your WordPress configuration file called wp-config.php file.

However, if you are on Mac, then it will show you the contents of the file and will ask you to create it.

You will need to create this file in your website’s root folder.

After creating the file, paste the text you copied earlier inside it. Next, you need to save the file and return back to WordPress installer to continue.

In the next step, WordPress will ask you to provide information about your website. First, enter the title you want to use for this site.

After that you need to enter a username, password, and an email address for your admin account.

Enter your WordPress website info

Once you have filled all the information, click on the ‘Install WordPress’ button to continue.

WordPress will now run the installation and prompt you to login once it’s done.

You can login to your website by going to /localhost/website1/wp-admin page and use the username / password that you entered during installation to login.

WordPress login screen

Things to Try After Creating a Local WordPress Site

Now that you have created your local WordPress site using XAMPP, you can work on it like you would do on a live WordPress site.

Head over to Appearance to customize your site’s appearance or install a new theme. Here are some great free themes that you can try.

The next thing you would want to try is WordPress plugins. Plugins are like apps for your WordPress site and allow you to add cool features like contact form, photo galleries, eCommerce store, etc.

Need help installing plugins? See our step by step guide on how to install a WordPress plugin.

After working on your local WordPress site you may want to move it to a live server. Head over to our step by step guide on how to move WordPress from local server to live site.

We hope this article helped you learn how to create a local WordPress site using XAMPP. You may also want to look at alternate ways to create local WordPress sites on Windows using Wampserver, and on Mac using MAMP.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Create a Local WordPress Site Using XAMPP appeared first on WPBeginner.

Adding Images to WordPress Sidebars Is About to Get a Lot Easier

Adding images to sidebars in WordPress is a cumbersome task that requires users to upload an image to the Media Library, find the URL, copy it, and paste it into a Text widget along with additional HTML. Nearly two years ago, Mel Choyce opened a ticket on WordPress Trac proposing that a media widget be added to core. This widget would allow users to easily add images to sidebars.

Throughout the discussion, the idea of creating a catch-all media widget was brought up that would allow users to add images, audio, or video to a sidebar. After developers spoke to Matt Mullenweg about the direction of the project, the team decided to create three separate widgets to handle each media type. Choyce outlined the benefits this approach provides:

  • We can focus on creating more tailored experiences for each widget.
  • We’ll be able to launch new widgets without having to worry about constantly updating one central widget, or potentially breaking anything.
  • It’ll be easier for people to discover new media types since they won’t be buried within one widget.
  • This will more closely mimic the approach we’re taking to content blocks in the future, which should provide an easier transition.

Out of the three core widgets in development, the Image one is nearly complete ready for user testing. To test, first download and activate the Core Media Widgets plugin. Once activated, navigate to Appearance > Widgets in the WordPress backend and in the available widgets section, locate the Image widget.

Core Image Widget UI
Core Image Widget UI

Clicking the Select Image button displays the media library modal where you can either select or upload an image. Once an image is selected, click the Add to Widget button in the bottom-right corner. This is what the widget looks like after an image is added.

Core Image Widget With an Image
Core Image Widget With an Image

Here is what the widget looks like on a page using the Twenty Seventeen default theme.

Core Image Widget in Action
Core Image Widget in Action

The core image widget is incredibly easy to set up and is a significant improvement over the Text widget approach. The user interface is much simpler compared to the image widget supplied by Jetpack. Jetpack’s image widget UI doesn’t take advantage of the media library modal and instead, requires the user to know the image’s URL.

Jetpack Image Widget UI
Jetpack Image Widget UI

Many of the fields are the same as what’s provided by the media library modal. Not surprisingly, WordPress.com uses the same interface and requires the user to know the image URL.

Core Image Widget May Be Ready in Time for WordPress 4.7.4

The team is specifically seeking feedback from those who use image widgets provided by plugins on WordPress.org. Once the image widget is merged into core, the video and audio widgets will be added to the Core Media Widgets plugin. Users can leave the plugin enabled until all three widgets are added to core.

“Once a widget has been thoroughly tested by users, we can then copy it into core for a release while then also disabling the widget in the plugin,” Ruter said.

If you encounter a bug or discover an incompatibility with a plugin or theme, please create an issue on the project’s GitHub page. According to Ruter, the team is working hard to get the widget to a point where it can be merged into core. Depending on how testing goes, it could be merged into core as early as WordPress 4.7.4.

Yoast SEO 4.5: update your PHP version

This is a rather special release, as it’s a project that’s close to my heart. It’s not a full-featured release, however, it is just necessary as a regular release. In Yoast SEO 4.5, we are urging site owners whose sites run on servers with an outdated version of PHP to update to a more recent version. To move the web forward, we need to take a stand against old, slow and unsafe software. Updating to PHP 7 will give your site an enormous speed boost. In this post, you’ll find out why we’re showing this notice in WordPress and what you can do to upgrade PHP.

Please read this post to get the complete picture of this move »

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO for WordPress pluginBuy now » Info

Why this move?

WordPress is built on PHP. This programming language takes care of the heavy lifting for the CMS. WordPress was always built with backward compatibility in mind, but we’ve reached a point where that’s just not feasible anymore. WordPress needs a minimum of PHP5.2 to function, but that version will not get updates, fixes or patches. This makes it inherently insecure. If you are on an old version, Yoast SEO 4.5 will show you a message in the backend. Please update to at least 5.6, but rather PHP 7 to take advantage of all the awesomeness of this new version. Not just for you as a user, but for developers as well.

The why is three-pronged: security, speed, and future-proofing. PHP 5.2 hasn’t been updated for years and has serious issues. PHP 7 is lightning fast, up to 400% faster than 5.2. You might even regard this as a green move; you can use 50% fewer servers to get the same results from PHP 7. Last but not least, developers can finally use all the modern technologies to bring WordPress to the next level.

We understand this move might be annoying for some, but it is necessary to speed up the development of the web and to bring it some must needed security. That being said, updating your PHP version is rather easy.

How can I update my PHP version?

How to update your PHP version depends on your host. Most hosts have an article on their site explaining how to update PHP yourself. Here’s the one from SiteGround, or WP Engine. Go to your hosts’ website to find out more on how to go about this. If you can’t find the information you need, please contact your web host. We have made an example email that you can edit and send to your hosting company.

Don’t forget to backup your site before doing any major changes!

And how do I choose a different hosting company?

It might be entirely possible that your host is not willing to work with you. Maybe you just don’t feel valued at your current host or it could be that their future plans don’t fit yours. If so, think about moving web hosts. A web host provides the engine your site runs on and that better be a damn good engine. To help you with your quest for a well-regarded and forward-thinking web host, we’ve compiled a list of hosting services that got the Yoast stamp of approval.

Read more: ‘Whipping your hosting into shape’ »