Looking back on WordCamp Paris 2016

The upside of being at a conference in a language you only speak a tad bit is that you get to meet and talk to all kind of people that have the same ‘problem’. WordCamp Paris had about 470 visitors, and I’m guessing 440 of them are native French. Don’t get me wrong, I like speaking French with French people, but it usually takes up to two or three days before I can keep up with the speed at which they talk. It’s like WP Rocket on acid. Luckily we ran into Bénard on the evening before the congress. This English-speaking Frenchman is always laughing out loud and that basically set the mood for our days in Paris.

Wordcamp Paris

Language barriers are real

Regardless of that we all speak WordPress, language barriers are real at this conference. I was at a sponsor booth. It had a huge bowl of snacks to lure people to their stand, and I walked up and said “So, everybody is coming to your booth for the snacks, right? How’s your WordCamp been so far?” The guy frowned and shrugged, looked at his shrugging colleague and I simply decided to walk to the next booth, with our friends Val and Joško of Sucuri. Very nice meeting the two of you!

The thing is, that we foreigners try to blend in anyway. We make it easy for the inhabitants of the country we are visiting. But we do like to talk to others that speak a language we do as well. And these conversations might be even more useful. We had a great lunch with Chris, talking about (WordPress) business. We hang out with Rarst to talk about plugin development, shitty bug reports and more. We talked about WordCamp Torino with Francesca and talked to Petya about WordCamps and WordPress in general. We caught up with a lot of people, which in the end is equally valuable to listening to all the talks.

Hanging out with other travellers

Friday evening we had a nice walk and dined in a very small, family-run restaurant called Le Cévennes. Robert and Heinz from Inpsyde joined Rarst, Taco and me and we had a really nice time talking about France, about home and WordPress in Germany.

WordCamp Paris 2016: Yoast at Arc de Triomphe

We joined the rest of WordCamp Paris at the party boat where the after party was. We had a nice conversation with Caspar who works at WP Media these days, for instance. We briefly met James from Ireland. We obviously had a beer with the always friendly Kristof from Belgium, and yes, Kasia, WordCamp Poland sounds like a blast ;-) WordCamp is about the people.

Drupal meets WordPress

On Saturday, we tried our best to understand the first talk by Claire Bizingre about accessibility, as Taco and both value the subject. You never know what a talk like that will bring, even at 9 in the morning. Claire pointed us to some automatic testing tools like Opquast Desktop and aXe DevTools. Although we sometimes had a hard time keeping up with the French words, luckily most slides told her story on their own. You don’t always need to talk to understand each other.

WordCamp Paris 2016: photo during one of the talks

Later on we met the very enthusiastic Léon Cros, who just did a talk about Drupal, and we talked about Open Source and why a Drupal guy was attending WordCamp Paris. He actually just felt like attending a WordCamp, found out they were having one at a ten minutes walk from his home in Lyon, attended and got asked to talk at WordCamp Paris. We discussed similarities in the communities and how we can learn from each other.

Right before lunch, we ended up at the Jetpack booth, talking to Cécile Rainon and the others of Jetpack. It seems our plugin is the number one requested plugin for WordPress.com. It only seems logical. WordPress.com is packed with a lot of all the other good stuff website owners need, and we’re in a high demand niche. It makes sense, as we offer an all-in-one SEO solution. Nevertheless, it was very nice to hear.

Paris, je t’aime

That pretty much rounds it up. We ended WordCamp Paris by joining a lot of the people mentioned above for a nice dinner and drinks and strolled back to the hotel for a good night sleep. We had a nice breakfast with Val en Joško in our hotel Eiffel Seine the next day and took the Thalys back to the Netherlands, where I’m wrapping up this post.

Bottom line: nous parlons WordPress. We obviously don’t speak the same language all the time, but just being here, talking to loads of people, making new friends, made WordCamp Paris 2016 very valuable to me.

Jenny and Julio and the rest of the organizers, thanks a lot for having us!

Learn How to Test WordPress Core Patches with VVV on Mac OS


Testing patches is one way that both developers and non-developers can contribute to WordPress without writing any code. It’s a valuable service that keeps things moving along in tickets and helps patches make their way into core.

The most challenging part of testing patches is getting your testing environment set up properly. The WordPress core handbook has instructions for using Grunt to test patches, but they’re not easy to follow if you happen to be a more visual learner.

Yesterday Ryan Boren published a tutorial for testing patches with VVV on Mac OS, complete with screenshots at every step. The bulk of the instructions cover establishing a test environment with VVV, which requires you to install Vagrant, install Virtualbox, initialize Vagrant, install Git, and finally install VVV. Applying a patch and reverting it after testing is probably the easiest part of the entire process.

Boren’s tutorial is one of the clearest and easiest to follow, because it helps you visualize what success looks like at every step. If you want to add mobile testing into the mix while testing patches, check out his post on using VVV and xip.io. Boren explained how he goes through tickets with patches that change UI and adds mobile and desktop screenshots of his testing.

“These screenshots hasten UI feedback and usually reveal visual glitches on mobile that are then patched up, making our mobile experience that little bit better,” he said. “Until that blue sky someday when I can apply patches to a patch server with a tap, I’ve found VVV and xip.io to be the easiest way to do localhost testing of patches from mobile devices.”

The process of setting up a test environment is the most time-consuming aspect of testing patches, but once you have it in place, it’s easy to apply them. Have you found an easier way to test patches with support for mobile devices? Let us know in the comments.

WP REST API Team Releases Version 2 Beta 12, Seeks Feedback from WordPress’ Lead Developers


The WP REST API team released version 2 beta 12 today. Daniel Bachhuber highlighted the breaking changes in the release that developers will want to digest before updating. This includes the removal of meta endpoints from the primary plugin into its own feature plugin, now available on WordPress.org.

In a comment on our coverage of the continuing discussion, WP REST API team member Joe Hoyle clarified the team’s position on the endpoints’ readiness for core:

For the record, the REST API Team support further iteration on the existing endpoints before being merged into core. That could mean waiting for the WordPress.com API team to use those endpoints in production, or gathering more usage feedback from others. I am strongly against merging anything before it’s been well-proven and well-tested.

The proposal by the team was to include the 4 content endpoints when they are ready. We had a lengthly overview as to the progress of those endpoints, more details on what we feel is left to be done can be seen at the issues queue for the 2.0 milestone.

Why these endpoints specifically? Because they are co-dependent for the most part. Shipping Posts without support for Taxonomies would not be that useful.

Hoyle also cautions that pursuing full coverage of wp-admin is a monumental task that could take several more years:

Going for development of _all_ functionality (somewhere around 8-10 total data routes) should not be underestimated. It’s taken somewhere around a year and a half to get the current 4 to where they are now, and that was with 2 years prior art from Version 1.

As someone who has been in the weeds of that implementation for a while now, I cannot over over-stress just how tricky trying to retrofit a consistent, coherent interface on 13 years of organically grown code and ideas can become. I’m looking forward to being part of the writing the implementation for the remaining (and majority) of functionality, however I don’t want to stop users and developers benefitting from what is already being built for another [several] years.

Hoyle emphasized that the team is not proposing merging the existing endpoints now, but he believes they are getting very close.

With the release of v2 beta 12, Bachhuber urged WordPress lead developers and committers to offer official feedback in hopes of building a consensus. Given the disagreements in the recent meeting, it’s clear that WordPress contributors have not been on the same page as far as what constitutes core readiness for the project.

Feedback from contributors is starting to trickle in. WordPress core committer Jeremy Felt shared his thoughts in a post on his blog today:

I’m in favor of the REST API team’s proposal to merge the endpoints for the primary objects in WordPress—posts, comments, users, terms—when they’re ready.

When the endpoints for these objects are ready, I would like to see them merged early in a release cycle.

With these primary endpoints in, front end workflows can immediately start to take advantage. This is something groups have been doing for years with custom code already. Getting these groups to use the same structure is valuable.

Core committer Weston Ruter summarized his opinion in a tweet:

The plugin is moving forward with regular betas while the discussion continues. Developers who are using the API in beta will need to continue to follow the project closely, as the latest beta makes changes to available features. 10up developer Eric Mann tweeted some of his challenges in using the API in beta:

My client installed the REST API before it included post meta. We had to build a bunch of custom work to support meta. Then the REST API updated to include meta and broke our integration. I spent a chunk of hours refactoring to compensate so we could update. Now, apparently, the REST API is pulling that meta support out and putting it in a separate plugin. Yet people still criticize me for saying I’m wary of placing too much dependency on the stability of the API.

Joe Hoyle is currently crowdsourcing stats on projects that are using the WP REST API v2 in production. Developers who have stepped up to use the API have had to be nimble in accommodating its rapid development. At this time, the WP REST API team agrees that further iteration on the existing endpoints will be necessary before merging them into core. Continued feedback from developers with projects that use the API will be critical for demonstrating that the API has been well tested.

WordPress Contributors Look for a Path Forward for the WP REST API

photo credit: Valeriy Poltorak
photo credit: Valeriy Poltorak

Over the weekend, discussion continued surrounding the direction of the WP REST API, as both Matt Mullenweg and Ryan McCue took to their WordPress blogs to clarify statements from last week’s status meeting. Differences of opinion are driving a heated debate about what constitutes a goalpost for the API’s readiness for core.

In a post titled “Chicken and Egg,” Mullenweg addressed the recent WP REST API discussion while sharing an anecdote from a book that covers history from the mid-90s hip-hop era.

I love the idea of Questlove realizing the song was missing something, and going back to the booth to keep working on it until it resonated with his target audience. A song that doesn’t stand up on its own wouldn’t be any better when bundled as part of an album. (Or Samsung would have the most popular apps on Android.) Fans hear the care and quality of each track, and they become super-fans.

Mullenweg relates it to considerations when building products for the web:

There’s this tension in everything we produce. Where’s the line to tread between 1.0 is the loneliest and a minimum viable product? Or is it about a minimum lovable product? Are we building a car with no air conditioning or a car with no wheels?

‘Pivot’ has become passé, but it’s much worse to assume that distribution will solve something core to your product that isn’t working.

Mullenweg mentioned the same car analogy during the meeting last week. In response to a commenter who asked for more clarification on how the analogy applies to the REST API, Mullenweg said the following:

If you want a good heuristic to use generally: there were decades of cars, millions of vehicles and drivers, before they had air conditioning. The core value proposition of a car is transportation, AC just helps you get there more comfortably. You didn’t need a car to get AC, you could have it in your house. AC might cause you to chose one car over another, but you probably wouldn’t walk or ride a horse if the car didn’t have AC, you’d just roll down the windows.

This begs the question, what constitutes wheels? Contributors to this discussion are divided on whether or not the existing endpoints are ready to be merged into core. The WP REST API team members, many of whom are already successfully using the API in production, believe that the endpoints are ready now. The current state of the API offers the ability to get content in and out of WordPress, opening it up for easier communication with other platforms, which many believe is the primary use case.

Mullenweg and others who joined the discussion last week are in favor of delivering something more complete, a REST API that supports everything available in wp-admin. This includes WordPress’ many site management features and would put the API several releases away from core readiness.

In a comment on our initial report, Drew Jaynes advocated what he believes to be a middle ground that provides a solid jumping-off point. This would involve resolving the missing pieces in the existing endpoints before merging them (items like password-protected posts, autosaves and post previews, and meta.)

“As I and others from the contributor/committer camp said in the chat, there can be a middle ground,” he said. “Whether that ends up looking like the four core endpoints alone, four core endpoints with some flavor, XML-RPC parity, or some measure of wp-admin parity, remains to be seen,” he said.

In a post titled “Progressive Enhancement with the WordPress REST API,” Ryan McCue outlined a full-on iterative approach that would push for distribution now and roll out more endpoints in future releases:

Progressive enhancement is our key solution to a couple of related problems: forward-compatibility with future features and versions of WordPress, and robust handling of data types in WordPress. Progressive enhancement also unblocks the REST API project and ensures there’s no need to wait until the REST API has parity with every feature of the WordPress admin.

McCue’s post goes into further detail of the REST API’s feature detection capabilities, which allow developers to easily detect support for features and build them in a forwards-compatible way while waiting for core support.

Is Distribution the Answer?

During last week’s meeting McCue said that continuing the project’s development as a feature plugin will do more harm than good. If the REST API is not allowed to ship without offering support for everything in wp-admin, the team would be forced to continue iterating on it as a feature plugin while simultaneously resolving difficult roadblocks in WordPress core. With just four major contributors operating at less than part time on the project, this requirement could stall the WP REST API indefinitely.

“We believe that the progressive enhancement approach is the best approach for continuing API development,” McCue said. “Progressive enhancement is a paradigm the REST API project ​must​ adopt, if it’s an API we want to add to (without breaking backwards compatibility) over the next 10 years.”

Mullenweg, who has led an iterative approach to development throughout WordPress’ history, is wary of latching onto distribution as the only way forward.

The larger WordPress’ usage becomes, the louder its footsteps are heard. Iterating on the REST API in core, with distribution to millions of sites, may affect the web in ways contributors cannot yet anticipate. As they say, heavy is the head that wears the crown. The ripples extend beyond WordPress sites to the outside platforms that will also consume the API.

Contributors are still discussing the nuances of iterative development in core vs. delivering a more complete API. Meanwhile, adoption is stilted by the uncertainty surrounding the project and the fact that it still carries a plugin dependency. It’s not yet clear whether WordPress contributors will dig in and push for inclusion of the endpoints against Mullenweg’s recommendation or whether they will opt to spend more time polishing the existing endpoints. If the WP REST API team is required to ensure that the API can support a wp-admin replacement, it may not land in core until the end of this year or later.

How to Display All Your WordPress Posts on One Page

Do you want to display all your WordPress posts on one page? Recently one of our readers wanted to create an archives page and show all WordPress posts on a single page. In this article, we will show you how to display all your WordPress posts on one page without pagination.

Show all WordPress posts on one page

Why and When to Display All Posts on One Page?

WordPress comes with built in archive pages for each category, tags, author, and date.

Many site owners however prefer to create custom archives page for their site. The archives page usually highlight their popular posts, display a date based compact archive, list categories, or display tag clouds, and more. Take a look at WPBeginner’s archives page as an example.

Some blogs prefer to simply display a list of all their WordPress post titles on one page.

Showing All WordPress Posts on One Page

There are many different ways to display all your WordPress posts on a single page. You can display posts on a page with a shortcode, you can display posts on a page using a plugin, and lastly you can display all posts on a page using a custom template and loop.

We will cover all three methods starting with the most beginner friendly one.

Method 1: Using Display Posts Shortcode Plugin

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

This plugin works out of the box, and there are not settings for you to configure.

Go ahead and create a new page and call it Archives or any other title. After that, you need to paste the following shortcode in your page.

[display-posts posts_per_page="1000" order="DESC"]

This shortcode will simply display a list of all your post titles in a chronological order. It is set to display maximum 1000 posts per page.

If you have more than a thousand posts, then you can change that. You can also change the post order to ASC which will display posts in a reverse chronological order (older posts first).

List all posts in WordPress

While you could use the display posts shortcode to show excerpts, thumbnails, and other related information, we don’t recommend doing that. When you are listing all your posts on a single page, this page will be long, and you want to make sure it’s simple and fast. Just displaying post titles is sufficient for archives page of this style.

If you want to display posts on page based on category or other parameters, you can do so by following the detailed usage instructions on their documentation page.

Method 2: Using Simple Yearly Archive Plugin

Showing all your WordPress posts on a single page can make it too long to scroll. You can fix that by showing a list of each year. Users can then click on a year to expand it and see the posts published that year.

First thing you need to do is install and activate the Simple Yearly Archive plugin.

Upon activation, you need to go to Settings » Simple Yearly Archive page to configure plugin settings.

Simple yearly archive settings

The plugin allows you to display list of posts in a variety of ways. You can show them all under links to yearly archives, or you can show them under collapsible years.

If you want to display them under collapsible years, then you need to add <div> and </div> next to the option ‘Before / After (Year headline)’.

Rest of the plugin options are quite self-explanatory. You can set them up according to your needs.

Don’t forget to click on the save changes button to store your settings.

Now to display all your posts on a page, you just need to add [SimpleYearlyArchive] shortcode to the page of your choice.

Collapsible yearly archives showing all posts in WordPress

The plugin provides a range of parameters that can be used with the shortcode. You can look at the parameters on plugin’s documentation page.

Method 3: Display All WordPress Posts in One Page with Template Code

While using a plugin to display all posts in one page is the easiest way, some of you may want to learn how to do it with page templates code.

First you will need to create a custom page template and copy the styling from your page.php file.

After that, you will use a loop below to display all posts in one page.

// the query
$wpb_all_query = new WP_Query(array('post_type'=>'post', 'post_status'=>'publish', 'posts_per_page'=>-1)); ?>

<?php if ( $wpb_all_query->have_posts() ) : ?>


	<!-- the loop -->
	<?php while ( $wpb_all_query->have_posts() ) : $wpb_all_query->the_post(); ?>
		<li><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></li>
	<?php endwhile; ?>
	<!-- end of the loop -->


	<?php wp_reset_postdata(); ?>

<?php else : ?>
	<p><?php _e( 'Sorry, no posts matched your criteria.' ); ?></p>
<?php endif; ?>

If the above code instructions does not make sense, the we recommend that you use method 1.

We hope this article helped you display all your WordPress posts on one page. You may also want to see our guide on 8 proven methods to promote old posts in WordPress.

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 Display All Your WordPress Posts on One Page appeared first on WPBeginner.

WordPress.org Has Fewer Than 20 Plugins Using the WP REST API v2

Plugin Recommendations Featured Image
photo credit: when i was a birdcc

During yesterday’s pivotal WP REST API meeting, WordPress contributors discussed adoption of the API. A cursory search of the WordPress.org plugin directory shows that fewer than two dozen plugins are currently using the API scaffolding included in WordPress 4.4. For reference, here are the 20 plugins identified by Mika Epstein during the meeting, along with active installation numbers for each:

With a few notable exceptions, most of these plugins are hovering around a range of 10 – 100 active installs. These low numbers may indicate that plugin authors have not yet readily embraced building with the scaffolding that was merged into core in 4.4. However, some developers who have embraced building with the API have opted not to offer their plugins and themes for large scale distribution on WordPress.org.

“I think the plugin directory is the wrong place to look for adoption,” WordPress developer Nate Wright said at the most recent meeting. “As a plugin author myself, I have to bend over backwards to ensure compatibility with tens of thousands of weird plugins and themes. Javascript itself is highly unstable in the ecosystem because of all the terrible code out there. I’ve used the API in client projects and am currently integrating it with some customizer tools I’m building. My publicly available plugins will be the last thing I’ll introduce to the API.”

Taylor Lovett, author of Custom Contact Forms, believes that it’s important to get REST API-powered plugins into the hands of users, despite the support challenges of public distribution.

“It pushes plugin and theme developers to start working around API JavaScript conflicts now,” Lovett said. “There are many plugins that conflict with the API for a variety of reasons, one of the big ones being modifying Backbone.sync. Having plugins use it now is painful but will push people to start reporting those JS conflicts.”

Custom Contact Forms is currently the most widely-used plugin running the WP REST API with more than 70,000 installations, but the journey to using v2 has been fraught with challenges.

“There have been a number of backwards compatibility breaks with the JSON REST API project,” Lovett said. “If I had known going into it what would happen, I probably would have not used the API.

“I am still not completely comfortable with using the API because of the perceived instability of the project,” he said.”

Nevertheless, public distribution has brought Lovett considerable feedback from users which has been invaluable for his contributions to the REST API project.

“I’ve had a number of patches to the API that were discovered through Custom Contact Forms,” he said. “I’ve discovered some real edge cases while maintaining the API across more than 70K installations.”

Distributing his plugin on WordPress.org while the API went through significant changes was more challenging than Lovett anticipated, but through it the API has gained more exposure.

“The faster the API is exposed to people and people get comfortable using it, the sooner we will see some major strides in applications being built around WordPress,” he said.

WP REST API Delayed, Contributors Facing Gridlock


The WP REST API team met yesterday in the #core-restapi Slack channel to discuss the status of the existing post, term, user, and comment endpoints. There are a few outstanding issues with these four core objects, which the team wants to tackle via a feature plugin approach instead of holding the API back from merge. These outstanding items include things like password-protected posts, autosaves and post previews, and meta handling.

“For now, we’re not going to support them, and will be working on them in a separate feature plugin instead,” WP REST API project lead Ryan McCue said. “Again, this will be an enhancement to the API in the future, and doesn’t block compatibility here.”

In September 2015, McCue and contributors outlined a merge plan for the REST API which brought the infrastructure into the 4.4 release with the endpoints on deck to follow one release later in 4.5. Contributors to the REST API believe that the project is still on track for this goal.

“Our proposal is that we ​merge the four core objects​ in the REST API with full read, create, update, delete support, with the more peripheral features to come ​when they’re ready,” McCue said.

Several WordPress contributors, including project lead Matt Mullenweg, voiced concerns about the REST API shipping without the features that have been temporarily spun out.

“I know it’s a minority opinion, but I would be pretty skeptical of merging a partial API into core,” Mullenweg said. “I think it would do a lot more damage than benefit.”

McCue contended that the team has been working towards shipping a product that can be progressively enhanced.

“The API is specifically structured around progressive enhancement, which is a key difference from many APIs,” he said. “Allowing clients to detect features and support them when they’re ready allows us huge flexibility.”

Does the WP REST API Need Full wp-admin Coverage?

Aaron Jorbin noted that while the four core object types allow for some innovative themes and content editors, they do not yet allow for full wp-admin replacements. This particular point was a deal breaker for several contributors attending the meeting.

“The cases where the current API covers today aren’t terribly interesting because they’re not really enabling something that was impossible to do before,” Mullenweg said. “It’s just a different approach to doing something that was already possible before. I don’t even think we have XML-RPC parity of feature support yet.

“I wouldn’t have included REST examples in the SoTW, or encouraged plugins to use the scaffolding, or even let the scaffolding in the last release, if I didn’t think it was the most promising thing out there right now,” he said. “But uptake definitely feels slower than I would have expected. It’s taken so long to get to this point, if we don’t pick up the pace, it could be another year or two before we get full wp-admin coverage.”

Despite the fact that the WP REST API recently had its own conference dedicated to it, most of the people who are building with it are those who are also contributors on the project. Adoption is not yet widespread, but this could be due to the fact that many developers don’t want to build on it until the core endpoints are officially merged.

“We’ve got a bit of a chicken and egg: without core adoption, potential API consumers are hesitant to take the plunge, but without adoption it won’t be tested sufficiently to be merged,” REST API contributor K. Adam White said.

“From a project point of view I’m not really excited about shipping an API that has ‘some assembly required,’ vs making the core release paired with interesting non-trivial killer apps (mobile apps, something calypso-like, big plugins using / supporting it),” Mullenweg said. “To me a complete API is one that covers everything that’s possible within wp-admin. A subset of that is a partial API.”

Multiple contributors on the REST API project, however, agreed that shipping with full admin replacement capability is unrealistic, especially after Mullenweg confirmed that it should support everything possible in the admin, including the file editor.

“We’re significantly more interested in getting read/write access to core types, so that we can interact with WP from a host of other platforms,” K. Adam White said. “I think that pushing everything off until it’s ‘Calpyso ready’ blocks myriad use cases before they can get off the ground.”

In response, Mullenweg asked why WordPress should support something in its web interface that isn’t supported through its official API. At the conclusion of the two-hour meeting he summarized his final proposal: “No partial endpoints in core. Let’s design a complete API, not half-do it and foist it on millions of sites,” he said.

This is a critical juncture for the WP REST API project. While most contributors seemed agreed on further iterating the existing endpoints and ramping up usage before merging them into core, attendees remained divided about the need to have full wp-admin coverage prior to merge.

WP REST API team members are squarely committed to iterating separately on peripheral features, but another contingent of WordPress contributors who joined the meeting yesterday are adamant about seeing a more polished API with better support for the admin. A plan forward has not yet emerged.

Shiny Updates Version 2 Adds Functionality for Themes and Bulk Plugin Updates


With all of the design improvements to the plugin and theme screens in recent WordPress releases, the experience of updating extensions started to feel clunky and disjointed. The Shiny Updates feature plugin was created to hide what project contributors refer to as the “The Bleak Screen of Sadness.”

WordPress users received a small taste of shiny updates when the feature was applied to plugin updates in the 4.2 release, but themes still lag behind. For example, when you update a theme, WordPress lets you know exactly how hard it is working behind the scenes to make that happen:

Downloading update from https://downloads.wordpress.org/theme/cover.1.6.4.zip…

Unpacking the update…

Installing the latest version…

Removing the old version of the theme…

Theme updated successfully.

Shiny Updates hides the ugly parts of updates in favor of making the process appear more effortless. Instead of taking the user to a new screen, updates happen in the background without the need to refresh the page.

The project is currently a feature plugin in development for WordPress core, led by Konstantin Obenland. In a recent status update Obenland said that the new version of the plugin aims to extend shiny updates to all aspects of updates, installs, and deletes for plugins and themes in WordPress.

Version 2 of the plugin currently offers the following:

  • Deleting single plugins, bulk updating, and bulk deleting plugins from the plugin page.
  • Shiny plugin installs from the plugin install screen: multiple actions can be queued up.
  • Shiny theme installs, updates, and deletes, multiple queue-able, including multisite.

Development for the Shiny Updates project is happening on GitHub where the team is collaborating on design and UX improvements. One of their goals, according to the most recent update, is to refine the user experience by “improving perceived performance and limiting confusing notifications.”

Update All the Things

WordPress’ update process is somewhat fragmented when there are multiple updates available for core, plugins, and themes on the update-core.php screen. Shiny Updates contributors are exploring a button that would “update all the things” in one pass. The dedicated issue on GitHub has 28 comments of discussion and design mockups for what an “Update All” process might look like.

In addition to adding an Update All functionality, contributors are also working on the following issues:

When asked whether Shiny Updates will be ready for inclusion in the upcoming 4.5 release, Obenland said, “Even though we’re fairly far into what we want to accomplish with v2, there are still a good number of tasks outstanding.

“I’m going to reach out to the a11y group for a review soon and have already gotten in touch with a few core committers to have the JS part reviewed,” he said. “We’re also in the process of running more user tests for the new flows. So the decision deadline next week just comes a little too early.”

At this time, WordPress 4.6 is a more likely target for including Shiny Updates in core. If you want to assist the team in getting it ready, install the feature plugin from the official directory or via the Beta Tester plugin. Testing version 2 should include both plugin and theme installation, update, and delete actions on both single and multisite installs. Testers can report any bugs to the project’s GitHub issues queue.

Plugin Review “Inconsistencies”

A few people have complained that they feel the review process is inconsistent. I’d like to take a moment to explain exactly why that happens. The tl;dr is, of course, humans make mistakes. But if you really want to understand what’s going on, read on!

There is no automated review process

This is the big thing. Every single plugin is opened and read by a human being. We download the plugin, read it, and try to catch the myriad things that are wrong, insecure, not permitted, etc. And we’re humans. We do our best to scan/grep for things we know are easy to find (like I love checking for wp-(con|load|blog) to see if that’s being called). But a lot of times things are buried or hard to catch.

This means mistakes are made. We don’t claim to be perfect. We claim to try our best to give you the best review we possibly can for your sake, as well as your users.

Some replies are canned, the process is not

I’m sure a lot of you have gotten an email starting with this:

There are issues with your plugin code. Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in your plugin being rejected.

Yes, that’s a canned auto-reply. In order to get through reviews faster, we have replies for the common issues. Right now I have 60 in A-Text. That means there are at least 60 problems with plugins I see every single day.

This makes us able to keep up with reviews. It’s impersonal, we know, but we try to cite examples from your plugin to help you understand what needs your attention.

We don’t test your plugin on all environments

Sometimes we do. But really that’s your job, not ours. We do if we notice things that are weird and we think may be problematic. Some days we test on VVV with PHP 5.6, sometimes it’s HHVM, and sometimes its PHP 5.2. Why? It depends on what we have available just then.

This means sometimes we catch that you coded something for PHP 5.3 and up and sometimes we don’t.

Every new version is checked top to bottom

Think about that for a second, please. If you submit a plugin and we pend it for changes, and you send us the new version, we read the whole thing all over again. Every. Single. Time. We check to make sure you did your changes first, yes, but then we go back and re-read everything to make sure we didn’t miss anything, or you didn’t accidentally add in something new.

This is why, sometimes, you get an email that starts with “We missed this before…” or “This is also not permitted because…” We’re giving you the best review we can.

No, we don’t list everything wrong

It’s not what you’re thinking. Every time we do a review, we list everything we see that’s wrong. We do not list out, for example, every instance of a non-sanitized/validated POST call. We do not list out every single usage of script tags instead of enqueues. We will give you an example, especially if you miss some on your first edit, but we expect you to know how to search your own code.

This helps you learn how to better vet and review your own code. Also it saves us a little time.

There are multiple people doing reviews

Some of us are better at some thing than others. When we find a plugin we don’t feel confident in reviewing on our own, we raise a flag and ask our cohorts to spot-check our work.

This also lets us hand off troublemakers. Let’s be honest here, folks, we don’t all get along with everyone. When it’s clear we’re at an impasse with someone, we ask each other for help.

Our goal is protecting users first, then you

The people we care about the most are the users who can’t code or who don’t understand the severity of things like offloading CSS. You may think it’s trivial and makes your plugin smaller. Someone in another country could find them sued for not disclosing it. Or your plugin may not work because Google is blocked where they are.

We care about protecting the users from XSS and SQL injections. We care about protecting their information. We care about keeping them safe. But we care about you too! We’re so techy about you documenting ‘This plugin calls service XYZ’ because, yes, the users have a right to know where their data is going, but also because you deserve not to have a slew of angry 1-star reviews that you didn’t tell them.

This is a tricky road to walk. Some people may get exceptions. Some people may teach us more about code! Some people may be told ‘no’ flat out.

Guidelines evolve over time (so do security best practices)

We’re constantly looking over the guidelines and evaluating them for clarity, consistency, supportability, and real-world applicability. Have you read our Detailed Plugin Guidelines lately? You should. Similarly, our security checks have gotten better over time. We used to allow you to call wp-config.php directly. We don’t anymore. The more a specific vulnerability is targeted, the harder we are on your code to ensure you are not the weakest link.

This is for your protection! We’re doing our best to make sure you don’t get dog-shamed for being the reason sites go down.

Remember: We are mortal

I said this to start off this post and I’ll say it again. We, your review team, are human beings.

We make mistakes. We miss things. We read code incorrectly. We don’t test everything as fully as we should. We screw up. We never miss things out of maliciousness or an intent to blacklist you from the repository. We believe you submit your plugins in good faith, and we respect you enough to treat you as adults and point out what you missed or explain how you can do things better.

This means you should give us the same benefit of doubt we give you.

Your Chance to Give Feedback on WordPress’ Accessibility Coding Standards

The WordPress Accessibility team is seeking feedback on a draft that outlines accessibility coding standards for WordPress core. According to the draft, new features should meet the accessibility guidelines before merging into core.

All code released in WordPress must conform with the WCAG 2.0 guidelines at level AA. These basic guidelines are intended for easy reference during development, but do not cover all possible accessibility issues.

While the document focuses on core, it’s also a great reference for developers who want their themes and plugins more accessible.

Matt Mullenweg Addresses WordPress’ Accessibility

For the second year in a row, Morten Rand-Hendriksen, an advocate for improving WordPress’ accessibility, brought up the topic during the Q&A portion of the 2015 State of the Word.

Hendriksen notes that in 2014, the WordPress theme directory contained 14 themes with the accessibility-ready tag. In 2015, that number increased to 79.

Hendriksen brings up the fact that when WordPress adopts modern technologies, so does most of the web citing responsive images as an example. He asks Mullenweg if WordPress can do the same for accessibility in which the audience responds with applause. Mullenweg responds with a simple yes.

Thinking of Accessibility as Just a Checkbox

Hendriksen then asks a follow-up question, “Can you tell everyone in this room and community that when they learn JavaScript, to also add on that little accessibility part, so that we’re building everything accessible and tell the world that the web should be accessible and that’s the WordPress way?”

Mullenweg responds by agreeing the web should be accessible but says, “I’m worried about getting to a point where we think of accessibility like a checkbox. Even though there are great guidelines and things like that, I think that accessibility is a process and it’s going to be driven sometimes not by every single person, but by groups like the amazing accessibility team and most importantly by the people who need the technology, communicating, and us observing that.

“So, I do think that we have presentations on accessibility at every single WordCamp, we have the accessibility guidelines online but I think we’re a little behind on the theme reviews which is part of the reason the number hasn’t grown as much because the accessibility reviews are more difficult than a standard review, but I’m really excited about what this group has been able to do and the growing momentum it’s gained in the WordPress world.”

“I don’t think that saying I want things to be accessible moves things forward as much as the continuing education that we’re doing through every single WordCamp, the guidelines, and the group,” Mullenweg said. He also highlights the need to think of accessibility in a global sense.

“I think about the 6.99 billion people who haven’t used WordPress yet and many of those who can’t. I also think about accessibility in terms of languages and touch devices.

“These are things that as we get there, what we do right can expand to a larger audience. I encourage everyone to keep that in mind, but learn JavaScript as well,” he said.

Mullenweg’s responses reinforce the fact that accessibility remains a priority for the WordPress project. If you notice a typo or want to give feedback on the WordPress accessibility guidelines draft, please leave a comment on the post. Also, check out the Make WordPress Accessible site for information on how you can help make WordPress more accessible.

Catching Bad Code Before It Happens

It’s not that easy.

We’ve got more spam/bad code in the plugin repository than anyone would like to see, and while we do manually curate plugin submissions, we don’t actively or even passively patrol all checkins for the bad stuff. We just can’t. We’re human, and with 600-1000 check ins a day, we can’t keep up unless it was a full time job and we were a Nacin-Bot.

While we have been adding on filters to plugins, to try and curtail the outright bad stuff without needing human intervention, setting up filters and checks that work more than 10% of the time has been a monumental effort. And frankly, 10% just ain’t good enough. We still have to scan the whole repository for bad code on a semi-regular basis, and manually curate the naughty list. The pre-commit tool we have there now checks for base64 and eval and other obvious stuff. It also can check for non-obvious stuff, such as variable function calls (thanks to PHP’s tokenizer). Until we can get up to 80-90% reliability with those checks, there’s no point in them, since the manual work remains intact.

And this is where you, the merry followers of this blog, come in. You’re smart people. You know what bad code is. You know what hacks look like. You love regex and filters. You scan plugins for the sheer fun of it (or because your work needs you to). We want your help. We want your code.

How do you do it? What filters do you use, what strings do you look for, and what’s your best trick to catching the bad guys?

I know you hate bad code as much as we do, and we won’t get to awesome without your help!

What is a SEO Friendly URL Structure in WordPress

Have you ever wondered what’s the most SEO friendly permalink structure in WordPress? We’re often asked this question by new users. That’s because in the past, the default WordPress URL structure was not SEO friendly at all. However that’s changed now. In this article, we will explain WordPress SEO friendly URLs, and how you can customize your WordPress permalinks.

SEO Robot

What is a SEO Friendly URL?

Before we go too deep into WordPress permalinks, it’s important that we define what is a SEO Friendly URL.

SEO Friendly URLs contain keywords that explain the article, and they’re easy to read by both humans and search engines. They also improve your chances to rank higher in search engines.

Example of a SEO friendly URL:


So what does a non-SEO friendly URL look like?


By default, WordPress now uses the post name in the URL which is the most SEO friendly URL structure.

So why do beginners still ask us for best permalink structure?

That’s because in the past, WordPress did not use pretty URLs also known as permalinks. The default used to be the non-SEO friendly example that we shared above.

This was changed in WordPress 4.2. If you recently installed WordPress, then your site URLs are SEO friendly.

You can easily verify your permalink settings in your WordPress admin area.

The Permalink Settings Page Explained

In WordPress, links are called Permalinks (short for permanent links). You’ll see the term permalink structure and URL structure being used interchangeably.

First thing you need to do is to visit the Permalinks settings page in your WordPress admin area.

Simply click on Settings link in the admin menu and then click on Permalinks. This will take you to a page that looks like this:

Permalink settings page in WordPress

As you can see there are number of choices available.

  • Plain
  • Day and name
  • Month and name
  • Numeric
  • Post name
  • Custom Structure
    Choose your own URL structure using available tags.

Let us explain these options a bit, and how useful they are for users and SEO.

The first option which is called plain used to be the default WordPress URL structure. This is not an SEO friendly option.

The day and name option is somewhat SEO friendly as it has the post name in it. However, with dates, the URL becomes too lengthy. But more importantly after some time your content seems outdated, even if you regularly update it. Similarly, the month and name option also runs the risk of being dated.

However if you’re a news publication, then you want to have the dates in your URL to show the recency and improve the user experience.

In our opinion, those two structures are only good for news sites. Business sites that are hoping to create ever-green content should avoid it.

Post name option is the most SEO friendly because it is short and pretty.

If you are running a larger publication, then you can use a custom structure that can also be SEO friendly.

At WPBeginner, We use a custom permalink structure that adds a category name along with the post name in the URL. Because our site is large and contain thousands of articles, it suits us very well. You will see larger publications follow a similar URL structure.

In order to use a custom URL structure, you will need to add special tags in the custom structure box. For example, we use:


Notice how each tag is wrapped between percent signs. Also notice the trailing slashes / before, after, and between the tags.

Creating Custom URL Structure with Available Tags

For the best results, we recommend using the options we mentioned above. You can copy the URL structure we use on WPBeginner or choose the post name as your URL structure.

However, there are plenty of other combinations you can create using tags. Here is a list of tags that you can use to create your own custom URL structure:

  • %year% – The year of the post, four digits, for example 2016.
  • %monthnum% – Month of the year, for example 05
  • %day% – Day of the month, for example 28
  • %hour% – Hour of the day, for example 15
  • %minute% – Minute of the hour, for example 43
  • %second% – Second of the minute, for example 33
  • %postname% – A sanitized version of the title of the post (post slug field on Edit Post/Page panel). For example, if your post title is This Is A Great Post! It would become this-is-a-great-post in the URL.
  • %post_id% – The unique ID # of the post, for example 423
  • %category% – A sanitized version of the category name (category slug field on New/Edit Category panel). Nested sub-categories appear as nested directories in the URI.
  • %author% – A sanitized version of the author name.

Don’t forget to click on the save changes button after choosing your permalink structure.

As soon as you press the save changes button, WordPress will automatically update your site’s .htaccess file and your site will immediately start using the new URL structure.

Warning: Important Note for Established Sites

If your site has been running for more than 6 months, then please don’t change your permalink structure.

You don’t have to use the same structure that we used.

By changing your permalink structure on an established site, you will lose all of your social media share count and run the risk of losing your existing SEO ranking.

If you must change your permalink structure, then hire a professional, so they can setup proper redirects. You’ll still lose your social share counts on the pages.

There’s only one exception to this rule. If your site is using the plain URLs, then no matter how old it is, you should update the URL structure for better SEO. Yes, you will still use social share counts, but the benefits far outweigh that.

We hope this article helped you create a SEO friendly URL structure for your WordPress site. You may also want to see our guide on categories vs tags – SEO best practices for sorting your content.

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 What is a SEO Friendly URL Structure in WordPress appeared first on WPBeginner.

WordPress is Revamping Its Testimonials Page with #ilovewp Social Media Campaign

photo credit: Wear your heart on a string - (license)
photo credit: Wear your heart on a string(license)

WordPress.org is getting some love in 2016. In addition to a beautifully redesigned login page, the testimonials page is in the process of being completely revamped.

The update comes not a moment too soon, as the old testimonials page included entries dating back to 2003 with what are now rather humorous references to b2 and Moveable Type:

I had been an avid b2 user for the last 6 months or so, but then decided to take advantage of WordPress’s features, commitment to extra development and stable codebase. So far, so good. – BC

From my just under 24 hours of experience with WordPress, I’m a happy man. This is fantastic code, and it’s only just getting on its feet! The updates that are forthcoming promise to make this one of the premiere weblog engines on the web today. Good work! I eagerly await your future versions! — Aaron Mildenstein

Aaron Mildenstein may have been peering through a crystal ball when he wrote that testimonial 13 years ago, as WordPress now powers 25% of the web. The software and the community have changed drastically from those early days when it was still vying for legitimacy. There are now more CMS options than ever, and WordPress is the leader of the pack.

Yesterday, Matt Mullenweg posted a call for users to share what WordPress means to them using the hashtag #ilovewp on WordPress, Twitter, or Facebook.

“Think of something that you love about WP that would make someone who hasn’t heard of it, or is on the fence about using it, compelled to try it out,” Mullenweg said.

Twitter is filling up with heart-warming snippets of how WordPress has opened up opportunities for people to make a living and be a part of a community that is changing the web:

The most striking change in the testimonials today versus the early ones in 2003 is that WordPress is now much more than the sum of its distinguishing blog features. For many users, WordPress means a chance to make a living while taking care of their families and a chance to connect to a global community of people who believe in open source software.

As for me, I love WordPress because it gives people a voice. It puts the power of publishing into the hands of every day people. I also appreciate that the people behind WordPress, all the way up to the very top, are defenders of free speech and advocates of the open web. Even if the technology behind the software makes radical shifts, WordPress’ guiding principles are what make it a publishing platform that will stand the test of time.

How to Fix WordPress RSS Feed Errors

Are you encountering a RSS feed error on your WordPress site? Recently one of our readers asked us how to fix WordPress RSS feed errors. There are multiple type of RSS feed errors and they can be caused by changes in plugins and themes. In this article, we will show you how to find and fix WordPress RSS feed errors.

WordPress RSS feed error

Most Common WordPress RSS Feed Errors

Most common WordPress RSS feed errors are caused by poor formatting. WordPress outputs RSS feeds in XML which is a strict markup language. A missing line break or an extra tab can break your RSS feed.

The RSS error message will look something like this:

XML Parsing Error: XML or text declaration not at start of entity
Location: http://example.com/feed
Line Number 2, Column 1:

Depending on what browser you are using, your RSS feed error message may vary.

You can also see this error message when visiting your feed in a browser.

Warning: Cannot modify header information – headers already sent by (output started at /home/username/example.com/wp-content/themes/twentysixteen/functions.php:433) in /home/username/example.com/wp-includes/pluggable.php on line 1228

If you are using FeedBurner, then your errors may look different.

Having said that, let’s take a look at what causes these RSS feed errors and how to fix them.

Manually Fixing RSS Feed Errors in WordPress

The most likely reason for your RSS feeds to show error is poor formatting. This poor formatting can be caused by a blank space after closing php tag in a plugin or in your theme’s functions.php file.

If you recently added a code snippet to your theme or child theme‘s functions.php file. Then you need to edit your functions file.

If there is a closing php tag at the end of your functions file, make sure that there is no extra space or line breaks after it.

Ideally, the closing PHP tag is not required at the end of the file. This is why it would be best if you remove the closing php tag altogether.

This should fix the problem in most cases. However, if it does not fix your RSS feed error, then continue reading.

Fixing WordPress RSS Feed Errors Using Plugin

First thing you need to do is install and activate the Fix My Feed RSS Repair plugin. Upon activation, simply go to Tools » RSS Feed Fix page.

Fix RSS feed button

Click on the Fix feed button and that’s all.

You can now visit your feed in a browser window or test it with a feed validator tool.

We hope this article helped you fix WordPress RSS feed errors on your site. You may also want to take a look at our guide on how to make separate RSS feed for each category in WordPress.

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 WordPress RSS Feed Errors appeared first on WPBeginner.

HTTP 451: content unavailable for legal reasons

At the end of last year, a new HTTP status code saw the light. This status code, HTTP 451, is intended to be shown specifically when content has been blocked for legal reasons. If you’ve received a take down request, or are ordered by a judge to delete content, this is the status code that allows you to indicate that. The upcoming Yoast SEO Premium 3.1 release will have support for this new status code, allowing you to set a HTTP 451 status code for pages.

HTTP 451 status code introduction

What does HTTP 451 mean?

The HTTP 451 header is introduced with the specific meaning of making it explicitly clear when content is blocked for legal reasons. Or, in the wording of the official draft:

This status code can be used to provide transparency in circumstances where issues of law or public policy affect server operations.

While the end result is the same as for instance a 403 Forbidden status code, this status code makes it much clearer what is happening. It might make you search for something just a little bit deeper. The original idea stems from this blog post which is worth a read.

How to set an HTTP 451 header

There are two ways to set an HTTP 451 header:

Deleting the post or page

In the upcoming Yoast SEO Premium 3.1 release we’ve changed what happens when you delete a post or page. You will now get the following notice:


The link underneath “Read this post” links to my earlier article about what to do when deleting a post or page. Because we’re assuming that most of the time when you delete content, it has nothing to do with a court order (we sure hope so), we haven’t added the 451 option here.

Creating a header without deleting the post or page

You can also just keep the post or page alive, which is especially useful if the court order, injunction or whatever it is that is forcing you to block the page, has a time restraint. Simply go into the redirects screen of Yoast SEO and create a 451 header for that specific URL:


An HTTP 451 template file

Along with the changes that allow you to set a 451 HTTP header, we’ve also created the option to have an HTTP 451 template file in your theme. It’s as simple as copy pasting the 404.php file in your theme to 451.php and modifying the content to have a good message.

I honestly hope you’ll never need this HTTP error, but if you do, you know now that you can do the right thing, provided you’re using Yoast SEO Premium!

Michael Arestad Sparks Renewed Effort to Improve the Content Creation Experience in WordPress

In 2013, Mel Choyce, Design Engineer at Automattic, published a proposal to improve the content creation and editing experience in WordPress. Her proposal and associated mockups like the one below, generated a lot of discussion. However, the project lost steam and major changes to the Add New Post screen were not implemented.

Post Writing/Editing Interface Concept From 2013

The post editor has undergone numerous improvements over the years from metaboxes in WordPress 2.0 to oEmbed support in 2.9. Here’s what the post editor looked like in WordPress 3.0.

WordPress 3.0 Post Editor Interface
WordPress 3.0 Post Editor Interface

Michael Arestad, Designer at Automattic, is sparking renewed interest to revamp the content editing and creation experience in WordPress. The project is composed of several smaller projects such as, the publishing user experience, automatic saving, the toolbar, metaboxes, and more.

“A few of us have been talking about getting these projects going for a while so I wanted to see how much interest there is and how many contributors we have to work with. I am by no means leading this as much as doing what I can to get the people interested in some of these projects going on them. I’ll personally be working on some of the longer projects,” Arestad told the Tavern.

A few people have already committed to parts of the project. Tammie Lister is leading a team focused on improving the Revisions UI while Hugo Baeta is leading the Toolbar Remix team.

The Revisions UI project is focused on experimenting with alternative interfaces to improve user friendliness with a secondary goal of providing a way for users to quickly switch between revisions. The Toolbar Remix team will audit the toolbar in the editor and determine whether buttons should be rearranged, added, or removed.

“Most of these projects will span multiple releases depending on the complexity of implementations and the number of usability tests required. There might be a few small ones that make 4.5,” Arestad said.

A majority of the projects are in the beginning stages. If you’re interested in contributing to an initiative, contact Arestad on SlackHQ or the person leading the project that interests you. You can also leave feedback by commenting on the proposal.

Looking Forward to Change

I work in the post editor everyday and while it’s a good experience, I want to experiment with alternative interfaces like the conceptual editor in the screenshot above. Consolidating metaboxes into the visual editor is a refreshing idea that I want to use in the real world to see if it speeds up my workflow.

If I were a betting man, I’d say the Add New Post screen is the most viewed and used part of the WordPress backend. Any changes to the editor and experience will affect a large number of users as evidenced by the removal of the View Post and Get Shortlink buttons in WordPress 4.4. However, any change that is implemented will likely be meticulously calculated by the core team.

What changes to the Add New Post screen do you want to see that would improve the way you create content in WordPress?

How to Add the Skype Share Button in WordPress

Did you know that Skype has a share button? We didn’t either until a reader asked us for a tutorial on how to add the Skype share button in WordPress. Skype is one of the most popular communication apps in the world. In this article, we will show you how to easily add a Skype share button in WordPress.

Skype Share Button

First thing you need to do is install and activate Skype share plugin (see our beginner’s guide on how to install a WordPress plugin).

Upon activation, go to Settings » Skype share button page to configure the plugin.

Skype share button settings page

The first option is to enable the share button. You must check this box to enable the Skype share button on your WordPress site.

Next, you need to choose a button size. Available sizes for the button are large share, small share, circle icon, and square icon.

Lastly, you need to choose the location of the button. You can either choose to show it on top of the article, below the article, or both.

Skype share can automatically detect the language of your WordPress site. But if it doesn’t, then you can manually select the language.

Don’t forget to click on the save changes button to store your settings.

That’s all, you can now visit your website to see the Skype Share button in action.

preview of Skype share button

Manually Add Skype Share in WordPress Template

If you want to manually add this in your theme files, then you can follow the manual code instructions below.

First add the following script in the head section of your file. You can either do this by directly editing your header.php file or do it the proper way of adding scripts by using Enqueue scripts.

// Place this code in the head section of your HTML file 
(function(r, d, s) {
	r.loadSkypeWebSdkAsync = r.loadSkypeWebSdkAsync || function(p) {
		var js, sjs = d.getElementsByTagName(s)[0];
		if (d.getElementById(p.id)) { return; }
		js = d.createElement(s);
		js.id = p.id;
		js.src = p.scriptToLoad;
		js.onload = p.callback
		sjs.parentNode.insertBefore(js, sjs);
	var p = {
		scriptToLoad: 'https://swx.cdn.skype.com/shared/v/latest/skypewebsdk.js',
		id: 'skype_web_sdk'
})(window, document, 'script');

After that add the following code in your single.php, loop.php, index.php, page.php, category.php, and archive.php as long as it is placed within the post loop.

<div class='skype-share' data-href='<?php the_permalink(); ?>' data-lang='en-US' data-text='<?php the_title(); ?>' data-style='large' ></div>

You can change the data-style to large, small, circle, or square.

You can also change the language to your desire language.

Basically, the code above will allow the user to share the individual post with the post title as the message.

We hope this article helped you add Skype share button on your WordPress site. You may also want to see our guide on how to how to add clickable phone numbers for smartphones in WordPress

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 the Skype Share Button in WordPress appeared first on WPBeginner.

Reminder: Policy About Tags In Plugin Readmes

This is a reminder of current policy.

We ask that users limit tags in their plugins to no more than 12 (twelve), with some exceptions. Any time your plugin has a high number of tags, you’re seen as trying to game the system.

How do you fix this?

  1. Remove any ‘common misspellings’ from your tag list
  2. Remove duplicate tags
  3. Don’t use ‘wordpress’ or ‘wp’ in your tags
  4. Don’t use tags that don’t apply
  5. Don’t use your competitors in your tags (if you’re not a woocommerce plugin, don’t list it)
  6. Don’t list everything under the sun related to your plugin
  7. Do use tags that clearly identify what your plugin is

As much as some people like to think, “tags” are not the same as “search terms” in our system, so including lots of them doesn’t really benefit you much. By adding multiple tags, you reduce the efficacy of searches and tags for everyone and make the experience of looking for a plugin suck. Yeah. You did that to yourself.

If you’re looking to improve your search rankings, we suggest improving the parts of the readme intended for human beings to read. The short and long descriptions should be clear and useful. Addressing common problems in the “FAQ” section helps too. The entire contents of the readme file is considered for the search, and tags are really only a small part of that. Removing irrelevant pieces such as lists of languages (like links) or feature bullet points may help a lot as well, to reduce the overall length and to help eliminate irrelevant information about the plugin.

Make the readme for people, not for machines, and it will help you rank higher in the search results. People actually search for solutions to their problems, not simply for keywords.

Matt Mullenweg Addresses Concerns That WordPress is Moving Too Fast

RoadRunner Featured Image
photo credit: steevithakcc

There are at least three major releases of WordPress per year where users can expect new features and major bug fixes about every four months. While this is great for users, some companies, plugin, and theme developers are struggling to keep up.

We recently received the following email from a reader concerned with WordPress’ release strategy:

As the pace of WordPress releases grows, plugin and theme developers have to constantly update their products. This is leading to a real and growing problem among WordPress site owners and companies like mine that handle website maintenance and updating.

This pace is leading to an almost daily need to fix problems, caused by these updates. Plugin updates tend to break things, even though we primarily use professional, paid plugins for the idea of support and generally better quality products.

I get that it’s important to patch security issues, but we’re also seeing a lot of new functionality, moving plugins into core, and other changes. These cause theme developers to push out updates with great frequency and they make mistakes.

I’m worried that the pace of core updates is driving the larger ecosystem toward failure. Everyone is scrambling to keep things patched, then new conflicts arise and things break down. The person on the end ‘companies maintaining their sites, responsibly, or services like mine’ face a constant flow of updates, then testing, then trying to fix things that have broken.

Matt Mullenweg, Co-founder of the WordPress open source software project, specifically addressed this issue during the Q&A session of the 2015 State of the Word at WordCamp US. Mika Epstein, who voluntarily reviews and approves plugins for the WordPress plugin directory, voiced the concerns shared by developers who are struggling to keep up.

With the myriad of technologies developers have to learn, including the REST API and JavaScript, Epstein asked Mullenweg if WordPress is moving too fast and if the number of releases per year should decrease by one.

Mullenweg answered the question by saying improvements can be made to the plugin directory so that users can share the burden in the testing process. He also said that the speed of WordPress development will increase instead of decrease. Meanwhile, the development team will continue to release three major versions per year.

He then describes a future where developers may be able to lessen their support burden by using the REST API that’s slated for WordPress 4.5. He also cites how large webhosting companies, such as Bluehost, have automatically upgraded most of the WordPress sites on their network to the latest stable version. Mullenweg ends his response by apologizing to those who feel WordPress is moving too fast but says its worked so far.

How Do You Keep Up With WordPress?

While we do a great job of keeping users and developers informed, plugin and theme authors should subscribe to the Make Plugins and Make Themes sites respectively. Anyone involved with maintaining WordPress sites should subscribe to the Make Core site where important information related to core is published.

We know that the release strategy isn’t going to change so whether you’re a developer or someone in charge of maintaining sites, how are you keeping up with WordPress?

How to Show Excerpt of a Password Protected Post in WordPress

Did you know that you can password protect your WordPress posts? By default, WordPress does not show the contents of a protected post to users unless a password is entered. However, there are a couple of ways you can password protect posts while still showing a teaser or excerpt. In this article, we will show you how to show excerpt of a password protected post in WordPress.

Showing excerpt for password protected posts

Method 1: Manually Showing The Excerpt of a Protected Post

First thing you need to do is to copy and paste this code snippet in your child theme‘s functions.php file or a site-specific WordPress plugin.

function wpb_protected_excerpt( $excerpt ) {
if ( post_password_required() ) {
$post = get_post();
return $excerpt;
add_filter( 'the_excerpt', 'wpb_protected_excerpt' );

function wpb_protected_excerpt_posts( $content ) {
if ( post_password_required() && is_single() ) {
$post = get_post();

return $post->post_excerpt.$content;
add_filter( 'the_content', 'wpb_protected_excerpt_posts', 10 );

Now go to Posts screen in WordPress to edit your password protected post and click on the screen options button on the top of the page. This will reveal a menu with a bunch of options. You need to make sure that the checkbox next to excerpt is checked.

Enabling excerpt meta box on post edit screen in WordPress

This will display the excerpt meta box below the post editor. You can enter your post’s excerpt in this box.

Adding excerpt for your password protected post in WordPress

Before publishing your post make sure it is password protected. Now you can visit your website, and you will be able to see the excerpt for the password protected post in WordPress.

Showing excerpt for a password protected post in WordPress

Method 2: Using a Plugin to Restrict Content

Using password protected posts is easier, but it does not give you the control you need to make sure that the right users have the access to the post.

If you run a multi-user WordPress site, or you are willing to open your site for registration, then using a plugin to restrict access to posts is a much better option.

It allows you to control which users have access to your protected posts, and you can easily control how much content you want to show to other users. Think of it as a membership site with multiple subscription levels.

First thing you need to do is install and activate the Restrict Content Pro plugin. Upon activation, you need to visit Restrict » Settings to configure the plugin.

Restricted content settings

You will need to provide the message users will see when they do not have the permission to view a protected content. Once you are done simply click on the save changes button to store your settings.

Now you can create a new post or edit an existing post that you want to protect. Simply add the content you want to show as excerpt in the post content area, and then wrap rest of the content that you want to hide between [restrict] [/restrict] tags.

Restrict Content shortcode

Important: You don’t need to make a post password protected from the publish menu.

You can also show excerpt to all users and give access to only logged in users, by using the Restrict Content meta box below the post editor. Simply check the box next to excerpt and choose a user role.

Choosing a subscriber user role will allow all registered users on your site to view the post when they are logged in. Non logged in users will be able to see the excerpt only.

Allowing only logged in users to view content

Selling Premium Content on Your Site

Restrict Content Pro also allows you to sell memberships for premium content. You can accept payments using Stripe, PayPal, and Braintree.

Accepting payments for protected content with Restrict Content Pro

You can create subscription packages for users which they can choose from when registering on your site. You can decide what content users will be able to access for their subscription level. You can also have multiple subscription levels.

For detailed instructions, please take a look at our guide on how to restrict content to registered users in WordPress.

We hope this article helped you show excerpt for password protected posts in WordPress. You may also want to see our list of 40 useful tools to manage and grow your WordPress blog.

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 Show Excerpt of a Password Protected Post in WordPress appeared first on WPBeginner.

How to Include Styles in Child Themes

This DigWP tutorial explains the "new" way to include parent stylesheets in Child Themes. I put the word "new" in quotes because the technique actually has been around for years, but there are many developers and designers who still use the old @import way of adding parent styles. This tutorial is for people who may be unfamiliar with using WordPress’ enqueue functionality for Child Themes. Here you'll find copy-n-paste techniques, examples, caveats, and numerous resources. Basically everything you need to know about including styles in your Child Themes.


How to Fix Image Color and Saturation Loss in WordPress

Recently, one of our readers asked us for a way to prevent image color and saturation loss in WordPress? This is a common problem faced by many WordPress users uploading photos and images. In this article, we will show you how to fix image color and saturation loss in WordPress.

Image color and saturation loss in WordPress

Why Some Images Loose Colors and Saturation in WordPress?

Many photographers capture photographs using Adobe’s RGB color space which has more colors and offer much better results.

However most web applications like WordPress, use RGB color space. When you upload your image, WordPress creates several image sizes. These images use RGB color space which has less colors than Adobe’s RGB format.

WordPress also uses compression on the resized images which may also contribute to slight quality loss. Here is how you can increase or decrease WordPress jpeg image compression.

Images captured with Adobe sRGB color space are more vibrant and accurately display colors in high tones. When converted by WordPress, those vibrant colors are replaced with slightly muted tones.

Color and saturation loss in WordPress

Having said that, let’s see how we can prevent this image color and saturation loss in WordPress.

Fix Color and Saturation Loss for Images in WordPress

The easiest way to fix this is by converting your images to RGB color space before uploading them to WordPress. This can be easily done using Adobe Photoshop.

In Adobe Photoshop, go to Edit » Color Settings. This will bring up the color settings dialog box.

Changing color management policies in Adobe Photoshop

You need to select ‘North America Web/Internet’ from the settings drop down menu. Next, under color management policies section, select the RGB to ‘Convert to Working RGB’. After that click on the OK button to save your settings.

Now you need to open the original photograph or image that you wanted to upload. If the working space profile mismatches, Photoshop will show a warning and will ask you what to do.

Mismatch Color Profile

You should select ‘Convert document’s color to working space’ and then click OK. Your photo’s color profile is now more accurately converted. You can now save the image to preserve your changes.

Repeat the process for all the images that you want to upload. Now you can safely upload these converted images without any color or saturation loss in WordPress.

We hope this article helped you fix image color and saturation loss in WordPress. You may also want to see our guide on 4 ways to prevent image theft in WordPress.

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 Image Color and Saturation Loss in WordPress appeared first on WPBeginner.

2015 Community Summit And How You Can Help the Plugin Team

Sadly, many of the same reasons we could not add new members to the Plugin Team last year are still an issue (see 2014 Community Summit Wrapup). The codebase has been improved, but the process is slow. Just to give you some hope, the work done on the Theme Repo is being used to help us. So. Soon. Soon. We’re restructuring the backend to make it more clear as to who can do what, but most things are waiting on the re-vamp.

The only real ‘news’ is that we’ve been sneakily moving our documentation over to https://developer.wordpress.org/plugins/wordpress-org/ – Please check it out to keep up with all the information about what makes good plugins in the repo. Oh, and we’ve swapped reps. I’ll be taking over as the plugin team rep and that really changes… nothing at all. @boone did a great job and I thank him for it.

You Can Help

While we are still stuck on the old system, you can jump in and help us by emailing plugins@wordpress.org when you find people playing fast and loose with the rules.

We encourage and welcome updates from everyone, but please don’t be snippy. Be serious. If someone has powered by links, or is phoning home, yes, please let us know. But don’t let your personal feelings get in the way. This is a big deal. A lot of people send us reports from a place of anger. Don’t be that person. That person makes it harder for us to figure out if someone has a personal vendetta against a plugin and/or developer, or a legit concern. We’re all passionate, but remember to channel that passion into something beneficial.

How to Report Issues

If you’ve found a plugin _doing_it_wrong(), email plugins@wordpress.org and remember:

  1. Make your subject clear. (“XSS Vulnerability in Hello Derpy” or “Derpack Developer swearing at users in forums” are good)
  2. Always provide an exact link to the plugin.
  3. Report plugins with guideline violations.
  4. Report developers who are behaving badly.
  5. Be detailed. If you know what file and line of code is the problem, tell us.
  6. Provide examples of vulnerabilities. If you already know what’s hackable, show us. It makes it faster for us to verify and reproduce. Link to forum threads etc etc.

Remember: We don’t retroactively enforce guideline changes unless there is a legal, copyright, or security related reason. For example, we no longer allow new plugins to call wp-load.php directly, however we don’t hunt around for plugins that do so. If a plugin is closed for using a non-GPL library and, in the review, we note other best-practices violations, we will require them all to be fixed before reopening.

Also, we won’t be following up with you as to what happened most of the time. We’d love to. We can’t and keep up with emails. Please don’t take it personally. As we add more people to the team we may be able to change that, but right now it takes us away from validating security issues.



Rami asked “What do you guys even use to check plugins and look for bad things?” and the real answer is “Our eyes.” We don’t have a theme-check type plugin because there are very few ‘standard’ things to look for (possibly it could check for license issues, including jquery files, and calling wp-load directly sort of things).

Remember: Thou Art Mortal

And so are we.

We’re people too. We make mistakes. We miss things. We have bad days. We get sick. We have families. If we don’t reply to you super fast, please sit on your hands and give us five days. Five. You should get some sort of reply from us within five, even if it’s ‘we’re still talking about this, sorry but it’ll take a while.’ Sending us an enough every 12 hours (yes, someone did that) is annoying.

Hunting us down on Twitter and Slack because we didn’t reply right away is similarly uncool and harassing. We use the email so that everyone on the team can read the conversations. Don’t take it off-line. Keep it in the email and that way, if you’re talking to Otto and he goes to a BBQ fest for two weeks days without access, Pippin can pick up the conversation and help you out.

Just be patient and calm. Especially if we’ve just closed your plugin. We know that sucks, and we totally get you’re angry sometimes. Just try to remember we’re all humans and treat us with respect like fellow humans.

Grumpy Otto (is there another kind?) looking at the camera.

Take the plugin. Leave the cannoli.