Plugin Developers Demand a Better Security Release Process After WordPress 4.2.3 Breaks Thousands of Websites

photo credit: Ravages - cc
photo credit: Ravagescc

WordPress 4.2.3, a critical security release, was automatically pushed out to users yesterday to fix an XSS vulnerability. Shortly afterwards, the WordPress.org support forums were flooded with reports of websites broken by the update.

Roughly eight hours later Robert Chapin (@miqrogroove) published a post to the Make.WordPress.org/Core blog, detailing changes to the Shortcode API that were included in the release. According to Chapin, these changes were necessary as part of the security fix:

Due to the nature of the fix – as is often the case with security fixes – we were unable to alert plugin authors ahead of time, however we did make efforts to scan the plugin directory for plugins that may have been affected.

With this change, every effort has been made to preserve all of the core features of the Shortcode API. That said, there are some new limitations that affect some rare uses of shortcodes.

The security team had no reasonable way of accounting for every single edge case, but the negative impact of these changes were far more wide-reaching than they had anticipated. This particular use case likely wasn’t covered in their testing. Unfortunately, plugin developers found out about the breaking changes only after the security release had already left a slew of broken websites in its wake.

“I fully understand this is an issue, but isn’t this a weird way of updating – almost all our clients are calling / e-mailing us at the moment as their sites seem to be broken,” one developer commented on the Shortcode API post. “Normally it would be better to announce such huge impact changes to the plugin and theme developers. This means I need to fully reschedule my agenda, which already is full during holiday season.”

Comments on the WordPress.org post are full of developers scrambling to find a way to fix client websites. Many were disappointed that the total secrecy of the security team, which is necessary in situations like this, was not immediately followed up with a public post on the important changes to the Shortcode API. Meanwhile, the email inboxes of agencies and plugin developers are filling up with urgent messages from outraged clients.

Developers want better communication from the those who are managing security releases. Amir Helzer, author of Types and Views, two plugins majorly affected by the release, sums up the thoughts of many other commenters on the Make/WordPress.org/Core post:

We are updating the Views plugin today, so that we resolve all shortcodes before passing to WordPress to process content.

This is a straightforward change, which takes us one day to complete.

Would have been great to receive a heads-up about an upcoming change in WordPress, so we could do this change on time.

We received a huge amount of support requests due to this, but this isn’t the issue. We can deal with a wave a support issues. This time it wasn’t “our fault”, but sometimes it is.

What worries us, as mentioned above, is seeing our clients (folks who build WordPress sites for a living), losing their faith in the system. They feel like the system sees them as little ants and not as humans. People don’t like seeing their problems being dismissed.

Many of them run hundreds of sites. They cannot afford to stop everything and fix content on so many sites. Especially not if they are currently away for their family vacation.

What others have asked here, and I would like to ask, too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.

We are your partners.

Without WordPress (secure, stable and reliable), we would not exist.

Without great themes and plugins, WordPress would not power 24% of the Web.

WordPress core members already volunteer a lot of their time. I’m not asking for anyone to volunteer more time. Need help? Ask us. There is a huge community of developers who rely on WordPress. We would be happy to get involved and set up whatever is needed.

User confidence in WordPress’ automatic background updates took a dent with the 4.2.3 release. Waking up to broken websites causes users to second guess automatic updates after being assured that maintenance and security releases would not include breaking changes.

When users get burned by automatic updates, in the end it doesn’t matter which party is at fault – whether it’s the core team or a theme or plugin. They simply expect updates to work and not break anything. Even in instances where a poorly coded extension may be at fault, the average user has no way of determining whether or not their active plugins follow WordPress best practices.

The aftermath of the most recent security release is one reason why many developers and users are still wary of automatic updates. Amir Helzer represents many other plugin developers who are eager to find better ways to work together with the core team to provide a better update experience for users. This is especially important for releases like this one where the Shortcode API changes directly affected users’ content. Hezler’s comment reaffirms the fact that development agencies, plugin developers, and core developers are all partners on the same team. It’s time to find better ways of working together to provide the best update experience possible for WordPress users.

Broken Updates and Personal Website Management

Yesterday a large number of websites were broken due to a security fix that affects the Shortcodes API.

I’m grateful for the security efforts of the WordPress Core team and I do appreciate various fixes that are automatically updated.

2 years ago Ipstenu wrote in her blog something about the automatic updates when people freaked out that the dark holes will unleash on each update:

The reason the updates are restricted to just minor, security/maintenance, updates is that, in general, they do not cause the problems people experienced 2010.

I believe I’ve seen similar statements by core leads and that was expected, and I haven’t seen major problems for a while – at least before the utf8mb4 was introduced. Then a lot of sites around me started to bend under the new database conversion, and the latest change had us staying until past midnight fixing some things that used to be working before.

My friend Amir who owns the business behind WPML and Toolset (Types and Views) commented on the aforementioned post regarding the security fix with something that resonated with me:

We received a huge amount of support requests due to this, but this isn’t the issue. We can deal with a wave a support issues. This time it wasn’t “our fault”, but sometimes it is.

What worries us, as mentioned above, is seeing our clients (folks who build WordPress sites for a living), losing their faith in the system. They feel like the system sees them as little ants and not as humans. People don’t like seeing their problems being dismissed.

Many of them run hundreds of sites. They cannot afford to stop everything and fix content on so many sites. Especially not if they are currently away for their family vacation.

What others have asked here and I would like to ask too, is to setup a mechanism that allows WordPress core developers to privately communicate such upcoming issues with plugins developers.

We are your partners.

Without WordPress (secure, stable and reliable), we would not exist.

Without great themes and plugins, WordPress would not power 24% of the Web.

 

I couldn’t agree more.

And I don’t believe that WordPress is meant for blogs. Maybe it was 12 years ago, but it no longer is. Over the past 3 years we’ve been building SaaS solutions, large Multisite networks with tens of thousands of subsites, and large WordPress solutions for the educational, event management, airline and automotive industries. And when those websites get affected, we’re screwed.

Because even if we disable the updates due to our deployment process, we’re left with a public fix for a security issue that is trivial to resolve by anyone with a decent programming/security background.

So due to the open source model, we’re forced to update – regardless.

Maintenance

Here’s the funny thing.

Maintenance.

Maintenance.

Since WordPress is known to be a “simple blogging platform” or a free and easy system that everyone can set up (even non-technical people), business owners believe that building a website is a one-off thing. I’m not even talking about content marketing, SMM or anything else that actually runs the business. I’m talking about the regular work required for a system to run.

Is your car something that works forever without maintenance? No. You need to change your engine oil every now and then, check your brakes, probably your tires before the winter season, not to mention all of the filters and other small things that make your car move on a daily basis.

So you go to a mechanic? Good.

Same goes for home management, your health, and most of the products that you generally use.

If you don’t maintain them, they rot.

And that maintenance is done by professionals – people who have been long enough in the industry to see all of the nasty problems that happen every now and then, and help businesses run with less troubles and unexpected surprises.

Which is why I’m still frustrated that a minor fix broke tens of thousands of websites. But while some of those were taken care of by experts, many business owners were left alone since they paid for their website and left it online. Simply as that.

No ongoing updates. No feature updates.

We do offer maintenance services for all of our clients, and expect them to understand the significance of the technology. WordPress is currently over 300K lines of code. That huge engine runs 24% of the Internet, and every single change can affect tens of thousands, hundreds of thousands or millions of websites out there.

And anything larger than a simple blog for a teenage homework can be affected. That’s the truth.

If you opt-in for a custom solution built from scratch, you’ll probably encounter other problems and pay way more than a WordPress-driven solution. But if you invest a nickle in your online business and don’t invest in any ongoing maintenance, then you’re dealing with the consequences.

I have an ongoing car maintenance plan that lets me call my mechanics any day of the week and ask them to come and pick up my car if it suddenly stops on the street. And this helps me sleep at night. And I’ve called them already, and they did their magic.

But I’ve been out there under the sun looking at my engine, having no clue what happened, and spending hours trying to be an engineer. And this simply didn’t work out.

So, if you’re aware enough that running a business with some online presence is essential for the future of your business, that’s a good first step. But your product is a vivid creature, that lives and changes constantly, and your business requires an update or two every now and then.

So, have you signed for maintenance already, and did you struggle with the latest Shortcode API update?

The post Broken Updates and Personal Website Management appeared first on Mario Peshev on WordPress Development.

WordPress 4.2.3 is a Critical Security Release, Fixes an XSS Vulnerability

photo credit: Lock - (license)
photo credit: Lock(license)

WordPress users in the Americas woke this morning to find update notices in their inboxes due to a critical security vulnerability. WordPress 4.2.3 was released today and automatically pushed out to sites that have auto-updates enabled.

Because this is a security release for all previous versions of WordPress, those who do not have automatic update enabled will need to manually update their sites immediately. Core contributor Gary Pendergast explained the severity of the bug in the release post:

WordPress versions 4.2.2 and earlier are affected by a cross-site scripting vulnerability, which could allow users with the Contributor or Author role to compromise a site. This was reported by Jon Cave and fixed by Robert Chapin, both of the WordPress security team.

We also fixed an issue where it was possible for a user with Subscriber permissions to create a draft through Quick Draft.

Pendergast thanked all parties reporting vulnerabilities for responsibly disclosing them to the WordPress security team.

This release also contains fixes for 20 bugs from 4.2, including one that might require you to update your database before being allowed back into the admin.

wp-update-db

Not all WordPress users who are updating will be greeted with this message, but if you see it, don’t panic. It’s related to one of the bug fixes included in the release.

“It was a bug fix in 4.2.3, not backported – some versions of PHP didn’t run the utf8mb4 update correctly,” Pendergast said when asked about the required database update.

Unfortunately, in some instances, clicking the “Update WordPress Database” button may require multiple attempts. This is unusual but Pendergast said that improving database upgrades is high on the team’s list of priorities.

A list of all the files revised is available on the 4.2.3 release page.

Yoast SEO 2.3

FB Yoast SEO 2 3 1200x628We’ve just released a major release of Yoast SEO, bringing it up to version 2.3. This new version of Yoast SEO helps you optimize your site and keep it optimized. It shows errors straight from Google’s Search Console, and points you at posts that need work. But first of all, we’ve changed the name!

WordPress SEO by Yoast === Yoast SEO

Nearly everybody we know already called it “Yoast SEO”. We were stubborn enough not to do that. It used to be just “WordPress SEO”. It became “WordPress SEO by Yoast” somewhat later, now, we’ve finally caved. The plugin will henceforth be known as Yoast SEO. Somewhat in jest, we add “for WordPress” to that. We do that as we’re working on making our SEO plugin available for other platforms.

Google Search Console integration

This release brings a feature that used to be specific to Yoast SEO Premium to Yoast SEO free. Google released a new version of the API for their Webmaster Tools. It also recently renamed it to “Search Console”. This new API meant we had to rebuild things anyway and as we did that we decided to make this feature available to everyone.

The option to create redirects straight from this interface will remain premium. But if you can create redirects in another way, this is a great, free, way to make sure your site stays optimized.

See what it looks like:

Yoast SEO Google search console integration screenshot

Pointing you at posts that need work

This was actually a user submitted feature request. Brandon Hubbard suggested a widget in this GitHub issue, which we thought was a great idea. So now, when you login, you’ll see a widget like this:

Yoast SEO dashboard widget

Breadcrumbs in the customizer

If you use and like our breadcrumbs, you might like this even more. If your theme declares support for yoast-seo-breadcrumbs, we’ll automatically enable them and even add a panel to the Customizer so you can customize them:

breadcrumbs-customizer

Instructions on how to make this work with your theme(s) can be found here.

There are literally tons more small bugfixes in this release, so we’re certain we can say this is the best Yoast SEO ever. So, go update and tell us what you think!

Summer Sale on Yoast SEO Premium

And to top it all off, we now also have a sale on our Yoast SEO Premium plugin! It is now exactly the same pricing as our other SEO plugins, so it starts off from $69!

This post first appeared as Yoast SEO 2.3 on Yoast. Whoopity Doo!

My WordPress Advice and Tips for Business Owners at Mr Marketology

I spent some time with Jeff from The Marketology Group for his podcast Mr Marketology discussing the WordPress world and best practices.

Don’t mind the small “P” in WordPress, other than that it was a great chat and it reminded me again how many basic bits from the WordPress ecosystem aren’t obvious to people outside of our community. I’ve been spending a lot of time with marketers over the past couple of years and that taught me a lot, which is why I was more than happy to share my overview on the WordPress market and the large ecosystem of business owners running WordPress website.

Jeff and I discussed plenty of interesting thing:

  • WordPress updates
  • Security for WordPress websites
  • SEO
  • WordPress for marketing
  • the power of the 24%
  • Can people run cheap WordPress solutions
  • Reputation and quality for WordPress services

And so on.

If you are a business owner running a WordPress website and not involved with the community (or working with a technical department), check out Mr Marketology’s podcast:

The post My WordPress Advice and Tips for Business Owners at Mr Marketology appeared first on Mario Peshev on WordPress Development.

New Feature Plugin Proposed: oEmbed for WordPress Posts

WordPress has a whitelist of 31 trusted sites from which users can oEmbed content, but one source is noticeably missing – WordPress itself. During this week’s feature plugin chat, Pascal Birchler and a group of contributors proposed the idea of oEmbed for WordPress Posts:

Basically, we want to make WordPress an oEmbed provider. Users should be able to paste an URL from a WordPress blog and the post gets embedded right away. Difficulties here are discovering other WordPress sites as oEmbed providers and whitelisting them. The oEmbed endpoint requires the WP-API to be in use, so this can’t land in core until the API does.

The oEmbed API proof-of-concept feature plugin is currently in development on GitHub. It requires WordPress 4.3 beta 3 or later and version 2 of the WP REST API plugin.

Mel Choyce, author of the trac ticket requesting the feature, created a mockup of how embedded WordPress posts might look:

wordpress-oembed-feature-plugin-mockup

The ticket is home to an active discussion with excellent reasons on both sides of the argument for why this should or should not be included in core, highlighting the many considerations that would be involved with having oEmbed discovery turned on. Tackling abuse of the feature could also pose a significant challenge.

The feature plugin is still in the early development stages and discussion regarding its implementation is ongoing. Birchler said the team needs help with design and development, particularly with the oEmbed auto-discovery part of the project. If you’d like to get involved with the discussion, you can join in the weekly chats in the #feature-oembed WordPress Slack channel.

WordPress 4.3 Beta 3 Adds Site Icon Feature to the Customizer

WordPress 4.3 beta 3 was released this week right on schedule, and beta 4 is expected to arrive next Wednesday. This release includes more than 140 fixes and improvements since last week’s beta.

One of the most important changes you’ll notice is that the Site Icon feature is now available in the customizer in addition to its spot under General > Settings. The new panel is called Site Identity and it includes the site title, tagline, and the icon upload controls.

site-identity-new-customizer-panel

“The feature is now complete and requires lots of testing,” WordPress 4.3 release lead Konstantin Obenland said in the announcement. “Please help us ensure the site icon feature works well in both Settings and the Customizer.”

Mark Jaquith’s work to improve passwords has also been added to the installation process so that administrators will be prompted to select a strong password when setting up a new site. This screenshot from Ryan Boren’s most recent “Today in the Nightly” update shows the password strength meter’s feedback added to the UI.

photo credit: Ryan Boren
photo credit: Ryan Boren

Boren also highlighted the value of the new Markdown-esque patterns recognized in the post editor and their convenience for mobile users. Instead of trying to format HTML on a tiny screen, users will be able to take advantage of the new shortcuts which require fewer keystrokes.

“Create bulleted lists, ordered lists, and blockquotes using markdown like patterns,” he said. “I find this particularly handy on phones when the editor toolbar is offscreen.”

photo credit: Ryan Boren
photo credit: Ryan Boren

Beta 3 also improves the accessibility of comments and media list tables with a better design for comment bubbles and focus styling for row toggles. Obenland welcomes feedback on the accessibility improvements from those who are using WordPress with screen readers.

With 140 changes in beta 3, a new round of testing is in order. You can help by installing the WordPress Beta Tester plugin on a development site and reporting any bugs you find in the recent improvements. The official WordPress 4.3 release is now just four weeks away.

How to Verify Your WordPress Site on Pinterest

Do you want Pinterest analytics for your WordPress site? Pinterest analytics help you monitor your site’s performance by showing stats for all images pinned from your site. Recently one of our users asked us for an easy way to verify their WordPress site on Pinterest. In this article, we will show you how to verify your WordPress site on Pinterest and get Pinterest analytics.

Verifying your site allows you to get more insights in Pinterest Analytics

Video Tutorial

If you don’t like the video or need more instructions, then continue reading.

Generating Pinterest Verification Code for Your Site

First thing you need to do is login to your Pinterest account and click on your user name. This will bring you to your pins page. Next, click on the gear icon on the top right corner of the screen and then on account settings.

Visiting Pinterest account settings

You need to scroll down on the account settings page to find the website field. Enter your site’s URL and then click on the confirm website button.

Adding your website to Pinterest

A popup will appear on the screen with a single line of code. This code is a meta tag that you need to add on your website. Simply copy it and leave this window open. You will need to come back here to complete the verification.

Pinterest verification code for your WordPress site

Adding Pinterest Verification Code in WordPress

There are two ways you can add the meta tag to your WordPress site. You can directly paste this code in your child theme‘s header.php file just before the </head> tag.

An easier way to add the code on your website is by using the Insert Haders and Footers plugin. Simply install and activate the plugin and visit Settings » Insert Headers & Footers page. Next, paste the Pinterest verification code in the headers section and save your changes.

Insert Pinterest verification code in the header

You now need to switch to the Pinterest verification code popup and click on the finish button. You will see a success message.

You can now see verified Pinterest Analytics for your site, and how it is doing on the Pinterest network. You may also want to add the Pinterest Pin it button to your site to increase exposure.

While we don’t use Pinterest on WPBeginner, we receive a lot of Pinterest traffic on our sister site List25. You can check out List25’s Pinterest page as well.

We hope this article helped you verify your WordPress site on Pinterest. You may also want to see our guide on how to add Pinterest Pin it button over images 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.

To leave a comment please visit How to Verify Your WordPress Site on Pinterest on WPBeginner.

How to Easily Create Short Amazon Affiliate Links in WordPress

Affiliate marketing is a steady source of income for many blogs. Amazon’s affiliate program is one of the largest and most popular program in the market. Due to the large number of products available, there is always something you can recommend and earn a commission. Did you know that Amazon also offers a short URL service? In this article, we will show you how to easily create short amazon affiliate links in WordPress.

Amazon affiliates

Why Use Short Affiliate Links for Amazon?

By default an Amazon affiliate link is a long URL containing strings and IDs.

http://www.amazon.com/gp/product/0470560541/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0470560541&linkCode=as2&tag=wpb09-20

This link is lengthy, and it is hard to look at. It also increases your chances of accidentally making a typo and breaking the URL.

One possible solution is to cloak affiliate links in WordPress by using a plugin like ThirstyAffiliates. Using an affiliate link manager allows you to redirect users while using your own custom short URLs like this:

http://www.wpbeginner.com/refer/prowp

The problem with using a cloacked URL is that users do not know where they will be taken when they click on that link. You may want to show users that they will be redirected to Amazon’s website, because Amazon is a trusted brand name.

This could potentially increase your earnings, particularly if you most recommend products from Amazon.

Amazon comes with its own short URL option that allows affiliates to easily transform any Amazon link into a short URL using amzn.com domain name.

Video Tutorial

If you don’t like the video or need more instructions, then continue reading.

Creating Short Amazon Affiliate Links

There are two type of short URLs that you can create for your Amazon affiliate links. The first one uses Amazon.com domain name.

You need to simply add /dp/yourproductid/?tag=youraffiliatetag.

Take a look at this example:

http://amazon.com/dp/0470560541/?tag=wpb09-20

You can create an even shorter URL by using amzn.com domain name. Simply remove the /dp/ prefix and add your product id with your affiliate tag.

http://amzn.com/0470560541/?tag=wpb09-20

That’s all, we hope this article helped you easily create short amazon affiliate links in WordPress. You may also want to see our list of the 10 best affiliate marketing tools and plugins for 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.

To leave a comment please visit How to Easily Create Short Amazon Affiliate Links in WordPress on WPBeginner.

How to Add Facebook Author Tag in WordPress

Have you noticed that Facebook is now displaying author information on links shared on Facebook? Recently one of our users saw our Facebook status and asked us how they can add the Facebook author tag on their site. Considering the massive user base of Facebook, this is crucial to any site’s social media strategy. In this article, we will show you how add the Facebook author meta tag in WordPress.

Facebook Author Tag Demo

How Does Facebook Author Tag Work?

Once you add the Facebook author tag on your site, it will display your name with a link back to your profile any time your article is shared.

This is great for both single author blogs and multi-author blogs because it bring more exposure to your personal brand.

There are several ways to add the Facebook Author tag on your site. We will show you both the plugin method as well as the code method to add Facebook Author meta tag on your WordPress site.

Video Tutorial

If you don’t like the video or need more instructions, then continue reading.

Add Facebook Author Tag Using Yost WordPress SEO Plugin

If you are using Yoast WordPress SEO plugin, then you are in luck because it has Facebook open graph meta data support.

You just need to visit SEO » Social page in your WordPress admin and make sure that the box next to ‘Add Open Graph meta data’ option is checked.

Enable Facebook open graph meta data in WordPress

The next step is to add your Facebook ID in your WordPress account. Simply visit Users » Your Profile page and enter your Facebook profile URL and click on the save changes button to store your settings.

Add Facebook profile URL in WordPress

That’s all, WordPress SEO will now automatically insert Facebook author tag or published by tag when you publish an article. WordPress SEO also allows you to easily add a page title and description for Facebook, and you can even explicitly set Facebook thumbnail for your posts.

Add Facebook Author Tag in WordPress using Code

Since we already use Yoast SEO plugin on our site, it made sense for us to use the above method. However if you want to add Facebook author meta tag on your site without a plugin, then simply add the following code in your site’s <head> section.

<meta property="article:publisher" content="http://facebook.com/yourpagelink" />

<meta property="article:author" content="http://facebook.com/yourprofilelink" />

Make sure to replace the links above with your site’s Facebook page link and your personal profile link.

If you don’t want to edit your theme files, then you can use our Insert Headers and Footers plugin to add this code in your site.

We hope this article helped you add Facebook author tag in your WordPress site. You may also want to see our beginner’s guide on how to add Twitter cards in WordPress.

Having an issue with the incorrect image showing in Facebook? Here’s how to fix Facebook incorrect thumbnail issue 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.

To leave a comment please visit How to Add Facebook Author Tag in WordPress on WPBeginner.

Explore the WordPress REST API with the New Interactive Console Plugin

wp-rest-api

WordPress REST API project lead Ryan McCue, in cooperation with Automattic’s Engineering team, released a REST API Console plugin on WordPress.org today. It’s a basic console that fits right into the WordPress admin and allows you to explore the API, make small changes, and find out what your site is exposing.

“This is a forked version of the WP.com console that myself and members of the Apollo team at Automattic worked on,” McCue told the Tavern. The console was converted in approximately four casual days, and McCue credits Beau Collins for this, as he originally wrote the majority of the console for developers working on WordPress.com.

“It’s pretty useful for exploring the API as a learning tool, but also for developers who are extending the API to get a sense of how their stuff fits in,” he said.

The REST API Console plugin requires the WP REST API plugin version 2.0 or later. You can find this on the GitHub project page and version 2 should be up on WordPress.org within the next day or two. Once you have both plugins installed, the console is visible in the admin under Tools > Rest API Console.

wp-rest-api-console-demo

You can actually make changes to your site using the console, so it’s advisable to install it on a local site and play with it there. While the GET requests can’t change anything, the other types can edit or delete posts (which would end up in your trash).

The plugin can only connect to the local site you’re currently on and cannot access remote WordPress sites. McCue recommends using something like Postman or Paw if you want to play around with remote sites.

In the future, he hopes to add more features and improve the plugin’s parameter documentation.

“The older WordPress.com console had the ability to click through to links, so I’d like to re-add that at some point,” he said. “The parameter documentation and tooling hasn’t been fleshed out yet, but the plan is to do it eventually – we’re working on exposing more from the API itself, too.”

If you want to tinker with the API but don’t have a local testing site handy, check out the live demo at demo.wp-api.org where you can click around to explore. This will save you the trouble of installing the plugin, if you just want to try it out. Also, you can’t perform any destructive changes there. Version 2 of the WP REST API plugin should be available on WordPress.org within 24-48 hours.

Google Analytics 5.4.3: Remarketing tag

We just released Google Analytics by Yoast 5.4.3. This is not a big release, but we do want to highlight one of the changes you’ll see in there.

Remarketing tag

Our Google Analytics plugin has had the remarketing tag incorporated for quite some time, but it was kind of hidden, so not many people were able to actually find this feature. So now we’ve made it a lot clearer in the settings of our plugin:

All you have to do to add the remarketing tag is check the box that is highlighted.

Targeting your website’s audience

For those of you who don’t know or are unsure of what the remarketing does, let me briefly explain. Remarketing allows you to target your website’s visitors on other sites than your own. So if a person has visited your site, and you have the remarketing tag incorporated in your site, you’re able to serve him or her your AdSense ads, even when they’re not on your site.

Cookie laws

Note that there are privacy and cookie laws active worldwide. These differ from one area to the next, so be sure you’re in compliance with the cookie laws applicable to your target audience.

This post first appeared as Google Analytics 5.4.3: Remarketing tag on Yoast. Whoopity Doo!

Theme Translations and Language Packs are Coming to WordPress.org

photo credit: . Entrer dans le rêve - cc
photo credit: . Entrer dans le rêvecc

WordPress.org will soon support translations and language packs for themes hosted in the official directory. In Matt Mullenweg’s Q&A at WordCamp Europe 2015, he emphasized the importance of having better language support for themes and plugins and identified this as a high priority for continued improvements to WordPress.org.

Today the WordPress meta team announced that theme translations will soon be available on WordPress.org at translate.wordpress.org. Within the next few days or weeks, all active themes (those updated within the last two years) will have their strings imported.

“This will involve importing ~1500 themes, which, combined, have about 315,000 total strings,” Sam Sidler said in the announcement. “After duplicates, the number drops to only 80,000 unique strings.”

Language Packs Will Reduce Download Sizes for Themes

Sidler outlined several advantages for theme authors who opt to manage translations on WordPress.org, including the community’s large network of contributing translators who currently maintain 140 locales on translate.wordpress.org.

The most exciting change is that themes hosted on WordPress.org will soon be able to take advantage of language packs. Theme authors will have the option to remove translations from their zip file in favor of allowing WordPress.org to deliver the language packs, resulting in smaller download sizes.

“Eventually, we also plan to give priority to localized themes in localized directories; e.g., someone searching the Romanian theme directory will see Romanian themes prioritized over English-only themes,” Sidler said.

The more languages a theme can be translated into, the greater its prominence in WordPress’ language-specific theme directories. This should provide WordPress.org theme authors with a strong motivation to work with the polyglots team to get more translations. Theme authors can also request new translation editors to be added to polyglots, if they want to continue working with their own translators.

Those who prefer to ship their own translations can continue to do so. Keeping the translation files in your zip package will essentially opt you out of language packs for those specific translations. If you need help adding support for translations and language packs, Sidler recommends Otto’s Language Packs 101 tutorial in addition to the Theme Developer Handbook section on Internationalization.

Candid Conversation with Tom McFarlin About the WordPress Community

Earlier this month, Tom McFarlin published a great post where he shares his perspective on the WordPress community. His post struck a nerve and instead of discussing it through comments, I invited him to a Google Hangout to have a candid conversation. Within the conversation, McFarlin and I discuss a number of topics, including:

  • Community behaviour and discourse
  • It’s not a WordPress problem
  • Comment moderation strategies
  • Subtweeting
  • How, as men, do we show that a significant portion of us are color/ethnicity/whatever blind?
  • Women in tech

McFarlin is the father of two daughters which adds an interesting dynamic to the women in tech issue. I enjoyed the time I spent with him discussing topics we both feel are important. If you have any feedback concerning the content in this recording, please leave a comment.

7 Reasons Why I Avoid Estimates

Every time I need to do estimates, I cringe a little. I no longer do estimates for small and medium clients since it creates false expectations and takes a huge amount of time.

Useless estimates

Useless estimates

Which is why I talk about pricing and budgets a lot:

I got involved with business development and estimations in 2007 as a Java developer, estimating custom development for several clients. Every now and then I need to break a project into small components, and then smaller tasks that I could put a number next to and send a rough offer.

I sent another proposal for a larger project today and I wasted many hours fine tuning the numbers. I added a long paragraph in my email with the attachment explaining why those estimates are inaccurate and basically vague, unrealistic and subject to change.

Since I’m a great supporter of the agile model for various reasons, here are my 7 main reasons why estimates and fixed price projects should be avoided whenever possible.

1. Your Estimate is Never Accurate

I shared the CHAOS report study in my latest WP Elevation post on 7 Common Pitfalls Leading to Scope Creep. The numbers are alerting: 15% of all web projects fail and yet 59% generate some form of loss – delays, extra features, unexpected changes and non-planned ones. Not to mention that a good number of the quotes are actually rejected if they predict the risk upfront, due to other offers that fall in one of the first two categories.

Estimates FTW.

Estimates FTW.

Based on the past 10 years of experience in the software development industry, I’ve seen two types of fixed-price projects:

  1. Projects that generate loss and are generally not profitable for the contractor/agency
  2. Projects with hyped numbers that cost several times the time spent on development, management, communication and testing

WordPress development (alongside with other types of web development) is usually a creative process that requires a unique approach to each project.

If you are a construction worker responsible for carrying bricks and other construction materials, it may be possible to estimate the amount of time it takes you to move 5000 pounds of bricks. It’s a repetitive activity that requires you to grab several bricks from point A, bring them to point B, get back and repeat.

Even so, there are various factors such as back pain, low blood pressure, high temperature outside that makes the transportation environment more troublesome (or rain) and so forth. But in general, it’s somewhat predictable.

Web development isn’t. There are thousands of things that could go wrong due to various unexpected exceptions. Unless you add a significant buffer for rainy days, you will certainly spend more hours than expected and generally delay the project.

2. Estimates Require Forever to Calculate

In order to build a detailed estimate, you need to break the entire project into generic components. Each of those components should be turned into smaller blocks, and then separable tasks for every small activity.

You have to build use case diagrams and flow charts for all of the possible activities. Larger projects require projection of visits and traffic, which determines the hosting environment. There is the communication time, and management and testing iterations. There are meetings and calls for syncing the process and solving problems on the fly.

UI-related projects often require iterations. And every now and then issues with various browsers or mobile devices occur.

Building larger systems requires custom development and bundling blocks together. Incompatibility issues are possible.

Multilingual projects need a 100% translatable application, and you’ll always miss several strings – so you’ll have to get back, fix the i18n compatibility, generate the updated .mo files and so forth. Oh wait, if you change a core plugin or theme, this would be overridden by the next update, so you probably need a child theme or extend the plugin and replace the views. Or otherwise add the extra time for maintainability post-update.

These are just a few generic examples. Last week we spent almost a day tracking a UI bug breaking the header of a site. Turned out to be an encoding issue, a file was changed using UTF-8 with BOM and broke the entire output of WordPress. The fix is “invisible”:

bom-file

That’s something that none of us could predict, and it was hard to identify. But it happens regularly, with most projects.

3. Estimates Don’t Define Quality

Estimates are a measure of “how long would it take to build X?”. Building a project or a components doesn’t say anything about quality.

And customers often compare apples with cucumbers.

Let’s take a job board component as an example. You estimate the amount of time to build one. There are different “what if”‘s here:

  • Would it implement all of the security best practices?
  • Can it scale to 100,000 job applications?
  • Are there tags for skills that could be extended and grouped later, or simply a text field that means nothing in the database?

Not to mention that the plugin could be fully extensible, with tons of actions that allow for other add-ons to enhance its behavior. Or plain and simple.

There could be pagination and sorting by columns, extensible and flexible views for different jobs, API for pulling jobs remotely with JSON requests etc etc. Even if you describe these separately in the proposal, again – there are various ways to implement each one of them.

Quality is not a factor when putting estimates. It simply defines what is your forecast regarding the amount of time it would take your team to build a given project.

4. Estimates Are Expensive

When estimating a project, there are two ways to tackle it:

  1. Roughly put some numbers next to the main features
  2. Spend forever asking all the questions in the world and preparing a 30-page document with every single small details

Therefore, the common sense dictates the following:

  1. You probably have absolutely no idea what are the project details and there are a hundred gotchas waiting to bite you very, very soon
  2. You will spend a week brainstorming on something that may as well not happen at all

Since the first option is not estimating, but guesstimating, what are the options for building the most awesome proposal ever?

  1. Prep it for free, waste a week of your life and lose the project to a lower number
  2. Ask for getting paid for 40-hours of your time doing a discovery session and estimating

Things get even more complicated if you’re working with a team on a larger projects. This would require a team estimating each of the modules separately, discussing dependencies and various use cases, brainstorming together, blocking time for meetings and calls, and delaying other projects instead.

5. Separate Modules Affect Other Numbers

The main reasons I get requests for estimating a project is in order to provide a fixed fee for the final cost. While that makes sense – more or less – it’s arbitrary and an expensive process, as we already mentioned above.

The second reason however is for pricing each component separately. In other words, if a certain number is higher than the ROI for a client, they would like to drop it and focus on something else.

That's what an average project looks like behind the scenes

That’s what an average project looks like behind the scenes

Here’s the thing: most modules are not standalone. They depend on other modules, or impact the overall look and feel and functionality for a project.

For example, getting back to the job board for a second. Let’s say that we have a request for submitting CVs by employees and the client decides to drop that.

This would most likely affect several different areas:

  1. The look and feel – various views for displaying the CV, upload buttons, review by employees
  2. Uploading and editing feature for contractors
  3. Review options and PDF viewer for employees
  4. Capabilities that restrict the access to that resource

And so on.

If a client wants to substitute a component for another one, it gets even messier – I won’t even go there.

The larger the project, the more dependencies there are. The more connections and messages between different components, and the harder it is to bundle everything together and make it work smoothly.

And here’s another hidden “treasure” – when clients want to build an MVP first and they receive 80% of the functionality for a reasonable fee, the challenges come when they ask for the other 20%. Since the basic 80% often come from the WordPress core or general plugins with little to no customization, the other 20% require custom development for a live platform – which requires research and a lot of careful development and testing in order to avoid conflicts and edge cases with the existing components.

Those second 20% are often far more expensive than the initial 80% – because it’s a different type of service. The number of features doesn’t determine the amount of time and the level of skill required.

6. Estimates Prevent Innovation and Adaptivity

As we stated above, the main reason for estimates is predictability and choosing the best fit for executing a project.

But clients are often inclined to go for a cheaper solution – since it’s our psychology. In the head of a client, a request for proposal (RFP) or simply asking for a project means that each contractor will deliver the very same product.

Wrong.

Different contractors have different set of skills, expertise, and workflows. They operate differently and deliver different results.

Some of those are visible, others – aren’t.

And unlike the fruits in a supermarket where you can easily compare cheap tomatoes and expensive ones (they even smell differently), the only way to compare two potential custom products is to pay for both of them and use them with the same data, in the same environment – which is a nonsense.

Therefore, a lot of agencies – sometimes inexperienced, and sometimes on purpose – try to solve problems in the fastest possible way.

Bundling random plugins together that “seem to work”, but break the layout on mobile, call dozens of additional database queries and hurt the code quality of the project.

Or customizing a random ThemeForest theme so that the site looks beautiful while loading 10 different sliders with 50 scripts at the same time.

On top of that those are hardly customizable – these are general purpose solutions that solve a problem and have options, but they’re not meant to be extended infinitely – there is a certain framework in place that allows for minor changes, but that’s it. Everything extra needs to be rebuilt from scratch, and sometimes the entire project needs to be deprecated and done from ground zero.

7. Fixed Numbers Encourage Sloppy Work

At the end of the day, clients want solutions and contractors want profit.

Real data is a myth.

Real data is a myth.

On fixed fee projects profit comes from spending as few hours as possible on a project, in order to prevent scope creep plus extra time and generate a good margin.

This approach discourages creativity and clean work.

It’s only logical – why double the amount of time in order to refactor the code, optimize the queries, reduce the script loads, combine and minify the scripts and styles and so forth if it’s not needed, nor budgeted, even if it’s all essential for the success of a project? And if you add that to the proposal, the final number will probably be higher than your competitors’ and you will lose the project altogether.


 

Estimating projects is something that should be avoided. The reason agile exists at all with variations such as Scrum, XP and Kanban, is that waterfall is an inefficient way of building software.

Projects estimated upfront suppress innovation. The team in charge isn’t motivated to invest in outstanding code quality. Different bidders try to underprice by cutting features, just as cheaper cars save on car parts that break more often.

What we do in order to prevent these is working against a budget.

When you are looking for a car or an apartment, you call your car broker or a real estate agent and tell them what you want. On top of them you give them a rough budget.

You won’t go to a Porsche or BMW dealer and tell them: “Show me all of your 200 models regardless of the fact that I have a limited budget that only 5 of your cars fit“. You need to respect both your time and the time for your technical partner.

The post 7 Reasons Why I Avoid Estimates appeared first on Mario Peshev on WordPress Development.

New Proposal on Trac to Remove Post Formats from WordPress Core

Post Formats is a feature introduced in WordPress 3.1 that enables themes to visually differentiate between types of content. A metabox with radio buttons was added in WordPress 3.6 to expose the feature to users and allow them to easily select a format. Since WordPress 3.6 was released, there has been little effort to improve the feature.

Morten Rand-Hendriksen teaches WordPress to thousands of people through Lynda.com. After spending time writing training materials for post formats, Hendriksen was reminded of how much post formats shouldn’t be in WordPress core.

He’s created a new ticket on trac suggesting post formats be removed from WordPress and placed into a plugin similar to how the link manager and blogroll were removed in WordPress 3.5.

After the termination of Post Formats UI, it appears the feature has largely been left to pasture and implementation across themes is at best spotty and inconsistent. One example of this is how different Post Formats are treated in the default themes, culminating in the minimalist/absent inclusion in Twenty Fifteen.

Hendriksen lists six key arguments that come up when discussing the removal of post formats from WordPress:

  • Feature support is inconsistent across themes causing users to wonder why the panel and options appear and disappear when themes are switched.
  • When implemented, behavior is inconsistent between themes causing a perception of arbitrary or broken behavior in the eyes of the user.
  • Specification for what exactly each post format does is vague and ambiguous giving theme developers too much room to come up with arbitrary and non-standard behaviors that cause user confusion when themes are switched.
  • The use case for Post Formats seems to have gone away or have been supplanted for the larger goal of making modular, Snowfall-like post editing available.
  • Post Formats behavior can be mimicked by theme developers through the use of Categories or other custom taxonomies.

Applying the 80/20 rule to software development, Hendriksen believes post formats is in the 20% range or lower. He ends the ticket by proposing post formats be moved into a feature plugin.

This would allow it to be improved concurrently with WordPress and open up opportunities to experiment with different implementations and ideas. Alternatively, it could be abandoned if no interest is shown to improve it.

Move Post Formats to a Plugin

My opinion of Post Formats hasn’t changed since the last time I wrote about them. They’re still unpredictable, I don’t see many sites using them, and they’re tough to explain to new users.

Considering post formats dramatically impact the presentation of content, it’s strange that the core team has not continually improved the feature after 3.6. By now, they should be rock solid. Instead, it’s a feature with no obvious future.

Although you can leave a comment on this post, the best place to leave feedback is in this trac ticket. It’s time WordPress core developers got involved with the conversation to let us know what they think about the future of post formats in WordPress.

WordPress 4.3 Improves User Search and Turns Comments Off on Pages by Default

WordPress 4.3 beta 1 was put into the hands of testers last week. Those who have been following 4.3 developments are already familiar with the major features headlining this release, ie. the new site icons, menu management in the customizer, and more secure passwords. However, there are also a couple lesser-known improvements that will have a positive impact on millions of WordPress users.

Improved User Search

Searching for users in the admin is about to get much easier, thanks to work on a ticket opened by John Blackbourn 16 months ago. He notes that “only the user_login (username) and user_nicename (sanitized username) fields are searched,” excluding the following more likely fields:

  • First name
  • Last name
  • Nickname
  • Display name

This issue was especially problematic in large, multi-thousand member multisite installations where finding a user in the admin often meant knowing exactly what to query and then paging through results. WordPress 4.3 contributions from Pippin Williamson and Scott Taylor make it possible to search by the user’s email, URL, and display name.

Comments Turned Off on Pages by Default

comments-off-on-pages-by-default

WordPress 4.3 will also bring a welcome change to turn off comments on pages by default. In the future when you create pages, you won’t have to remember to go into the discussion settings to disable comments. One might think this would be a simple little thing to change, but quite a bit of discussion has gone into crafting the best solution to the ticket opened five months ago.

This change also applies to all custom post types. Mel Choyce outlined the new behavior in a post on the make.wordpress.org/core blog:

Post registrations that don’t explicitly add support for comments will now default to comments being off on new posts of that type (before, they defaulted to on). Up until now, post type support for comments has only affected admin UI; a developer could omit comment support on registration but still allow comments to be posted. This is a change in behavior, and we will be closely monitoring its effects during beta. Moving to explicit support will allow core behavior to be more predictable and robust in the future, but we will always consider real-world usage.

The change also comes with a new function and a filter that you can use to restore the current behavior of comments to your post type, if necessary. More details and an example on how to use the filter are available on the make.wordpress.org/core announcement post.

PHP 4 Style Constructors Will Be Deprecated in WordPress 4.3

PHP 4 style constructors are being deprecated in WordPress 4.3 to ease the transition to support PHP 7. According to Aaron Jorbin, on the Make WordPress Core blog post, WordPress r32990 introduces a change so that all classes use the PHP 5 style constructors, while still retaining the PHP 4 style constructors for backwards compatibility.

A deprecated_constructor warning that follows the same rules as deprecated_function will also be displayed for WordPress classes that are not external libraries

Chris Christoff, who contributes to WordPress core, generated a list of plugins on the WordPress plugin directory that have widgets calling WP_Widget::WP_Widget() and/or parent::WP_Widget() and/or {object}->WP_Widget().

The list includes more than 4,000 plugins and contains the author, title, and slug. Plugin authors should check the list to see if your plugin is listed. Even if it’s not, you’re still encouraged to make sure you’re not using a PHP 4 style constructor in your code.

If you use any of the plugins listed, please create a support forum thread with a link to the Make WordPress Core blog post and politely ask them to update their plugin.

Highlights of Matt Mullenweg’s Q&A Session at WordCamp Europe 2015

Kari Leigh | Found Art Photography
Kari Leigh | Found Art Photography

The video of Matt Mullenweg’s Q&A session at WordCamp Europe is now published on WordPress.tv. For those who were unable to attend, this session provides a glimpse into what WordPress’ co-founder sees for the future of the software and the community.

One of the most exciting parts of the video is where Mullenweg talks about the potential of WordPress.org to serve other languages and eventually expand avenues of core contribution to non-English speaking audiences.

When asked what kind of contribution can be made to improve WordPress.org for Rosetta sites, themes, and plugins, Mullenweg replied:

Themes and plugins are undoubtedly the most important. To me, the next most important things are the Rosetta sites and having theme and plugin directories available on the Rosetta sites. There is actually a great example at ro.wordpress.org, which is the Romanian Rosetta site that shows both the potential and the problem:

Now there are themes and plugins menu items there, which none of the Rosetta sites have had prior to this. But when you click on it you see mostly English in the plugin descriptions, even things like screenshots and tutorials.

He described these updates to WordPress.org as just a “hint of what could be amazing” one day. Mullenweg noted that despite Europe having 23+ recognized languages, attendees at the WordCamp were all speaking English. However, not all areas of the world are populated by people with bilingual capabilities.

I think it would be amazing to open up WordPress to have a first priority experience of the thousands of plugins and themes that are available for people who do not speak a word of English. Right now WordPress is just not accessible to that group. Luckily, over half the people in Europe are bilingual… In places where that’s a possibility, WordPress can still do well even though we don’t have a native experience in someone’s mother tongue.

But English is only the third most popular language in the world and it’s not the fastest growing. There are huge audiences that I think would be an important part of the community. Someday I want it to be where, instead of things being translated from English to a different language, we’re getting core contributions translated from, say, Chinese or Hindi or Spanish, into English to be reviewed. We’re not looking to just how to translate plugins from English into other languages but vice versa. I think that will be when we’re successful.

In the same way that better language support opens up WordPress to a wider audience, Mullenweg believes that the customizer will open up the software for more non-technical users. During the Q&A he shared his thoughts on the future of the customizer:

As we currently are working, the customizer is the way forward…It essentially removes the fear and disconnect between wp-admin and the front end of a site. It’s a bridge that gives people the confidence to make changes while seeing those changes in real time. The real time feedback and safety net of seeing that, and being able to undo and redo things, is incredibly empowering, particularly for non-technical users who don’t know how to dive into CSS or the code. I personally believe that the work on the customizer is some of the most important going on in the WordPress project right now.

In addition to building the feature in a way that is responsive to mobile devices, Mullenweg noted that the customizer currently falls short on desktop:

The customizer is, for lack of a better word, a narrow interface, because it needs to show your site in addition to the admin. I think we need to do a better job of making sure that interface scales up as well as down, meaning that if you do have the space or would like to make it fullscreen, that it is responsive, so that it enlarges into an interface that probably looks and works much like the current wp-admin interface for being a fullscreen experience for editing and modifying menus, widgets, colors, fonts, header images, site title, all the things that are key to the presentation of your site.

It is curious that the customizer is being pushed through to WordPress 4.3 without the ability to scale up gracefully. If the situation were reversed, where the feature was unfriendly to mobile users, it seems less likely that it would have been deemed ready for core. This illustrates the WordPress project’s strong emphasis on being positioned to attract mobile users.

Mullenweg encouraged attendees to keep an eye on the customizer, because he believes it will do a much better job than Wix and Squarespace when it comes to providing a user-friendly way to customizer websites.

The entirety of the 66-minute long Q&A session is included in the video below. In addition to languages and the customizer, Mullenweg also answers questions about security, WordPress’ minimum PHP version, the possibility of multilingual features in core, and the importance of building for mobile.

The WordCamp Video You Need to Watch

Cory Miller is one of the nicest, strongest people I know and this talk of his about mental health is incredibly important. His utter honesty about his own demons and challenges is inspiring me to take some steps in my own life.

Watch this video today. You might cry (I did), but it’s worth it.

WordCamp Europe 2015 pictures

WordCamp Europe 2015 was an exceptionally well run conference[1].  The content of the talks was so good that I mostly kept my camera in my bag, but managed to capture a couple of pictures during the event.

Rian Rietveld speaking in front a slide with a punk wapuu and #A11Y in a anarchy/punk font A packed room of about 400 people Beau Lebens staring alertly Petya Raykovska pointing her finger at the camera like I was doing something wrong One of the best people in the WordPress community.

All photos are licensed CC BY-SA-NC 2.0. If you are the subject of a photo and want a difference license, just let me know.

1) Siobham McKeown, the lead organizer is accepting booking to organizer events. If you want a professional organizer, get in touch with her.

DX Plugin Base – Ongoing Updates

I built DX Plugin Base several years ago as a general plugin framework that we could use internally, and something that could serve as a code repository for most of our projects. I’m really happy that some folks got the plugin and built their own reusing most of our code, such as the Metwit Weather Widget.

Since we hired a few more folks helping with both client work and internal projects, over the last couple of weeks we have been brainstorming on what could be added to our existing code base in order to improve our plugins – new features, enhancements, and polishing our alpha code for open beta that we could launch over the next weeks.

So, instead of blogging more about the latest happenings in the WordPress industry, I took some time doing client work and also improving the docs of our plugin. Now we have our shiny readme that describes most of the available code samples in a simple way, one by one, making it even easier for new devs to start building plugins using the WordPress APIs and following the standards. We’re improving the readme as we speak, and will iterate and add more features from our backlog in order to make it better and easier for the onboarding process of developers who are still learning the WordPress development process.

DX Plugin Base Docs

DX Plugin Base Docs

After using the plugin for training purposes with over 200 of my students, we’re back to the dev stage – improving the plugin, adding some new features, and building even better and more stable framework for new WordPress plugins.

DX Plugin Base is what we call Underscores for WordPress Plugins. Take it, fork it, change a few bits, add a function or two and there we go – your plugin is ready for use!

If you’re interested in helping out, feel free to send a PR or add a GitHub issue for code snippets that we could add to our plugin.

 

The post DX Plugin Base – Ongoing Updates appeared first on Mario Peshev on WordPress Development.

WordPress 4.3 Beta 1 Now Available for Testing

testing

WordPress 4.3 is right around the corner with beta 1 released and ready for testing. According to the 4.3 project schedule, there will be no more commits for new enhancements or feature requests from this point on. Contributors are now focusing on bug fixes and documentation ahead of August 18th, the target release date.

With all the controversy surrounding WordPress 4.3’s inclusion of menus in the customizer, you may have missed a few other lesser known features that are on track to be included and need to be put through the paces. The new site icons feature was added to trunk this week, along with a text editor for the Press This posting interface.

WordPress lead developer Mark Jaquith has been working on making passwords more secure. As of 4.3, WordPress will no longer send passwords via email. The password strength meter is now more tightly integrated. It will warn users upon selection of a weak password and can also suggest a secure password.

One interesting new improvement added to the post editor is recognition of some basic markdown-esque patterns inside TinyMCE:

Certain text patterns are automatically transformed as you type, including * and – transforming into unordered lists, 1. and 1) for ordered lists, > for blockquotes and one to six number signs (#) for headings

For those who are used to formatting text this way, the post editor in WordPress 4.3. will be a more friendly place for speedy composition.

Admin post and page list tables will take a huge leap forward to become more responsive in this release, improving the experience of using WordPress on smaller screens. Previously, the columns that could not fit were truncated, but WordPress 4.3 will allow columns to be toggled into view.

Check out release lead Konstantin Obenland’s beta announcement post to download a zip of the beta. If you want to help test, the easiest way is to get hooked up via the WordPress Beta Tester plugin. Bug reports are welcome on the Alpha/Beta support forums and can also be filed on WordPress trac.

WordPress 4.3 Adds New Site Icons Feature and a Text Editor to Press This

WordPress 4.3 is on track to include a new site icons feature, which will allow administrators to easily upload an image to be used as the favicon and app icons for a site. Favicons have traditionally been handled by WordPress themes or plugins, but the new core support means that users no longer have to hunt down an extension to handle this basic site feature.

This addition landed in 4.3 in response to a four-year old trac ticket requesting an easier way for non-technical users to upload and crop an image to use as a favicon. Konstantin Obenland, release lead for 4.3, committed the feature to WordPress trunk this week, along with the following summary of its current capabilities:

This v1 marries Jetpack’s Site Icon module with the Media Modal, reusing code from the Custom Header admin. For now, the core-provided icons will be limited to a favicon, an iOS app icon, and a Windows tile icon, leaving .ico support and additional icons to plugins to add.

After testing WordPress 4.3-alpha, I found that the experience of adding a favicon in the settings panel is smoother and more intuitive than any plugin I’ve ever tried. The screen offers users a nice preview of the image as a favicon and mobile icon. It also doesn’t burden you with any notices about sizes and image quality, unless you attempt to upload an image that is less than 512px in width.

wordpress-site-icon

If you want to test the feature, you can provide feedback on the ticket or via the announcement post.

Another major enhancement added to 4.3 this week is a text editor for Press This. Many WordPress users appreciate the streamlined simplicity of the Press This post editor but were held back from using it to compose posts due to the lack of HTML editing support. The addition of a text editor offers the same capabilities as the standard editor in post-new.php.

press-this-text-editor

Press This will also receive a few polishes in addition to the text editor, including auto-scrolling when the caret moves out of the viewport while the user is typing (similar to editor-expand) and auto-resizing for the textarea. WordPress 4.3’s improvements to Press This are not exactly a replacement for the dearly-departed distraction-free writing mode, but the post editor at wp-admin/press-this.php is quickly becoming one of the more zen-like interfaces in the admin.

Filter to Disable the Customizer Shot Down on WordPress Trac

photo credit: shutoff - (license)
photo credit: shutoff(license)

WordPress 4.3 will introduce menu management via the customizer, providing live previews on the frontend for adding, deleting, and ordering menu items. Although users still have the option to manage menus using the admin interface, developers who are not keen on the feature are searching for an easy way to disable the customizer and remove its links throughout WordPress.

In certain scenarios involving client work, the customizer can be more trouble than it’s worth and may not be a beneficial addition to a custom-tailored WordPress admin.

Gabe Shackle, an application developer and UI engineer at Risdall, created a ticket on WordPress trac last week, requesting a filter to disable the customizer. His patch offers developers an easy way to enable the ‘no-customizer-support’ class within the body tag.

Due to the fact that the ‘customizer-support’ class is added via JavaScript on page render, it cannot be manipulated using any core filters or actions currently.

By setting the filter value to false, the Customizer is essentially hidden from the admin and the links that were currently pointing at the Customizer (widgets, themes, etc…) are reverted to their previous dashboard destinations.

Currently, developers who want to disable the customizer have to employ a combination of different methods in order to effectively remove everything that the customizer introduces into the admin.

“This filter makes this process into a simple boolean filter so that developers who do not want or need the Customizer can easily remove it,” Shackle said.

WordPress lead developer Dion Hulse replied to the ticket to say that although he doesn’t use the customizer much himself, he doesn’t think that WordPress users would benefit from an easy way to turn it off.

Personally as much as I don’t use the customizer a lot of the time, I think offering a filter to disable it is probably not in the best interests of WordPress users.

The customizer, as much as some dislike it, is a major component of the future of WordPress UX – whether that is a good or bad thing remains to be seen by some – but like it or hate it, it’s here.

Hulse suggested, as an alternative, that a better way to disable it would be to remove the customize capability from the roles.

Shackle further explained that he was attempting to follow the precedent of the admin bar, which he considers to be a similar type of UX component.

“The Admin Bar can be disabled not only by a filter but by a global variable, core function, and user profile setting,” he said. “The Customizer has none of these options.”

Nick Halsey, the developer of the Menu Customizer plugin that is being merged into 4.3, replied based on assumptions about why Shackle might request a filter to disable the feature:

I have yet to see a valid reason for something like this. In most cases, concerns about not wanting users to have access to the Customizer stem from the fact that you’re not giving them the appropriate capabilities. And the customize capability can be used to turn off the Customizer if you really must.

While you can remove the customize meta capability (or re-map it or whatever), doing so simply because you don’t want to train users or don’t want to use the Customizer is doing yourself and your users an enormous disservice. As dd32 mentioned, the Customizer will only continue to grow in importance within WordPress. Additionally, user testing has shown that the Customizer experience is generally easier for users to grasp than the admin, which largely stems from the value of having live-previewing available. We’re putting a significant amount of time into the Customizer every release to continue improving it, conducting frequent user tests along the way to optimize usability.

Halsey promptly closed the ticket following this exchange. I followed up with Shackle to find out why the proposed alternative to remove the customize capability is inadequate for his purposes.

“Mostly I was hoping that the Customizer could be treated more like the admin bar, which has 3+ methods for disabling it,” Shackle said. “Having a clearly labeled filter is, in my opinion, more legible than modifying user capabilities. A PHP developer with virtually no WordPress knowledge could most likely understand much quicker what’s happening with a filter named ‘enable_customizer_support’ rather than ‘map_meta_cap’.”

Obviously, not all tickets and patches will be considered valid by the maintainers of WordPress core components, but Shackle was disappointed by the defensive response to the discussion.

“Honestly, had the reply simply been something along the lines of ‘You should just use the customize capability to achieve the same effect’ I really wouldn’t have had any issue,” he said.

“Unfortunately, it seems any approach other than ‘Customizer for all things!’ means I get to be told multiple times how much of a disservice I’m doing my clients and what a lazy developer I am for not just re-training my clients how to manage their sites’ appearance.

“It feels like the Customizer team themselves have an all-or-nothing approach to the project and that anyone who questions this is wrong, regardless of their reasoning,” Shackle said.

This exchange demonstrates that since core contributors view the customizer as a major part of the future of WordPress, this is one feature where there will be little willingness to support efforts to make it more modular. Disabling support for the customizer will continue to require use of ‘map_meta_cap,’ the same method the creators of the Customizer Remove All Parts plugin have employed.