How to create a 301 redirect in WordPress

There will be times where you want to redirect visitors to a different part of your website when they visit a particular page or post. Reasons for this can be that you renamed a post and its URL, a page was removed or you want a different page to rank.

Redirects in a nutshell

The name ‘redirect’ pretty much says it all: It sends visitors traveling to a specific page to an alternative one. But what does this 301 mean and how does it differ from a 302 redirect? Both send your users to a different page. The only subtle (yet very important) difference is that a 301 will permanently send visitors and search engines to the new destination. 302 redirects indicate that you only temporarily want visitors to be sent to a different page.

Creating a 301 redirect on the server

One of the most basic methods of adding a 301 redirect, is by editing your .htaccess file on the server. This method is only available on Apache servers. Nginx has their own way of defining redirects in the server configuration and requires extensive knowledge of system administration.

These configurations can get quite unmaintainable over time, especially if you’re an avid blogger or you’re trying to improve the SEO of your posts. On top of that, you would have to log in on your server over FTP, edit the files and re-upload them every time you add a new redirect. That’s why, generally speaking, using this method is not considered the way to go.

Creating a 301 redirect with PHP

As a WordPress developer, you have two options: Either you make a redirect by altering the headers of a file in the code -or- you make use of WordPress’ built-in
wp_redirect function.

An example of plain PHP could be as follows:

// MyExampleFile.php
header("HTTP/1.1 301 Moved Permanently"); 

And this is how you’d do the same, but now by using WordPress’ built-in function:

wp_redirect( get_permalink( ), 301 );

If you forget to add the 301, both WordPress and PHP will both assume that it’s a 302 redirect, which isn’t always the case.

This method is a bit easier than editing files on the server, but can also become cumbersome once the amount of redirects increases.

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

Yoast SEO for WordPress pluginBuy now » Info

Creating a 301 redirect with Yoast SEO

Our Yoast SEO Premium plugin offers you a helping hand when it comes to creating these redirects. Our built-in Redirect manager assists you whenever you change the URL of a post, page or any of the taxonomies that may result in a possible 404 if you don’t properly redirect visitors.

In addition, we also offer you an interface to edit or remove these redirects at a later point in time. The plugin also tells you when you’re about to create a redirect that will result in a redirect loop. This looping is something you want to avoid at all costs.

Read more: ‘How to properly delete pages from your site’ »

WP REST API Content Endpoints Officially Approved for Merge into WordPress 4.7


After a lengthy and impassioned meeting in the WordPress #core Slack channel on Monday evening, the WP REST API content endpoints were conditionally approved for merge into 4.7. Since that time Brian Krogsgard published a document with input from the team on how they plan to measure the success of the API.

The conditions included some last minute work from the team on demonstrating how the API can benefit core development. Contributors produced multiple proofs of concept, including leveraging the REST API endpoints for Press this and Quick Draft features.

“I think the team has come together really well over the last couple days to tackle the merge tasks,” WordPress core committer Jeremy Felt said. “It seems that the momentum is on the right track to merge and then continue knocking out issues throughout the rest of the cycle as we start testing it as part of core. I’m also pretty excited about the pieces of the admin that are about to start using it with such a short window. 4.8 and 4.9 have a ton of potential with the API.”

Contributors in attendance at today’s core development meeting agreed that the team had made significant strides to meet the conditions previously identified for merge. After a short few minutes of discussion, WordPress 4.7 release lead Helen Hou-Sandí officially approved the WP REST API content endpoints for merge into core.

Code on the GitHub repository will now be frozen and continued development will be managed via WordPress trac. The WP REST API has had 99 contributors on the project to date. The content endpoints identified in the merge proposal will ship with WordPress 4.7 and contributors will focus on authentication for the 4.8 release cycle.

WordPress 4.7 to Ship with Infrastructure from the Customize Snapshots Feature Plugin

photo credit: Chantel Lucas
photo credit: Chantel Lucas

Customize Changesets, the technical term for the infrastructure in the Customize Snapshots feature plugin, was merged into WordPress 4.7 yesterday. The project, formerly known as Customizer Transactions, brings the underlying architecture required for the ability to save a session as a draft. It enables WordPress to save a set of changes made in the Customizer so that it can be shared, previewed outside of the iframe, and even published at a future date.

Although the initial introduction of Customize Changesets will ship with no UI, it is the gateway for a host of exciting new features in the Customizer.

“The new APIs make possible many new user-facing features in future releases and feature plugins, including saving long-lived drafts, submitting changesets as pending for review, scheduling changes, seeing the previewed state on the frontend without being in an iframe, sharing preview URLs with others who do not have customizer access, and others,” project lead Weston Ruter said in the merge proposal.

Users will be able to detect the Customize Changesets architecture in WordPress in two ways. A new customize_uuid query parameter is added onto the URL. Also, users can now reload pages in the Customizer and the changes that have already been made will persist.

“In future releases we can explore new UIs to take advantage of the new capabilities that changesets provide,” Ruter said. “New UIs can provide a way to schedule changes, the ability to undo the last change, show an audit log (revision history) for changes, collaborative editing of a customizer changeset, and so on. Future feature projects will explore many of these and feature plugins will start to prototype them.”

Ruter also noted that Customize changesets fixes “several long-standing issues related to incompatibilities between JavaScript running on the site’s frontend when previewed in the customizer.” This should make the experience of customizing WordPress less buggy for users.

When I asked Ruter if the UI for core will come from the Customize Snapshots feature plugin, he said he’s not certain whether the team will migrate the features into a separate “Customize Changesets UI” plugin or adapt it to make use of changesets instead.

“Either way, the UI features will live on and will be prototyped in feature plugin form before proposal for core merge,” Ruter said. “The underlying plumbing from Snapshots was adapted for changesets now in core. So the snapshots itself needs its internals to be gutted to re-use changesets.”

From there contributors will begin building a UI for managing changesets, which includes listing existing changesets and their revisions, as well as moving a changeset post from auto-draft to draft, pending, or future. Ruter encourages those who want to contribute to a changesets UI for core to get involved in the Customize Snapshots plugin on GitHub.

How to Reset WordPress Admin Password on Localhost

Recently, one of our users asked us how to reset WordPress admin password on localhost? If you are running WordPress on localhost and forget your password, then you can’t reset it by email. In this article, we will show you how to reset WordPress admin password on localhost.

How to reset WordPress admin password on localhost

Why Password Reset Doesn’t Work on Localhost?

The term localhost is used to describe a local server that is not available to the general public. For example: your personal computer.

Many WordPress users install WordPress on localhost (in their computer) to test changes, design websites, try out new plugins, and even learn WordPress.

If you haven’t tried it, then see our tutorial on how to install WordPress on your Windows computer using WAMP.

Mac users can follow instructions in our tutorial on how to install WordPress locally on Mac using MAMP.

Now here is the problem that some beginners may come across.

If you forget your WordPress admin password while working on localhost, then you will be NOT be able to reset it using the normal password reset option in WordPress.

The password reset option emails you a link to reset your WordPress password. In order to send emails, your server needs to enable the mail function.

This function is turned off by default on local servers which means WordPress will not be able to send the password reset email.

But don’t worry, there’s a way to reset your WordPress password on localhost.

Ready? Let’s get started.

Reset WordPress Admin Password on Localhost

We will be using phpMyAdmin to reset password on localhost. Simply visit phpMyAdmin control panel by typing this URL in your browser’s address bar:


You will be asked to provide your MySQL username and password. Typically, the username is root with no password.

Once you are logged in, you need to select your WordPress database.

Select database

Once you select your database, you will see a list of tables in your WordPress database. Go ahead and click on the browse link next to WordPress users table.

Users table in WordPress database

You will now see the list of entries in your users table. The number of rows depend on how many users are registered on your WordPress site.

Next, you need to click on the Edit link next to the username of the admin user.

Browsing users table in WordPress DB

This will open up a form where you can edit the information stored in WordPress database for that user.

Changing user password

Scroll down to user_pass field and type a new password in the ‘value’ column. After that you need to select MD5 in the ‘function’ column.

Don’t forget to click on the Go button at the bottom to save your changes.

That’s all, you can now login to your WordPress site on localhost using the new password.

If for some reason you’re having a hard time following the phpMyAdmin method, then please look at our guide on how to create a WordPress admin user using your functions.php file. Simply open your theme’s functions.php file and paste the code in the article above, and you’ll be good to go.

We hope this article, helped you learn how to reset WordPress admin password on localhost. You may also want to see our guide on how to how to move WordPress from local server to live site.

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 Reset WordPress Admin Password on Localhost appeared first on WPBeginner.

WP REST API Content Endpoints Conditionally Approved for Merge in 4.7


The WP REST API team and WordPress core contributors met tonight to decide whether to merge the content endpoints in 4.7. After the merge proposal was published a week ago, several core developers expressed concern regarding the brokered authentication scheme and the team has since decided to remove it from the proposal in favor of focusing on it for the 4.8 development cycle.

Discussion at the meeting tonight centered around six topics: security, performance, user feedback, if merging will negatively impact API development, whether content endpoints will benefit core development, and whether those endpoints belong on every WordPress site. The team also discussed possible ways to measure the success of the project once it has been merged into core.

Contributors agreed on a conditional approval for merging the endpoints, provided that the team address outstanding questions on object meta and that others outside of the REST API team provide a proof of concept for how WordPress core can use the endpoints. These conditions must be met before the enhancement deadline next Wednesday.

“Making something work in core does not mean committing it to trunk,” WordPress 4.7 release lead Helen Hou-Sandí said. “This is also a call to the greater dev community – there is a chance to do something that doesn’t necessarily carry the weight of being shipped in core that can serve as proof that you want something. A developer’s vote.”

Hou-Sandí said that requiring the proofs to be created by developers outside of the REST API team will demonstrate “how other people experience the development process.” It also frees up the project’s team to focus on other pre-merge tasks.

Multiple proofs of concept are encouraged and some of the features being considered include Press This, Quick Draft, infinite scroll on admin list tables, and anything else anyone wants to try. Adam Silverstein volunteered to take a crack at Press This and by the conclusion of the meeting said, “I’ve got Press This creating new posts already actually, that was pretty straightforward to switch over.” He plans to include his work in a new ticket on trac.

“I have no blocking objection but I am pretty wary and want to make sure that conditions for keeping in 4.7 are hammered out in the next 24 hours and conditions for beyond worked on before beta,” Hou-Sandí said. Matt Mullenweg, who has been one of the most vocal critics of the project’s readiness so far, agreed with her statement but also said he isn’t yet satisfied with how the team plans to measure the success of the project.

“I also feel like the measure of success is still woefully undefined, and there’s still a lot of fuzziness in the core arguments of ‘if this is in [core] people will use it more,'” Mullenweg said.

Contributors seem very motivated in the final stretch and are working towards producing the necessary proofs of concept prior to the enhancements deadline. If any of the proofs are solid enough to be merged, the WP REST API content endpoints will ship in WordPress 4.7 alongside a core feature that is using the API.

WordPress Post Navigation Redux (New Tags!)

For years WordPress post navigation has been possible thanks to a flexible set of five functions, including posts_nav_link(), next_post_link() and next_posts_link(). These navigational functions continue to work great in many WordPress themes, but there are newer, even more flexible functions available to theme developers. Introduced in WordPress 4, these new navigation functions can make it easier than ever to display nav links for your WordPress-powered posts.


Building SaaS with WordPress – a WordCamp Netherlands 2016 Talk Slides

WordCamp Netherlands is over now and it was a pleasure giving a talk at the very end of the second day of presentations. Surprisingly the room despite of the three long days of contributing to WordPress and a number of great WordPress talks for developers, designers, bloggers, business owners, marketers and other industry experts and people joining the WordPress community.

Photo credit:
Photo credit:

That’s the spirit and I’m looking forward to attending more events with motivated enthusiastic people eager to learn more about the community, business and technical ecosystem and participating at 100%!

Here are the slides of my talk:

We have been building Software as a Service applications for a few years now and we have faced numerous problems from technical standpoint, organizing the ongoing management and continuous development process, marketing gotchas, defining the pricing model right and selling through different venues.

Videos are being processed by the organizing team over the next few weeks, but if you have any specific questions, feel free to post a comment or get in touch with me or DevriX.

The post Building SaaS with WordPress – a WordCamp Netherlands 2016 Talk Slides appeared first on Mario Peshev on WordPress Development.

How to Start an Online Store in 2016 (Step by Step)

Do you want to start your own online store? We know that building an online store can be a terrifying thought especially when you are not a techy. Well, you’re not alone. After helping hundreds of users start their online store, we have decided to create the most comprehensive guide on how to build your online store with WordPress (step by step)

How to build an online store

What Do You Need to Start an Online Store?

There had never been a better time to start an online business than today.

Anyone with a computer can get started within a matter of minutes and without acquiring any special skills.

The three things you need to start an online store are:

  1. A domain name idea (this will be the name of your online store i.e
  2. A web hosting account (this is where your website lives on the internet)
  3. Your undivided attention for 30 minutes.

Yep, it is really that simple.

You can setup your own online store with WordPress in less than 30 minutes and we’ll walk you through each step of the process.

In this tutorial, we will cover:

  • How to Register a Domain Name for Free
  • How to Choose the Best Web Hosting
  • How to Get a SSL Certificate for Free (required for accepting payments)
  • How to Install WordPress
  • How to Create a WooCommerce store
  • How to Add Products in your Online Store
  • How to Select and Customize Your Theme
  • How to Extend Your Online Store with Plugins
  • Learning to Learn WordPress & Grow Your Business

Ready? Let’s get started.

Step 1: Setting up Your Online Store Platform

The biggest mistake most users make is not choosing the right platform for their online store.

Thankfully you’re here, so you won’t be making that mistake.

There are two popular eCommerce platforms that we recommend: Shopify or WordPress + WooCommerce.

Shopify is a fully hosted eCommerce solution that starts at $29 / month. It’s a hassle-free solution where you just login and start selling. The downside to Shopify is that it gets quite expensive, and your payment options are limited unless you pay additional fees.

This is why most users choose WordPress + WooCommerce because of the flexibility it offers. It does require some setup, but it’s worth doing it for the long run. WooCommerce is the world’s largest eCommerce platform.

In this tutorial, we will walk you through how to setup an online store in WordPress using WooCommerce.

To setup your store, you need to have a domain name, web hosting, and a SSL certificate.

A domain name is your website’s address on the internet. It is what users will type in their browsers to reach your website (for example: or

Web hosting is where your website lives on the internet. It’s your website’s house on the internet. Every website on the internet needs web hosting.

SSL certificate adds a special security layer on your website, so you can accept sensitive information such as credit card numbers and other personal information. This is required for you to accept credit card payments on your website.

Normally a domain name costs around $14.99 / year, web hosting costs around $7.99 / month, and SSL certificate costs around $69.99 / year.

That’s a lot of startup cost.

Thankfully, Bluehost, an official WordPress and WooCommerce recommended hosting provider, has agreed to offer our users a free domain name, free SSL certificate, and a discount on web hosting.

Basically, you can get started for $12.95 / month.

→ Click here to Claim this Exclusive Bluehost offer ←

Bluehost is one of the oldest web hosting companies, started in 1996 (that’s before Google). They are also the largest brand name when it comes to WordPress hosting because they host millions of websites including our own.

NOTE: At WPBeginner we believe in transparency. If you sign up with Bluehost using our referral link, we will earn a small commission at no extra cost to you (in fact, you will save money and get a free domain). We would get this commission for recommending just about any WordPress hosting company, but we only recommend products that we use personally use and believe will add value to our readers.

Let’s go ahead and purchase your domain + hosting + SSL.

Open up Bluehost in a new window using this link and follow along.

First thing you need to do is click on the green Get Started Now button to get started.

Bluehost Signup

On the next screen, select the plan that you need (starter and plus are the most popular).

After that, you will be asked to enter the domain name for your website.

Choose domain

Lastly, you will need to add your account information and finalize the package info to complete the process. On this screen, you will see optional extras that you can purchase.

It’s entirely up to you whether or not you purchase these, but we generally don’t recommend purchasing these. You can always add them later on, if you decide that you need them.

Hosting addons

Once completed, you will receive an email with details on how to login to your web hosting control panel (cPanel). This is where you manage everything from support, emails, among other things.

Go ahead and login to your cPanel. You will be greeted with a popup informing you that WordPress with WooCommerce is pre-installed on your website.

Bluehost first login

You just need to click on ‘Login to your site’ button, and it will take you to your WordPress site’s dashboard.

Congrats, you have finished setting up hosting and domain part.

The next step is to setup your WordPress site and then your online store.

Step 2. Setting up WordPress

Bluehost has automatically installed WordPress and WooCommerce on your website.

When you first login to WordPress, you will see a welcome message. You will be asked what kind of website you want to set up.

Welcome screen

Go ahead and click on ‘I don’t need help’ link. Don’t worry we will walk you through all the necessary steps.

Closing the setup wizard will show your WordPress admin dashboard which looks like this:

WordPress admin dashboard

First, you need to visit Settings » General page to setup your WordPress site title and description.

Set your WordPress site title and description

Setting up HTTPS to Use SSL

Your WordPress hosting package came with a free SSL Certificate. This certificate is pre-installed for your domain name. However, your WordPress site needs to be configured, so it loads as https vs http.

On the Settings » General page, you need to change your WordPress Address and Site Address to use https instead of http.

Change WordPress URL to use HTTPS

Don’t forget to scroll down to the bottom of the page and click on the save changes button to store your settings.

Your basic WordPress setup is complete. Now it is time to setup your online store.

Step 3. Setting up Your WooCommerce Store

Before you can start selling, there are a few things like currency, payments, and shipping information that you need to set up.

You will be seeing a ‘Welcome to WooCommerce’ notification on your WordPress admin pages. Go ahead and click on the ‘Run setup wizard’ button in the notification.

Run WooCommerce setup wizard

This will launch the WooCommerce setup wizard where you need to click on the ‘Let’s go’ button to get started.

WooCommerce setup wizard step 1

WooCommerce needs few essential pages for cart, account, shop, and checkout. You can click on the continue button to automatically create these pages.

WooCommerce pages

This will bring you to the next step.

Now you will need to tell WooCommerce where your store is located and which currency and unit measures to use.

Choosing locale and currency

After selecting your location and currency, click on the continue button to move on.

Next, you need to enter shipping and tax information.

WooCommerce shipping and tax information

WooCommerce can be used to sell both digital downloads and physical goods that need shipping.

You need to check the box if you will be shipping goods, or you can leave it unchecked if you will only be selling digital goods.

Next you need to answer the tax question. WooCommerce can help you automatically calculate and add taxes to your prices.

If you are not sure, then you can leave it unchecked. You can always add tax information later from WooCommerce settings.

Click on the continue button to move on.

Next, you will be asked to choose a payment method for your online store.

WooCommerce payment method

By default, WooCommerce comes with support for PayPal, PayPal Standard, and Stripe payment gateways. There are many other payment methods available for WooCommerce which you can install later if you need.

The easiest way to accept payment is using PayPal Standard.

Simply enter your PayPal email address and click on the continue button.

A lot of people including us, use both PayPal and Stripe. By using Stripe, you allow your users to enter their credit card information on the checkout page without having to leave your site and going to PayPal.

You can setup Stripe by following the instructions on the WooCommerce screen.

Once you’re done, your WooCommerce online store is all setup.

WooCommerce setup finished

You need to click on the ‘Return to WordPress dashboard’ link to exit the setup wizard.

After finishing the WooCommerce setup, you are now ready to add products to your online store.

Step 4. Adding Products to Your Online Store

Let’s start with adding the first product to your online store.

You need to visit Products » Add New page to add a new product.

Add new product

First, provide a title for your product and then some detailed description.

On the right hand column, you will see the ‘Product Categories’ box. Click on the ‘+Add New Product Category’ to create a category for this product. This allows you and your customers to sort and browse products easily.

Add product category

Scroll down a little and you will notice the Product Data box. This is where you will provide product related information like pricing, inventory, shipping etc.

Enter product data

Below product data box, you will see a box to add product short description. This short description will be used when users are viewing multiple products on a page.

Product short description

Lastly, on your right hand column you will see boxes to add a main product image and a product gallery.

Product images

Once you are satisfied with all the product information you have added, you can click on the Publish button to make it live on your website.

Repeat the process to add more products as needed.

Step 5. Select and Customize WordPress Theme

Themes control how your WordPress sites look to the users when they visit it. For a WooCommerce shop, they also control how your products are displayed.

There are thousands of paid and free WordPress themes available.

Your Bluehost hosting account, automatically installs the Storefront theme for your website. You will need to customize it to meet your needs.

Head over to Appearance » Customize page. This will launch theme customizer where you can change different theme settings.

Customizing your theme

If you don’t like the Storefront theme, then you can use another theme by visiting Appearance » Themes page.

Change theme

If you need help selecting a theme, then please refer to our guide on 9 things you should consider when selecting a perfect WordPress theme.

Step 6. Extend Your Online Store With Plugins

Now that you have your online store ready, you probably want to get started with adding other usual elements on your website such as a contact form, about page, and more.

To further customize WordPress and add features like contact forms, galleries, sliders, etc, you need to use WordPress plugins.

WordPress plugins are apps that allow you to add new features to your website.

There are over 46,000 WordPress plugins available. At WPBeginner, we feature the best WordPress plugins to help you add the functionality that you need.

We have a step by step guide on how to install a WordPress plugin.

Here’s a list of 24 must have WordPress plugins for business websites and another one with 20+ best free WooCommerce plugins.

Often readers ask us which plugins do you use on your website. You can check out our Blueprint to see the list of plugins and tools that we use.

Learning WordPress to Grow Your Online Business

WordPress is incredibly powerful and WPBeginner is the largest free WordPress resource site for beginners.

At WPBeginner, our main goal is to provide cutting-edge helpful WordPress tutorials that are easy to understand even for non-techy WordPress website owners (see more about us).

You can also subscribe to WPBeginner’s YouTube Channel where we regularly share video tutorials to help you learn WordPress.

We also have a guide to show users how to make the most out of WPBeginner’s free resources.

Many of our users type their question in Google and just add wpbeginner at the end of it. This shows them related article from WPBeginner.

We hope that this tutorial helped you learn how to build an online store. You may also want to see these 19 actionable tips to drive traffic to your new WordPress site.

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 Start an Online Store in 2016 (Step by Step) appeared first on WPBeginner.

Stop WordPress from modifying .htaccess

By default, depending on file permissions, WordPress automatically will change your site’s .htaccess file. It does this on several occasions, adding and/or updating the rewrite rules required for permalink functionality. This post explains how this works, why it can be dangerous, and how to stop it from happening.

What WordPress does

When permalinks are enabled on your site (under General > Permalinks), WordPress automatically will modify your .htaccess file with the latest rewrite rules. So if your .htaccess file has owner write access (very common), WordPress will write to the file with a block of directives similar to the following:

# 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]

# END WordPress

As far as I know, this only applies to non-Multisite WP installations (i.e., WP doesn’t automatically add the rules required to enable WP Multisite, although I could be wrong about this). In any case, for regular WP installations, WordPress will add these rules whenever permalinks are invoked. Here are some details:

  • # BEGIN WordPress and # END WordPress serve as markers used by WordPress
  • If the markers do not exist, the permalink rules will at added at the end of the .htaccess file
  • If the markers do exist, whatever code located between the markers will be updated automatically
  • So you can move your permalink rules (to someplace other than at the end of the file) by moving the entire block of code (markers included)
  • If you have customized your permalink rules between the markers, the changes will be overridden by WordPress
  • There is no way to remove the empty line before the closing marker :(

So the big moral of the story here is that you need to add any custom .htaccess rules outside of the BEGIN and END markers. Otherwise WordPress will overwrite them with the default permalink rules.

Why its bad

So given the previous points, if you have:

  • Custom permalink rules inside of the BEGIN and END markers, they will be lost
  • Custom permalink rules outside of the markers (e.g., not using any markers), then WP will add another set of rewrite rules at the end of the .htaccess file

Either of these scenarios can be dangerous, especially if the custom rules are required for site functionality, navigation, etc.

For example, at my WordPress Bookstore, I use custom permalink rules to account for variations in store items, custom/short URLs, and more. So in my .htaccess file, the permalink rules are highly customized, and proper store functionality depends on a very carefully crafted set of directives.

So because the block of custom rules is not wrapped with BEGIN/END markers, WordPress was taking liberty and adding its own default set of permalink rules at the end of my .htaccess file. These default rules were redundant and could have interfered with normal functionality, especially if my custom rules had not been written properly (e.g., if I had omitted the L flag).

And it would have been disastrous if I had made the mistake of wrapping my custom rules with the BEGIN/END markers.. then WordPress would have overwritten everything and things definitely would have been broken (badly). Incidentally, the only reason I didn’t use the WP markers is because, as an .htaccess aficionado, I think they look horrible, especially with that stupid blank line. Ironically it’s this superficial aesthetic preference that prevented complete site breakage, but I digress.

Do you think the millions of other WordPress users are as careful with the contents of their own .htaccess files? I shudder to think at the frustration and wasted time brought about by this default WP functionality. Here are a few good reasons why automatically modifying the .htaccess file is never a good idea:

  1. Apache/.htaccess syntax is hypersensitive
  2. A single error in syntax/idiom can crash the server
  3. It’s not safe to assume any pre-existing .htaccess directives
  4. Existing .htaccess directives may conflict with automatically added rules
  5. Any additions to .htaccess should be tested thoroughly before going live, especially when other rules may be in play

Before looking at ways to stop WordPress from changing the .htaccess file, it is important to understand that taking any steps to prevent the default behavior may cause something to not work as intended. Really it’s not a big deal, however, as .htaccess files by default are not writable on many servers; so lots of WordPress users already operate in this capacity without issue. </disclaimer>

Make it stop

So now that we’re all on the same page with WP’s auto modification of the .htaccess file, let’s look at how to prevent it from happening (or not).

Method 1: Lock it down

The cleanest way, in my opinion, is to make the .htaccess file “read-only”. By changing the file permissions to read-only, WordPress will not be able to modify it. As explained in this support thread:

“WordPress specifically checks if both the home path and the .htaccess file in the home path are writable, using the PHP is_writable function. If it’s not writable (aka, read-only), WordPress does not attempt to write to it. If you’re on a Linux based hosting system, make the .htaccess file have 444 or 440 or 400 permissions. Use the smallest one that still works.”

For example, on my server, a chmod value of 444 worked like magic. But on your server depending on configuration, you may need to dial it down even further, using 440 or even 400. Always best to test thoroughly, and/or ask your host if any doubt.

So the permissions change is a solid solution, but understand that it will prevent anything — WordPress, plugins, themes, etc. — from making changes to the .htaccess file. Consequently you yourself won’t be able to make changes to the file via SSH/SFTP/etc. So for example, if you want to quickly block a brute-force attack, you’ll need to set the permissions of your .htaccess file back to 644 (or whatever) in order to make any changes.

Depending on how frequently you need to modify your .htaccess file, this can get tedious. So if locking down file permissions doesn’t seem like an ideal solution, you may want to consider method #2..

Method 2: Add a filter

If you want to stop WordPress from automatically updating your permalink rules, but also want to ensure that the file is writable for other purposes, then you can add the following filter via plugin (or theme functions, etc.):

// Stop WordPress from modifying .htaccess permalink rules

This will prevent WordPress from modifying the permalink rules in your .htaccess file (or web.config file, if using Windows server). The only downside to this approach is that you’ll have to be mindful of any changes that WordPress makes to its default permalink rules, and update your .htaccess file accordingly. Fortunately this is rare; in my 10+ years working with WordPress, the permalink rules have been changed only once.

Method 3: Customize outside of the markers

As mentioned previously, if you don’t mind WordPress and plugins writing to your .htaccess file, you can simply add and custom .htaccess rules outside of the BEGIN/END markers. That way WordPress can keep the permalink rules up to date, and other plugins can continue to do whatever they want to your .htaccess file. Of course, implementing custom rewrite/permalink rules without actually modifying WP’s default rules is easier said than done ;)

Method 4: Do nothing

Last but not least, you can always just let WordPress update your .htaccess file as it pleases. A couple of points about this strategy:

  • Only recommended if you do not need any custom permalink rules
  • While it should be fine to let WordPress core make changes, it’s your call as to whether or not plugins et al should enjoy the same write privileges

So in case you’re thinking, “what a nutjob, telling me to not allow WordPress to do whatever it wants”, relax. I’m saying that there are scenarios where WP’s auto-writing can be dangerous. But if you’re always using the default permalink rules, then you’re probably safe allowing WordPress to make changes automatically. WordPress is a well-tested and generally reliable piece of software ;)


In the process of setting .htaccess permissions for a couple of my own sites, I managed to take a few notes for future reference. You can ignore this section if you are not making any permissions changes. Otherwise, you may find it useful.

Default .htaccess permissions   = 644 (rw- r-- r--)
Read-only .htaccess permissions = 444 (r-- r-- r--)

Online tool: CHMOD Calculator

Note: When WordPress does NOT have write access to the .htaccess file, making a change to the Permalink settings results in an admin notice that says, “You should update your .htaccess now”. Additionally a set of .htaccess rules will be displayed near the bottom of the page. Otherwise, if WordPress does have write access to the file, these items will not be displayed.

Thanks for reading. Remember to vote this November! :)

GoDaddy’s New Primer Theme Bypasses Theme Review Queue, Highlights Bottlenecks in Review Process

photo credit: pollas - cc
photo credit: pollascc

As part of its new onboarding experience for WordPress customers, GoDaddy has created a group of 10 themes to streamline the process of creating a business website. In order to host updates more effectively, the company is submitting the themes to and the first one is now live after less than 24 hours in the theme review queue.

Primer is the parent theme for nine upcoming child themes, which will be submitted to one at a time. Its controversial fast-tracking through the queue angered and frustrated WordPress theme authors who currently have theme submissions that have been waiting months for a review.

Samuel Wood, who works on but is not part of the Theme Review Team, explained in the ticket why he processed the theme outside of the queue.

“The special case here is that they needed to reuse an old name for assorted practical reasons, and it had to be live to allow the already created child themes to be added to the directory,” Wood said. He had to manually make the theme name available or GoDaddy would not have been able to submit it under this name. Wood had the theme reviewed first and the required changes took three weeks to finalize. After it was finished he was able to transfer it to use the Primer name.

“Timing was important because they made this one theme as a base for a dozen or so child themes, and are deploying this to all their WordPress installs, which is quite a lot,” Wood said. “We’d rather have them updating properly from our servers instead of having them create some wacky solution that updates it from theirs or from GitHub.”

The necessity for administrative intervention in this case, and the resulting frustration of other theme authors who have been waiting, once again highlights how painfully slow the theme review process can be. The long wait times discourage some authors from submitting themes to the official directory.

“I have three free themes on and one of the most demotivating things, while waiting to be approved, was the wait times,” theme author Tomas Petrašiūnas commented on the related post on the Advanced WordPress Facebook group. “Building a theme in a week and then waiting for a few months to even start the review process – that’s the exact reason why I’ve never bothered to get more themes approved on”

Chris Bavota, author of the popular Arcade theme, said he “submitted three themes in February and [is] still waiting on approvals and reviews.”

The theme and plugin directories have historically been protected from commercial interests receiving any special treatment, but exceptions like this one made it difficult for other waiting theme authors not to see GoDaddy’s major sponsorship of WordCamps as the reason for getting a theme fast-tracked.

“As someone who has been waiting months for a simple child theme review and who has been a WordCamp sponsor, this sucks big time,” Stiofan O’Connor commented.

Incomplete Theme Submissions are Slowing the Review Queue

Samuel Wood identified the Primer theme situation as a special case and encouraged theme authors and reviewers who were frustrated to explore new ways of managing the queue. At this time there are more than 600 themes in the queue, an improvement from the 900+ that were waiting a month ago.

Key reviewer Emil Uzelac said one of the main issues that slows the process is incomplete theme submissions, which includes themes that present with more than five errors. Sometimes themes languish in the queue and by the time they are reviewed they haven’t been updated to meet newer requirements. Others include common mistakes like missing translation functions or prefixes, or including custom versions of scripts that are already included with WordPress.

To mitigate this Uzelac said the team has implemented some new policies which he says have helped reduce the queue over the past month.

“We are actually limiting submissions to one theme per author now, and if the theme has five or more distinct issues, we close it as not-approved,” Uzelac said. “It has been working very well. Once we are around 100-150 this will go much faster.” He estimates it will take a few months to get there.

The Theme Review Team is also working on improving automation for routine tasks. Due to the architectural shortcomings of the Theme Check plugin, the team is looking to PHP_CodeSniffer to create a better solution. They are working to add a new WordPress-Theme coding standard to the existing WordPress Coding Standards project, and contributors are building a list of sniffs that pertain to theme review requirements.

Talking SaaS at WordCamp Netherlands This Weekend

The Netherlands is one of the most active communities in the European WordPress ecosystem, and I’m very much excited to talk about Software as a Service applications in the WordPress context this weekend in Utrecht!

WordCamp Netherlands Talk

WordCamp Netherlands is hosted in Utrecht this year, with a Contributor Day on Friday, Oct 14, and a couple of days with talks in two parallel tracks on Oct 15 and Oct 16.

cloud-service-architecture-iaas-on-premise-vs-saasI’m basically closing the WordCamp with the last talk of day 2 talking about “Building SaaS with WordPress” while Franz Vitulli is talking about Slack and internal communication in the other room.

I will share some insight based on 7 WordPress Software as a Service applications that we’ve built at DevriX from both business, and technical standpoint. SaaS is one of our main specialties lately, and we’ve just finished the MVP of another wonderful SaaS application lately which is also using React and actively leverages the REST API.

That said, if you’re attending the talk over the weekend or are just interested in high-end WordPress applications, Multisites and SaaS solutions, feel free to post some questions down in the comments area that I can possibly include in my slides!

The post Talking SaaS at WordCamp Netherlands This Weekend appeared first on Mario Peshev on WordPress Development.

The Days of Creating Child Themes for Simple CSS Changes May Soon Be Over

The general advice given to users who want to make simple edits to a theme without losing them is to create a child theme. This involves creating a directory, CSS file, a functions.php file, and uploading them to the webserver via WordPress or FTP.

Users must also make sure the child theme references the parent theme correctly in order to establish the proper inheritance. This can be a complicated process for a lot of people but thanks to a new feature proposal for WordPress 4.7, the days of going through this process may soon be over.

The Benefits of Adding a CSS Editor to the Customizer

The proposal suggests adding a CSS editor to the customizer which offers a number of benefits. Users can live preview changes before they’re applied and see how they’ll appear on mobile devices. Instead of editing files directly, changes are stored in a Custom Post Type for each theme and override theme styles.

Related projects such as customize changesets (#30937) and revisions for customizer settings (#31089) will allow for future enhancements. Adding the editor will also lay the groundwork for possibly removing the Theme file editor from core at some point in the future.

Here’s an example of what the CSS editor looks like in action. Note the line numbers that can help with troubleshooting purposes.

custom-css-proposal-demo-1.gifThe editor also displays error messages for common syntax errors. For example, a missing bracket. Adding the editor is only the beginning with revisions, syntax highlighting, and in-preview selector helpers, planned for future iterations.

Special Meeting Planned to Discuss Storage Issues

In today’s WordPress developer chat, attendees discussed the pros and cons of the editor and whether or not it’s ready to be merged into WordPress 4.7. A point of contention preventing a final decision is how data is stored.

Members of the Core and Customizer Component teams will discuss this particular issue in detail in a special meeting before making a final decision to merge it.

Testing and Feedback Needed

To test this feature, you’ll need to apply the patch via Trac or the Pull Request from GitHub as it won’t land in WordPress Trunk unless the proposal is approved. The team encourages you to add custom CSS in the customizer using a variety of themes and to share your experience and feedback in the comments.

A Use Perfectly Suited for the Customizer

While I have yet to test this feature myself, it seems like the perfect use case for the customizer. While some developers have expressed concerns with the proposed implementation, others are excited to see it land in core.

Removing the need to create a child theme for small or simple changes is a huge win for users. It’s also a major win for those who provide support. Instead of giving a customer complicated directions, it can be as simple as telling them to open the customizer, click on additional CSS, paste the snippet of code, and click the save button.

Polyglots Team to Host 2nd Global WordPress Translation Day November 12


The WordPress Polyglots team is planning another Global WordPress Translation Day after the success of the original event in April. The first event drew 448 participants from more than 105 countries to online streaming sessions and live meetups, where contributors worked on more than 160 languages. Global WordPress Translation Day 2 is set for November 12th and will begin at 0:00 UTC with a live opening session from Tokyo, Japan.

“The first translation day was a blast,” said Polyglots team member Petya Raykovska. “We got together as a team for the first time and organized something that had a huge impact on our community and brought more contributors over. It shed a lot of light on who we are, what we do, and why it’s important. It turned us into one team as opposed to 100 different teams under the Polyglots name.”

In April the Polyglots focused on growing the translation teams and educating new translators with live training sessions. This event will follow the same format with 24 hours of live streaming sessions about localization and internationalization (L10n and i18n) for those who are joining from home. The team is also aiming to organize in-person translation contributor days in more than 50 different locations.

One of the goals for the event is to bridge the gap between developers and translators. In addition to beginner and advanced sessions to help new contributors learn to translate, the event will also feature technical sessions for developers. After plugin and theme translations became part of, there’s a back log of demand for localizing an estimated 40,000 projects.

“The Polyglots team has a lot to share with developers and there will be sessions on preparing their code for translation, building and managing translation communities, tools, tips and tricks for maintaining your code, as well as detailed information on how translations work in WordPress and plugins and themes,” Raykovska said.

Global WordPress Translation Day Unites Polyglots to Work on Projects Across Borders

The Polyglots team has more than doubled over the past year and a half and is still learning to work together as a unified team. With 1,247 translation editors and thousands more contributors, it takes a concerted effort to work together effectively.

“Our goal with WP Translation Day 2 is to literally meet each other,” Raykovska said. “Among the live sessions will be many that will just stream people’s local events in so we can say ‘hi’ in person, along with round tables featuring people from different locale teams to discuss important issues.”

In addition to translating WordPress core, themes, and plugins, the Polyglots will be working on the new initiative to internationalize WordPress core JavaScript, an ambitious task which includes changes to core, GlotPress, wp-i18n-tools, and language packs.

“Internationalization is not a feature, it fixes a usability issue for many users whose primary language is not English,” Dominik Schilling when making the case for JavaScript Internationalization on the WordPress development blog this week. “And that’s about 47% of our users.” That figure is up 1% since July. It wouldn’t be unreasonable for the percentage of non-English sites to overtake English sites within the next year.

The Polyglots are one of the most influential contributor teams for expanding WordPress usage to new areas of the world. Raykovska said she hopes the second Global WordPress Translation Day will help everyone feel more included.

“This is an event that serves as a de facto online community summit,” she said. “It would be impossible for all the Polyglots to meet in person, but this way you can meet people who are close to you as well as people who are on the other side of the world. We’re a huge remote team. And one of the most important things for successful remote teams is face time. This is our way of getting that.”

In keeping with the Polyglots’ growing momentum, the upcoming Global WordPress Translation Day will be the second event of its kind hosted within 2016. It will connect the thousands of new contributors who have joined within the past year. Organizers have confirmed more than 20 live meetups that will happen during the event and new ones are being added every day. Participants can join locally or online in the #polyglots Slack channel or in their local Slack channels. Sign up on to reserve your spot and stay updated on the event.

The Risks of Premium Themes for Successful Businesses

I did a review of Envato and ThemeForest last year discussing the race to the bottom and the financial challenges for both business owners, and theme authors. The focus, however, was on the existence of the marketplace in the first place and the lucrative vision of the millionaire theme author in the context of the low-cost offers for $500 WordPress websites.

This is a short run of the drawbacks for business owners tempted to spend some cash on a custom WordPress theme and taking a shortcut with a premium WordPress theme within the $30-$150 range.

Keep in mind that not all premium themes are built the same, but the business model behind most of them is design and flexibility that compromises stability, speed, or security.

What is a Premium WordPress Theme?

The Premium WordPress Themes misconceptions
The Premium WordPress Themes misconceptions

Premium WordPress Themes are WordPress themes for sale by various marketplaces, most notably ThemeForest, Elegant Themes, and a hundred more shops for themes where you can purchase a “ready-to-go” solution usually within a hundred bucks. The benefit is that you see a beautiful demo (or several demos) that seem to solve your need, and the cost is drastically lower than hiring a designer and a developer to build a custom theme for you.

That causes several issues for the vast majority of the sites, impacting mostly websites with higher traffic and larger user base.

Why Are Premium Themes So Cheap Then?

From a theme author’s standpoint, building a WordPress theme requires a certain set of hours, usually within the 50-300 range. Even at an average rate of $50/hr, this results in a $2,500 – $15,000 investment from the author in the form of design, front-end development, back-end development, documentation, demos, etc.

Now, this would approximately be the cost for a custom solution tailored to your business needs. Marketplaces such as ThemeForest charge clients about $50 per theme, and take a cut of 30%-50% from the revenue before paying the author. In other words, a theme author should sell 80-500 copies of a theme until break even, if we don’t account for additional support time, fixing bugs and customization.

In order to gain that many customers, authors are required to build multi-purpose themes that solve all problems that you can think of, and design themes that are applicable for all niches – business blogs, online magazines, photographer websites, food sites, classifieds sites and so on.

Why Is That Any Bad?

Multi-purpose WordPress themes need to solve problems for different industries, and therefore include a set of things:

  • A ton of WordPress options customizable for every need
  • Some sort of a visual builder or a user friendly way to easily edit content
  • A number of snippets (shortcodes) for different sections and such
  • Sliders, galleries and other media-heavy components
  • Different skins, templates and other turnkey solutions for quick set-up

Many premium WordPress themes take it a step further and bundle additional plugins, or get crazy with hundreds of options across the whole website.

In reality though businesses in need of WordPress websites take advantage of a tiny percentage of those options for their specific solution. When you multiply all possible combinations of colors, fonts, sliders, galleries, sections and the like, you end up with millions of combinations. For every page load your premium theme does every check in the database and configurable files in order to read the right configuration for your solution, and takes a while until it loads everything as you’ve specified.

Additionally, the code base it many times larger than a clean custom-made solution that solves only one problem – your problem. That easily gets cluttered, very hard to maintain, and in addition to the performance challenges, it is incredibly hard to keep working in the long run as your website grows, WordPress issues new major versions three times a year, and you bundle that theme with a number of plugins that should play together with it. The larger code base also means a lot of interaction with sensitive data, which opens different vectors for potential security breaches and possibly hacker attacks on your website.

What if My WordPress Theme Doesn’t Have Many Options?

Options... Options everywhere. Image credit:
Options… Options everywhere. Image credit:

Even if the premium WordPress theme that you’ve selected (or considering) isn’t that option-heavy, it is likely loading a number of styles and scripts that make it beautiful, interactive, and flexible when a user visits and browses your website.

Styles and scripts are different files responsible for the look-and-feel and dynamic activities across your pages – such as masonry grids for your posts, flexible galleries, interactive sliders, parallax effects and other goodies that pop up and boost the user interface for a website.

While those could be optimized as well, providing a very flexible solution without causing numerous bugs in different setups and various hosting providers is safest when loaded in the straight-forward way – one file for each library, each snippet, and every component that makes the DIY website build so much easier.

Modern browsers tend to allow up to 8 simultaneous file requests when loading a page, and many premium themes bundle 30-60 styles, scripts and additional icons or images everywhere they can. This may take roughly 0.5 to 5 seconds additional load time every time a visitors opens your website, and 25% of the desktop users tend to close a tab if it doesn’t load within 4 seconds. Google is also punishing slow websites by ranking them further in the search results, therefore impacting the organic search positioning for businesses with slow websites.

And it’s normal – that’s a serious overhead we’re talking about.

Convenience Comes at a Price

Generally the more options, configurations and jingles you want in a WordPress theme, the heavier and harder to maintain it gets. The less features you use in a solution, the more the overhead and the additional computations behind the scene for every single page request.

That’s not all – slower websites also have bigger impact on servers, take more server resources and can handle less simultaneous users. There are certain limits of concurrent connections that web servers can handle, and the longer it takes one visitors to load a page, the fewer folks can browse your website at that time as well.

Almost all of our customers contacting DevriX are large businesses starting with a premium theme and off-the-shelf plugins that can’t accommodate the traffic their successful business gets. This leads to revenue constraints or even losing partnerships when a site misbehaves, and our main tech team works closely with the creative department on building custom tailored solutions, scaling servers and providing much better user experience to each and every visitor.

While not all premium themes are cluttered, poorly coded or heavy, it’s a financial benefit for theme authors to build multi-purpose solutions that solve as many problems as possible. This leads to more theme sales and better ROI in the short run for authors, and the ability to sustain a business. However, lighter and maintainable products are more limited in terms of options and have a narrower market, which often can’t return the cost of building a theme, which determines the market expectations and the state of the premium WordPress themes freely distributed online.



The post The Risks of Premium Themes for Successful Businesses appeared first on Mario Peshev on WordPress Development.

WP REST API Team Proposes to Merge Content Endpoints Into WordPress 4.7


Over the weekend, the WP REST API team published a proposal to merge the API endpoints for content types into WordPress 4.7. This is the second in a two-part proposal, which merged the infrastructure for the API into core in October 2015. Since that time the team has worked on polishing the content endpoints and making changes to core that are necessary to support the API.

The endpoints proposed for merge include posts, comments, terms, users, meta, and settings management. This includes public access as well as authenticated access via the OAuth 1 protocol. The team selected OAuth 1 over the newer OAuth 2 protocol, because OAuth 2 requires HTTPS with a modern version of TLS. As WordPress core doesn’t require HTTPS, the team did not want to make it a requirement for using the API.

“This merge proposal represents a complete and functional Content API, providing the necessary endpoints for mobile apps and frontends, and lays the groundwork for future releases focused on providing a Management API interface for full site administration,” said Ryan McCue in the proposal posted on behalf of the WP REST API team.

Preliminary feedback in the comments so far has been supportive of merging the API, with a few WordPress contributors expressing concerns regarding the authentication scheme. WordPress sites don’t have a centralized oAuth server, which means those using the API to create applications would need to have those apps registered with every single WordPress site it connects to. To get around this, the WP REST API team created a brokered authentication solution with the main broker system running at The team is proposing brokered authentication for WordPress 4.8 to allow for more testing. Eventually, the broker would be hosted on

“The concept of a third-party broker feels very antithetical to WordPress Core,” George Stephanis commented on the proposal. “To have to ping the third-party server for every login to check for invalidations of their applications, let alone the initial confirmation of an application … for me, it doesn’t pass the gut check.” Stephanis said he would rather see something similar to the Application Password System feature plugin that is being developed for core, as it provides a simple flow for applications to request passwords and get the generated passwords passed back. It’s also compatible with the legacy XML-RPC API.

WordPress lead developer Dion Hulse commented that he does not like the idea of having a third-party broker but thinks that Application Passwords would be worse than the complications that oAuth options introduce.

“At the end of the day moving towards oAuth is going to provide a far better developer and user experience for API clients,” Hulse said. “In an ideal world, a central provider wouldn’t be needed, but we don’t have a decentralized platform for WordPress yet, so there’s no other mechanism for WordPresses out there to be told the sort of information they need to know.”

The proposal is open for comments and the WP REST API team welcomes feedback in the #core-restapi Slack channel as well. They are particularly interested in getting security feedback on the REST API plugin and the OAuth plugin, which are both available on If the endpoints are merged, the team plans to implement feedback throughout the next few weeks before 4.7 ships in early December.

“During the remaining parts of this release cycle and through into the 4.8 cycle, additional work will go into other parts of the API,” McCue said. “This includes further work and refinement on the broker authentication system, including work on infrastructure. Additionally, we plan to continue working on the Management API endpoints, including theme and appearance endpoints to support the Customizer team.”

The team outlined an iterative approach that would not include full wp-admin coverage at merge into 4.7, a controversial sticking point which contributors were divided on when they discussed the possibility of merging the endpoints earlier this year. They are proposing that the Management API endpoints and theme/appearance endpoints be maintained as separate feature projects on GitHub until they are ready for merge. Development related to the content endpoints would move from GitHub to Trac if the merge is approved.

WordPress 4.7 Will Allow Developers to Register Custom Bulk Actions in Admin List Tables

photo credit: -pdp- - cc
photo credit: -pdp-cc

WordPress 4.7 will allow for custom bulk actions in admin list tables, an exciting new feature for developers. List tables are found on various screens throughout the admin. Bulk actions are the dropdowns that let users perform actions such as activate or deactivate plugins in bulk, move multiple posts to the trash, and bulk delete media items.

The ability for developers to filter bulk actions was introduced in 3.1 but it didn’t offer much flexibility. Up until 4.7, it only allowed for the removal of items from default bulk actions. The upcoming release will make it possible for developers to register new bulk actions for any admin list table dropdown, including the Attachments list table.

image credit:
image credit: Eric Andrew Lewis

Eric Andrew Lewis posted the announcement on the make.wordpress/core blog along with a sample code walkthrough of the steps required for adding a new option to the dropdown, handling a bulk action form submission, and displaying notices to inform users of what happened. The announcement was met with a round of cheers from developers who are delighted to make use of the new ability to register their own bulk actions.

This small, yet important change resolves a six-year-old ticket and has the potential to impact many plugins. For example, the Custom Bulk Actions plugin has been rendered obsolete, as core now provides a better standard. There are many other plugins that register bulk actions through a similar method or another type of hack, but WordPress 4.7 will offer an easier, core-supported way to accomplish this.

DevWP Redesign – UX Recap and Content Planning Flows

The last redesign of DevWP was about a year and a half ago (give or take), but I’m really happy to announce that we’ve done some minor updates in the internal structure plus a brand new landing page for the main domain:


Our previous redesign (again by our Creative Lead Alex) did follow my overall idea, but wasn’t as functional as I wanted it to be. My initial goal was staying closer to what the internal pages print (overall structure and a sidebar) in order to be consistent, but that led to various limitations – either repetitive information in sidebars and the landing page, or keeping two different sidebars that had nothing in common at the end.

Information wasn’t trivial to find across different sidebars, and there were missing actions in the navigation funnel – both across the landing pages, sidebars, and internal pages. Most of those were rectified with the new look-and-feel with several CTAs and the lack of sidebar on the homepage, which is retained through the internal pages.

From a usability-standpoint, the initial look-and-feel was very consistent and pleasant, relying on a WooTheme theme:



Apparently it didn’t have the mechanism to outline specific areas properly in the form of landing pages, but back then the blog was the main thing and this was a fairly smart and usable choice for the time being.

Content Production Was Blocked, Too

The most interesting thing with the previous design was that it served as an actual blocker to my writing efforts. I took a break from writing for a while, but wasn’t able to get back in writing shape here, despite of my actual motivation. I was still producing guest posts and copy for DevriX or some of our customers, but the overall structure of the site was standing in the way, which was quite problematic at the end.

Additionally it felt as if all of the high-end topics I was writing about was exhausted, and already covered in my previous publications. Whenever I had a title in mind, there was already a post covering a good chunk of that theory, and there was no need to write about it. At the same time DevWP means “WordPress Development” which seemed oddly limiting at some point, and broader topics weren’t as applicable as they would be for a more generic site. As a final excuse, I’ve been spending more time at the office brainstorming with the team and less time focused on writing things down, but since I’ve upgraded my hardware with a new awesome and powerful ThinkPad notebook with a splendid keyboard and 9-10h of battery life, I’ll be slightly more portable and capable of writing more often.

New Content Branches

That said, after rebuilding the Articles section at DevriX, I figured that following the same model applied there was logical. Why?

DevriX is a WordPress Development company. DevWP is a blog on WordPress Development, too.

However, DevriX is a full-service agency that provides technical PHP and JavaScript development on top of scalability, security and performance work in all layers, but we don’t stop there. We extend the creative efforts toward the front-end of our applications, but also reflect the marketing and branding needs of a business. Our team of content writers produces over 50 articles a month, and we unify and distribute those content efforts across different channels. Additionally, we do business and market research, craft marketing strategies, build sales funnels, measure conversions, improve user experience, monitor SERP rankings, issue feedback polls and analyze customer feedback, provide support, maintain infrastructure when scaling is needed, translate technical to business requirements and support business needs as a whole.


And even when we provide purely business or marketing services, WordPress is our go-to tool.

  • A campaign website? That’s WordPress here.
  • New product offering? Design and build a new landing page.
  • Automate business processes? Build plugins, refactor the admin, integrate 3rd party services.
  • Increase the traffic? Plan for new content, and publish it in WordPress.
  • Too much content everywhere in chaos? Let’s recategorize, fix the tagging system and build some sane archive or cornerstone pages.
  • Run some campaigns? Sell stuff through the eCommerce with coupons, or offer freebies through a WP page template with an email sign up form.

Basically whatever we need to do, WordPress happens to be a good solution, and we leverage it through the different channels and our combined skill set and efforts. That’s why I’ll expand the content here into the three main categories (also outlined in the new homepage):

  1. Business – content oriented for business owners. I see a lot of potential here in the higher market, especially when it comes to why WordPress is a suitable platform for large businesses. A lot of successful businesses stay away from WordPress due to the newbie content online, the race to the bottom and the large pool of low quality solutions, DIY tutorials, influx of blogging themes and what not. That “category” may cover the other side of the coin given our solid experience with enterprises and large multinational businesses using WordPress.
  2. Marketing – articles marketing directors and experts in a need of WordPress solutions, as well as Inbound Marketing case studies by us and some of the tools and services I’ve been playing with as a part of our Retainer packages for our best clients out there.
  3. Development – purely technical copy, from programming advice through code reviews, bad practices in existing solutions, technical recaps and more for the engineering group of readers.

Since I’ve asked my readers a couple times about topic suggestions – I keep these in my archive, and I still don’t know if answering those would be applicable to you or the other readers, but just keep in mind that I haven’t forgotten or ignored you and I do appreciate your candid feedback. Hopefully the new high-end content categories above would be more suitable for some of those entries.

The post DevWP Redesign – UX Recap and Content Planning Flows appeared first on Mario Peshev on WordPress Development.

When emailing zips please make sure your email…

When emailing zips, please make sure your email client and email service provider allow this.

Increasingly, we have seen people testifying that they emailed us a file with a zip, but we never receive it. In doing some research, we’ve found that mail providers are now silent-killing large emails! While the settings can be overwritten, please keep this in mind when you email people your zips.

If you have the ability to check your mail logs, you may be rudely surprised. I know I was.

WordPress Plugin: Theme Switcha

[ Theme Switcha ]

Announcing my latest WordPress plugin, Theme Switcha! There are many theme-switch plugins but none of them provide the simplicity, performance, and reliability that I require for my own sites. So I wrote my own plugin using the WP API and kept the code as focused and solid as possible. Only essential theme-switching features have been added, along with a simple yet informative UI. Theme Switcha gives you a consistent, quality theme-switching experience that you can optionally share with your visitors.

[ Theme Switcha UI ]
Theme Switcha – All your themes ready for switching

Plugin Features

Theme Switcha is Packed full of features:

  • Enables you to develop new themes while visitors use the default theme
  • Control who can switch themes (admins, users with passkey, or everyone)
  • Administrators can switch themes directly via the WP Admin Area
  • Enable visitors to switch and preview themes on the front-end
  • Each visitor can choose their own theme
  • Send preview links to clients via the passkey
  • Choose your own custom passkey code for preview links
  • Set the duration (cookie timeout) for switched themes
  • Enable/disable theme preview in the Admin Area
  • Enable/disable all theme switching without deactivating the plugin
  • Provides several shortcodes to enable visitors to switch themes
  • Shortcodes display themes as a list, select menu, or thumbnails
  • Changed options are saved when working on switched themes
  • Simple, stylish UI featuring screenshots of each theme
  • Works with any theme, parent themes and child themes

Check out a screenshot of the Theme Switcha settings page »

Theme Switcha makes it easy for the site admin to preview and develop new themes without changing the default theme. So visitors will continue to use your site normally without ever knowing that you are testing new themes behind the scenes. And if you want to enable your visitors to switch themes, you can do that as well by adding a shortcode to any WP Post or Page. Then each visitor will be able to select and preview any of your WordPress themes.

Useful for things!

Theme Switcha is useful for things like:

  • Maintenance mode – display a temporary theme to visitors while you update your primary theme
  • Theme test drive – preview and test new themes without disrupting anything on the frontend
  • Theme development – perfect for developing new themes to fit your existing site content
  • Client presentations – send clients special “theme preview” links to show off new templates

The beauty of Theme Switcha is that it’s all 100% transparent: visitors will never know that you are hard at work testing and building new themes behind the scenes.

Learn more and download Theme Switcha »

How to Add Your WordPress Blog to Apple News

Did you just start a blog and want to submit it to Apple News? By becoming an Apple News publisher, you can monetize your news channel while giving your readers the ability to read your blog alongside with their other favorite websites from a single app. In this article, we will show you how to add your WordPress blog to Apple news.

Add WordPress blog to Apple News

Before Getting Started

Apple News app allows users to read news and blogs articles in one single app on their Apple devices. It provides a better reading experience and makes it easier for users to stay updated with their favorite content from a single app.

The Apple News program for publishers allows you to submit your blog as an Apple News channel. It also allows you to monetize your content by showing advertisements.

However the monetization program is still in beta, and it is only available in the United States, UK, and Australia. You will have to wait for a couple weeks for your application to get reviewed.

Please note: this guide is for self-hosted WordPress blogs and not for blogs. See our guide on the difference between vs If you’re on, then you can use this guide to move from to

Having said that, let’s learn how to add your WordPress blog to Apple News.

Adding a WordPress Site to Apple News

First thing you need to visit the News Publisher app on the iCloud website. You will need to login with your Apple ID.

Once you are logged in, you will see News Publisher terms of service. Click on I agree and then click on the submit button.

Next, you will be asked to provide publisher information. Fill in the form and then click on Next.

Publisher info

In the following step, you will be asked to setup your channel by providing information about your website. Fill in the required fields and click on the next button to proceed.

Setting up your channel on Apple News

You will now be asked to provide a type based logo for your channel. A type based logo is just an image with your site name in readable text format. It should have a transparent background, and the file size should be less than 2 MB.

Upload logo for your channel

Next, you will be asked to choose between RSS or Apple News Format. Go ahead and choose Apple News Format, we will cover this in the next step.

If you use the RSS feed option, then you will not be able to monetize your content in Apple News. It also prevents you from using other Apple News features as a publisher.

See the comparison chart below:

Choose news format

Once you are done, click on the Signup for Apple News Format button.

That’s all, you have successfully finished your application for joining the Apple News. You will now see a thank you page like this one:

Thank you message

Now you will have to wait to hear back from Apple News. An application can take up to two weeks to be approved.

You may want to bookmark this article now and come back to complete step 2 once your application is approved. Press Ctrl + D to bookmark the article in your browser (Cmd + D for Mac users).

Submitting Articles to Apple News

Once your application is approved, you will be able to submit articles from your WordPress blog to the Apple news app.

You will have to manually submit your first article via your News Publisher account on iCloud. Since Apple is notorious for quality, your first article will be manually reviewed by the Apple News team, and this could also take some time (anywhere between 1-2 weeks).

After that Apple News will automatically start showing articles from your RSS Feed.

Here is how to automatically publish your WordPress blog posts to Apple News.

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

Upon activation, you need to visit Settings » Apple News page to configure plugin settings.

Publish to Apple News settings

Next, you need to enter your channel ID, API key, and API key secret. You can find this information by signing into your Apple News Publisher account.

Apple news API keys

After that you need to select which post types you would like to generate in Apple News format. In most cases, the only post type you need to select is Posts.

Apple News WordPress Post Type

The last section is to configure the visual appearance of different elements in your generated articles. Feel free to customize the settings as you need.

Apple News Formatting

Don’t forget to click on the save changes button when you are done.

That’s all, Publish to Apple News will now start publishing your article in the Apple News Format.

We hope this article helped you learn how to add your WordPress blog to Apple News. You may also want to see these 19 actionable tips to drive traffic to your WordPress site.

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 Add Your WordPress Blog to Apple News appeared first on WPBeginner.

Documenting JavaScript in WordPress

Ever since the release of the 3.0 version of the Yoast SEO plugin, JavaScript has been a big part of it. We rely on it to make high-end features possible, like real-time content analysis. The decision to use JavaScript meant that the development team had to make a lot of choices about technologies and tools. So, we had to get a firm grasp of the use of JavaScript in WordPress.

While working on Yoast SEO 3.0, we discovered that few WordPress contributors have extensive JavaScript knowledge. At the contributors day of WordCamp Europe 2016, we saw an opportunity to help WordPress advance the future of the internet. By documenting the JavaScript in WordPress, we can make it easier for everyone to build on and enhance the code.

We believe that JavaScript is here to stay. It is a great language that helps to enrich the user experience people enjoy so much on the web. But to work towards a better JavaScript implementation and understanding of WordPress core, we had to find out what goes on!

That means documenting all the places where decisions were made, magical things happen or where complicated situations are handled. This documentation is a requirement to maintain all the functionality. It’s also crucial to prevent misunderstandings that will lead to bugs or other problems. These insights resulted in our dedication to documenting all the existing JavaScript files used in WordPress.

How we started

The first thing we did was to reserve a slot in the development calendar. Every Thursday we have two hours to work on the documentation process. This means that all developers in the office are going to work on WordPress core activities for that period of time. At the moment the primary focus is JavaScript documentation so everybody will put their time into this particular task. In the future, we might be working on other parts of the core.

To get things going, we started off with a briefing about the intentions and goals. After this meeting, we developed a practical approach. This approach consists of guidelines and tools to ensure a uniform result. Every result must follow all standards. We use these to make sure everyone works in the same way.

Tools: JSDoc

Since we’re writing JavaScript documentation, it was only logical to use JSDoc to generate a view of the state of the documentation. The WordPress standards dictate which specific tags you should use in the documentation. It’s mainly used to validate that everything is visible at the intended location.

WordPress: Coding Standards

WordPress has a precise definition on the formatting of code. This ensures that the entire code-base has the same look and feel. It helps developers in providing a unified experience throughout the platform. You all know these definitions as Coding Standards. WordPress implements separate standards for PHP and JavaScript.

There is also a precise definition on how you should format your JavaScript documentation. It is possible to use a tool to generate documentation. If you do, you can use special keywords to provide extra information about the code that is being documented.

Prioritizing files

To start, we’ve created a list of all the JavaScript files provided in a WordPress installation. From that list, we determined what files are the most complex and which ones are in the most critical places. This way, we developed a priority list.

Weekly dedication and future

Every week, all our developers have two hours to pair up and write documentation for a specific file. All patches are code reviewed internally at Yoast before we submit them to core in our attempt to make the review and merge as easy as possible. Currently, we submitted a total of five patches to the WordPress core repository. Three of them are already merged for the upcoming release 4.7.

We received very enthusiastic feedback on the patches submitted. Besides that, we had a good time (with some frustrations) figuring out what was going on. Do you want to follow our lead and get to know WordPress core better? If so, find code that doesn’t have documentation, determine what it does, write the documentation and create a patch. It is one of the most gratifying things to do and makes core documentation maintainers jump with joy!

To be continued…

We will continue to document the files until we finished them all. After that, we will evaluate how and where we’ll put our team to work. We could work on improving existing functionality, architecture and efficiency, but could also develop new features and bootstrapping core for the future.

Do you want to help? Or do you need to document your own JavaScript for a patch in WordPress core? Then you should learn all about the WordPress JavaScript documentation standard.

The merged tickets at WordPress trac:

New Inclusive Parents plugin adds more statuses to WordPress’s Parent Page options

There’s a long-running feature/bug in WordPress that prevents you from using unpublished pages as parents: that is, you can’t add child pages to anything that’s set to private, password-protected, scheduled, pending, or draft. This prevents you from doing things like creating a new scheduled section of a website for embargoed content, or submitting a whole draft section to an editor for approval.

Inclusive Parents is a lightweight plugin to remedy that. It adds private, password, future, pending, and draft pages to the Edit screens’ parent dropdown in Page Attributes as well as the Quick Edit and Bulk Edit parent dropdowns. It also adds private and password pages to the Menu screen. Unpublished pages have their (status) appended in all cases.


Inclusive Parents screenshot-1 Inclusive Parents screenshot-2Inclusive Parents screenshot-3

Donate or Contribute

You may contribute to the plugin code on GitHub or donate to fund its further development.

W3 Total Cache high-risk XSS vulnerability

Just today, WP Media pointed us to a high-risk XSS vulnerability in W3 Total Cache (W3TC). This was a very popular WordPress plugin that has over 1 million active installs. Although it’s a very popular plugin, it hasn’t been updated in over six months. We stopped recommending it a while back for WP Rocket, a W3 Total Cache alternative that skyrocketed in use over the past few months.

We agree with Julio’s statement that when you need to explain to other people you haven’t abandoned your plugin, due to questions about that, the clock has already struck midnight.

XSS vulnerability

Let’s first explain what’s going on here:

XSS (short for Cross-Site Scripting) is a widespread vulnerability that affects many web applications. The danger behind XSS is that it allows an attacker to inject content into a website and modify how it is displayed, forcing a victim’s browser to execute the code provided by the attacker while loading the page.
Source: Sucuri

That’s definitely not what you want your website to do, right? In this case, we are talking about W3TC being vulnerable to a XSS flaw, high risk rated. This one should be fixed asap. With nobody maintaining the plugin, that is a huge issue for the millions of sites that use the plugin.

Order a website review and get a plugin of your choice for free. We'll even configure it for you

$ 699 - Buy now »Get a Yoast website review

Instead of waiting for a fix, we recommend disabling the plugin and using a W3 Total Cache alternative like the ones listed below.

W3 Total Cache alternatives

Luckily, there are more plugins you can use to optimize your site speed. And most work pretty well out-of-the-box. We have listed three speed optimization plugins for you as alternatives for W3 Total Cache.

  1. WP Rocket
    Our most-recommended speed optimization plugin. WP Rocket simply delivers speed improvement. It has a lot of options under the hood and works by simply clicking some checkboxes in their dashboard.
  2. WP Super Cache
    Made by Automattic, so it works flawlessly with WordPress. It’s a simple speed optimization plugin that helps a lot of WordPress sites. We have to add a note: it hasn’t been updated in five months as well. But all in all, it’s a nice, free WP Rocket or W3 Total Cache alternative.
  3. Comet Cache
    Formerly known as Zen Cache, formerly known as Quick Cache. If you change your name so often, you’re probably actively working on your plugin as well, right? Registration is needed.

Over to you

If you want your website to be safe RIGHT NOW and you are using W3 Total Cache, we recommend investing a few bucks in WP Rocket. It’ll be worth your while. If you don’t feel like investing that money in your website, feel free to switch to one of the other W3 Total Cache alternatives instead!

We’re using Sucuri’s Website Firewall at, which eliminates the need for a separate speed plugin. But we have installed WP Rocket on some other sites with great results, so we’re happy to recommend them! Plus, we’re on the awesome and fast WP Engine hosting platform. Just in case you were wondering ;)