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.


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 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.

WordPress Contributing Effort and Focus

End of 2014 was a turning point in my life, and I have been thinking a lot about my contributing efforts for a while now.

About a year ago I was teaching at a university, a school, co-organizing WordCamp Europe 2014 and a meetup, spoke at various conferences and meetings for free as well, contributed patches to plugins (plus free plugins and updating themes), mentoring people, teaching interns, and doing a dozen extra things for free.

Things Changed at Work

Working crazy hours.

Working crazy hours.

Our work back then was pretty well organized – we had a large client with an ongoing retainer for SaaS development, and some smaller ongoing projects. The majority of our team was busy with client work, the income was higher then our expenses, and we had another 20% or so time to work on internal projects, open source plugins and handle the load without stress. I had the process sorted out, and my billable work was about 20h/week, which allowed for another 40h/week on other activities. And it worked out well.

However, things have changed since then. We learned a lot of things and had to change the entire process, reorganize the team and our business strategy. We were 6 full-timers then with 4-5 more part-time folks, and about 12 fulltimers now with 5-6 part-time or freelance people in our team.

But due to the complete restructuring of the company, now I have to dedicate at least 50 hours a week on client or team work. I stay in touch with several different “departments” in-house – such as marketing and sales, conduct a lot of brainstorming meetings with Stanko and our business assistant, and with close to 20 people there’s a lot going on at any time. We have some new people who are being trained right now, and interns starting on Wednesday, and a good amount of my time goes into management, training, code reviews, and business development.

And I would still love to contribute, help and give back.

Contributing After Hours

But in a moment of a drastic change people have to optimize their resources: be it money, time, hardware, whatever. And given my incredibly limited time that was spent on free work, I had to do a lot of brainstorming and figure out a way to juggle all of it. Because doing the same work on top of my AT LEAST 50 hours a week would result in 90-hour work weeks which doesn’t make any sense in the long run.

And by a “long run” I mean months without a single day off. Because that happens a lot. It doesn’t for others, and for some it’s normal to chit-chat for hours without appreciating others’ time, but I tend to be highly efficient and the large volume of regular offtopic is against my principles.

Past WordCamp Europe 2015

Contributor Day - Main Room

Contributor Day – Main Room

WordCamp Europe 2015 was my second WordCamp EU as a co-organizer after being lucky enough to have Sofia as a host for WCEU 2014. I was in charge of the Contributor Day this year and I’m really glad that I was able to help with it – with about 900 people attending, it was, as usual, the best place to brainstorm with other WordPress folks on different subjects, and solve problems faster when being in the same room.

But I had a really hard time managing my energy and sanity levels – and not only due to the usual madness the days before (and during) a conference, but also due to everything else going on. I had to work at least an hour every morning and 2 hours after going back to the hotel room at night, and still being behind with a pile of emails and a lot of work. I spent the previous weekend working hard in order to catch up with a large project for the automotive industry we’re working on, and will spend the next one or two at the office, too.

And I genuinely couldn’t enjoy the event as much as I wanted to – simply because my brain was shutting down every now and then.

What Does Contributing Mean?

I’m not going to review any Oxford Dictionary definitions of the “Contributing” word or so, but I had a few discussions over lunch or during the after party that touched on contributing. One of the best ones was a chat with several examples of people doing full-time work for the community and being less respectful to people who stay late at night, after work hours, doing free work, because of their “limited time” – and yet preaching: “You should contribute more!”.

I’ve actually had that conversation with similar people at least a few times – sometimes it is a genuine motivational speech (which everyone needs every now and then), but occasionally it’s a pure misunderstanding of how life works. And while we’re so focused on diversity in terms of gender, race or religion, we completely forget about the different types of people trying to work together on a project.

The Elite Status – The Opposite of “Impostor Syndrome”

I’ve been in other communities where certain companies build a sort of “immunity” status or what I call a “royal family” level. This is normally a well-respected or really powerful group of people that suddenly starts to feel elite and more important than everyone else – often simply due to working for one of those top companies or organizations. That alternative reality may cause damages to people who simply want to give back without being ignored, disrespected or belittled.

Status quo for the alternate reality

Status quo for the alternate reality

Sometimes it’s not even intentional – it’s an “awe” by people who want to see the popular rockstars, and working for, say, Automattic, and speaking at a local meetup is “kind of a big thing”. But if you start taking yourself seriously, then you’re distancing yourself from the reality and the humble and friendly ecosystem which WordPress is (was?) proud to embrace.

And as a catchy question here, you may wonder – how can one compare the 40 hours of week contributed by a full-time well-compensated employee for a community to the 5 or 10 hours a week of hard work for free, during the weekend or late at work, for the sake of the contribution itself?

If you see that as a rant of some sort, you’re wrong. It’s a question that everyone should ask themselves, and validate their own position and understanding of a community. Because when you think about it, the massive amount of time one could spend on anything – be it Core, a plugin, an event – does establish a position of authority.

Recognizing or Eliciting?

I’ve also had a few chats about this Deputy group post by Jen outlining the sponsored deputies helping out. In my opinion it’s great that finally people are being recognized for their contributions for things other than Core, and also the dedicated time is being pointed out. Also, the fact that the Deputy group is distributed and also incredibly diverse (in terms of companies, region and anything) is essential for the development of the group.

But some of the feedback I’ve received was by people who were afraid of the sense of artificial hierarchy. People who contribute more were being promoted, and suddenly two or three different “layers” of management were introduced (or are expected) due to the fact. Being employed and naturally able to help full-time was a definitive factor that would heavily impact a contribution’s significance, and potentially diminish the amount of work contributed by people in their evenings or weekends.

And that is actually a very good point, one on which I don’t have a definitive answer or stand on as of this weekend. I thought about that on Saturday night in the solitude of my room, and remembered a few occasions when I had the advantage of my network of contacts myself – getting patches in Core thanks to meetings in San Francisco, or being able to do things quickly when I was acting as a part-time WordPress ambassador for SiteGround. And while I wouldn’t mind having an infinite amount of money so that I can pay salaries, build free stuff and give back forever, the reality prevents me from doing that, and that is a problem noticeable in various aspects of the community (and many other communities as well).

Blogging Feedback

One of the reasons I decided to share that story and roadmap here was the incredible feedback that I received about my blogging efforts lately. I spoke to 20 different people over at WordCamp Europe who were reading my posts regularly, taking notes, and applying some of my tips in their actual business – improving their freelance career or growing their small businesses.

Some of them were able to find a well-paying job thanks to those, or switch to incredible clients by improving their business processes and planning. Others were sharing my entries with their customers in order to educate them, which was also something that I’m really happy about.

I’ve been blogging since 2006 or so in different blogs, and ever since I started blogging actively about my WordPress community and business experience this year, I’ve been getting a lot of positive feedback. Which is why I plan to allocate more time on writing, and cover other problems that I’ve encountered or discussed with people at WordCamps or online, as well as my regular challenges that I’m dealing with on a daily basis.

My Goals Right Now

While I reduced the contributing efforts on my end last year and limiting the amount of activities I was involved with, I will also step down from a few more, and focus on slightly different things.

One of the things I proposed and strongly supported at the last Community Summit was a mandate of 2 years for WordCamp organizers. Which is one of the reasons why I won’t be joining the WordCamp Europe 2016 as an organizer, and will be a “helper” for WordCamp Sofia this year, too.

This is a complex decision that involves different problems – such as political issues and opinions, or working with fewer people with different ideas, values or goals of mine. While more often than not these are not crucial, it’s just an unnecessary burden that leads to some tension, wasted time on Slack, or overall bashing from people on the outside interested in helping out. I truly believe that honest and hard working people with long history in the WordPress project should be allowed to participate and join regardless of their job status and not being restricted for political reasons (or business ones).

So I am more than happy to limit some of those aforementioned activities and:

  • help out for WC Sofia and our local meetup,
  • spend more time on blogging and sharing knowledge,
  • organize my business process so that everyone is happier and could start helping more (we used to contribute more than 5% until a few months ago before the new hires),
  • help new WordCamp organizers with their local communities,
  • start releasing our beta plugins and iterate their development cycles on GitHub and WordPress.org, sharing more of our code base,
  • keep presenting at schools and universities and introduce people to WordPress,
  • continue to work with interns and mentees, and help them become better, more professional and more successful.

And I will choose my battles wisely – help more people who would like to grow their local communities and spread the good Word.

The post WordPress Contributing Effort and Focus appeared first on Mario Peshev on WordPress Development.

Matt Mullenweg Appoints Nikolay Bachiyski as Security Czar for the WordPress Project

While on stage at WordCamp Europe answering a question related to WordPress’ security track record, Matt Mullenweg named Nikolay Bachiyski as the first Security Czar for the WordPress project.

Bachiyski is employed by Automattic and has been a member of the WordPress community for more than 10 years. Over that time period, he’s established trust with a number of people in and outside of the WordPress ecosystem. The role allows Bachiyski to focus on communication and triage security reports.

Mullenweg admitted on stage that there have been communication issues in the past. He didn’t specify any examples, but one that comes to mind is WordPress 4.2.1.

In April 2015, security researcher Jouko Pynnönen, published details of a security vulnerability in WordPress hours before the team released a patch. He tried contacting the WordPress security team using a variety of channels, all of which came up empty.

WordPress has refused all communication attempts about our ongoing security vulnerability cases since November 2014. We have tried to reach them by email, via the national authority (CERT-FI), and via HackerOne. No answer of any kind has been received since November 20, 2014.

According to our knowledge, their security response team have also refused to respond to the Finnish communications regulatory authority who has tried to coordinate resolving the issues we have reported, and to staff of HackerOne, which has tried to clarify the status our open bug tickets.

No one from the WordPress security team officially announced why or how the breakdown in communication occurred. Hopefully, with Bachiyski as Security Czar for the WordPress project, breakdowns in communication like these decrease or disappear entirely.

Pro Version of Block Bad Queries

BBQ Pro is the premium version of my free security plugin, Block Bad Queries. BBQ Pro helps keep your WordPress-powered site safe and secure by blocking bad URI requests. This helps to conserve precious server resources like memory and bandwidth. BBQ Pro runs silently in the background, checking all incoming traffic and blocking any URI requests that contain nasty stuff like eval(, base64_, and other malicious nonsense. It’s advanced firewall protection that’s fast, flexible, and fully customizable.


Facebook author tags & Yoast SEO

Last week, Facebook did a post on their media site about Facebook author tags. Many blogs, including sites we love like SearchEngineJournal, picked it up as though it was the best new thing since sliced bread. It’s not, obviously, mostly because it’s not actually new. You see, Facebook did release their author tags in June, but not this year, not last year, but two whole years ago. We included it in WordPress SEO 2 days later. Two years ago.

The confusion about how new the Facebook author tags feature was caused us to be slightly surprised when we suddenly got questions from our WordPress SEO Premium customers as to whether we’d include it. We did however write a piece on our knowledge base (which we restyled last week too) about how to implement Facebook author tags with our SEO plugin.

Facebook OpenGraph support in WP SEO by Yoast

Facebook meta data is put on the page in so-called OpenGraph tags. WordPress SEO has some of the most extensive Facebook OpenGraph support you’ll find in plugins out there. If you enable OpenGraph on the Social settings page, it’ll all happen automatically:

Facebook OpenGraph settings - WordPress SEO

Enable Facebook Author tags

For the Facebook author tags feature to work though, you actually have to go into the user profile page of your WordPress install and enter your own Facebook profile URL. That’s it. The plugin will then automatically add more things, like the publisher tags, image tags, a description tag, article type etc. etc. Lots of things you don’t need to think about, we’ll optimize it for you.

If you want to further optimize your OpenGraph output, you can change some of the things the plugin will output on the Social tab of the WordPress SEO metabox:

Facebook settings on the Social tab

We recently added the recommended image size in the descriptions of those upload fields, mostly as we kept forgetting them ourselves.

Just one more reason to use WordPress SEO by Yoast!

This post first appeared as Facebook author tags & Yoast SEO on Yoast. Whoopity Doo!

Brain Workout and Bredogenerator

My multitasking regime is notorious, and I’m quite used to switching context all day long, doing five and more things at a time.

While this may be a tough process to follow, one of the reasons I’m capable of accomplishing that is my brain workouts started a while ago with the Bredogenerator exercise.

I blogged about that on WP Elevation in my guest post – Master Your Communication Skills With Bredogenerator.

The Bredogenerator is a great system that could be practiced anywhere – just like a game, which you could play solo, or in a group. It’s a great brain practice that develops both your logical and creative halves of your brain, allowing you to get out of the box, present alternative realities, vividifying objects, virtually going through time and dimensions.

The benefits of using Bredogenerator are noticeable after a few weeks of regular training, and could seriously improve your communication and negotiation skills, boost your imagination and make you more productive.

If you are the type of person who is in self-development, trying different sleeping regimes, brainstorming patterns and willing to improve your skills, check it out. It’s pretty easy and even entertaining, and my definite replacement of other mind games for keeping my brain up to speed on everything.

The post Brain Workout and Bredogenerator appeared first on Mario Peshev on WordPress Development.

WordPress.tv is Branching Out Into Beginner Tutorial Videos


WordPress.tv is expanding its video catalog beyond WordCamp session recordings. As most of the video content on the site centers around topics for developers and established users, the WPTV team is now actively soliciting submissions for more beginner video tutorials.

Are you a proud member of the WordPress community, who creates (or would like to create) videos that are focused on helping others learn how to use WordPress? If you answered “yes” then we would love your help in submitting your videos to WordPress.tv, so we can share them with the world in our “how to” section.

The current “how-to” category on the site contains mostly outdated videos, featuring ancient versions of WordPress. The WPTV team is hoping to add more “getting started” content that covers basic WordPress site management, including the following:

  • How to configure widgets
  • Setting up a custom menu
  • Managing comments
  • How to insert an image gallery

The initiative to add more beginner content is not new but failed to gain traction in previous attempts.

“Uptake was slow, so we thought it would be a good idea to give it a go again, and put a bit more structure to it,” WPTV contributor Jerry Bates said.

One guideline in particular that was a sticking point the last time the group solicited tutorials was the requirement of no self-promotion or logos in the videos. Contributors have to submit their work for sheer love of the community, which makes it more difficult to gather submissions.

While we want you to be able to benefit from your work, WordPress.tv is a non-commercial community-run website; we can’t accept videos with watermarks, logos, or self-promotion of any kind. We do have a place for you to enter your WordPress.org profile name as a producer credit, so you will get noticed!

So far, the WPTV team has not received many submissions, but the demand for beginner content is there. According to Bates, some of the most viewed videos are consistently the beginner tutorials, despite the fact that they are outdated.

“This is a popular video type on YouTube and in for-pay training courses, but I think the greatest need is for foundation-level videos,” Bates said. “Anything that would help a new user on day one, week one, etc.”

“We need more short and to-the-point tutorials,” WPTV crew member Michael Wiginton said. “Most will not want to watch a 45 minute video when trying to find an answer.”

The team is also experimenting with a plugin that would bring these tutorial videos into the WordPress dashboard, but the first step is to build a library of suitable beginner content.

WordCamp recordings provide a never-ending funnel of content down to WordPress.tv, but only a small slice of these videos are useful for beginners. If WordPress is going to continue to grow its marketshare, the project cannot depend on only providing developer-oriented videos and education. A strong beginner tutorials section on WordPress.tv is a worthy project that will help support new users.

The WPTV crew is a small team, averaging just 5-6 active volunteers. Creating and moderating videos is one unique way to contribute to the WordPress project that doesn’t require writing code. If you’re interested to submit some beginner tutorials, check out the suggestions and guidelines on the WPTV blog.

It’s time to Escape the WordPress Bubble

WordPress has a bad rap in outside circles.  While other communities are seeing WordPress as more than blog software, many still think that since WordPress supports PHP 5.2, it doesn’t also support PHP 5.6 or HHVM.  They don’t know about the all the interesting problems that WordPress solves so that users and developers can get there jobs done easier.  And this is the WordPress communities fault.

We as a community spend to much time living inside our bubble.  This is slowly changing.  People like Helen Hou-Sandí are speaking at cssconf, Jenny Wong at PHPUK, Zack Tollman at PHP[world], and Joe Dolson at CSUN (amongst many others) are getting the word out about WordPress, but we can do better, and we must do better, and we will do better.

To help WordPress developers escape the bubble, I’m creating a mailing list where we can share CFP announcements, review each others abstracts, and support each others desires to break out of the WordPress bubble. The aim is a high signal list (membership will be moderated) where knowledgeable WordPress developers can work together to improve our image.  Let’s break down this bubble.

EDIT: Jenny Wong is going to be giving a talk at WordCamp Europe on this, including some great tools to help you break out of the bubble. If you won’t be at WCEU, you can check out the livestream.

Join the Mailing List

Menu Customizer Officially Approved for Merge Into WordPress 4.3


The Menu Customizer plugin was merged into WordPress trunk today and will be one of the headline features of the 4.3 release.

Roughly a week ago the feature plugin was tentatively approved for merge, pending an a11y audit and PHP and JS tests. Following an overwhelming amount of negative feedback from the community, core contributors published what was essentially a rallying call to get the plugin ready for merge, reaffirming their commitment to iterating with the customizer.

Nick Halsey, the plugin’s developer, published a number of UX flow and performance comparisons of the admin menus screen vs. menus in the customizer. Ryan Boren and Konstantin Obenland also published iPhone 5 and 6 emulations of the plugin in action.

Halsey’s overall conclusion was that managing menus in the customizer takes less time in most cases than managing menus in the admin:

For the tests, I added links to both Menus UIs to the admin bar (4.3 will have one link here, to the Customizer). I ran into a few areas where the experience could be improved, but in terms of timing, the Customizer version wins in most of these scenarios currently. Note that this is intended to compare the experience for power users.

The Menu Customizer is one of the most controversial new features added to core in WordPress’ recent history. It will be interesting to see how it plays out when users discover it in 4.3. Those who were not in favor of the feature voiced their opposition in comments on the original proposal and in independent blogs around the web but were ultimately overruled.

At this juncture, no official timeline has been set for removing the menus screen in the WordPress admin. The existing menus will continue to be maintained for the time being, which should provide an easier transition for users who are surprised by the new feature in 4.3.

BackPress and WordPress Development

Today WP Tavern announced that BackPress is coming back from the dead. For those of you unfamiliar with BackPress, it’s a collection of PHP scripts (or a library, or a sort of framework if you want) for building web applications. On top of that the syntax is quite similar to the WordPress APIs, since it’s a “simplified” version for building web applications with classes and collections of functions that you can find in the WordPress core as well.

Now, the project has been abandoned for quite some time, and most of the code is no longer usable. It has been updated in WP Core during the course of a thousand iterations (or more), but if you dig deeper you’ll find classes and functions that you’ve been using in WordPress for a long time.

JJJ and Sivan want to resurrect BackPress and make it up to date with current WP, which I find really fascinating.

I’m not sure what the plan is exactly – whether it’s fetching a version of WordPress and stripping it down to a framework, or improving every single module since it’s up to date and works like a lightweight version of WordPress. But it reminds me of ExpressionEngine and CodeIgniter, the Open Source framework being the core of ExpressionEngine. It also reminds me of Rails and the way it started, and various forks such as the Backdrop CMS being a lightweight form of Drupal (of sort).

I love WordPress myself and I’ve spent enough time dealing with frameworks in PHP, Java and Python, and the ability of reusing a ton of CRUD features, authentication and much more is a bliss if you’re building a lot of projects with a common internal structure. But some of our projects don’t use a good chunk of what WordPress offers either.

I’ve been working on two different plugins trimming down WordPress – disabling some of the APIs, simplifying the menu structure and everything that we don’t use a lot and could be disabled with hooks or simple conditional statements. The WP API will change a lot of things in the long run, and developers will keep using the WordPress Core without having to deal with a lot of bloated code for specific use cases.

BackPress is the backbone behind bbPress and GlotPress, as well as other community projects. It’s powerful, but pretty old and limited now, and bringing it back to life can change a lot.

While I know that some of the active WordPress developers don’t find BackPress to be a suitable project and everyone looking for a light and flexible framework should just head to Laravel, FuelPHP or something else, I would gladly use BackPress if it includes the WordPress APIs in a highly decoupled manner, allowing you to leverage the power of the Core without having to attach tens of thousands of lines of code for features you don’t use. Also, the WordPress dashboard (and overall admin panel) is overly complicated, and while it was super straight forward for clients 7 years ago, the majority of the simplified SaaS projects and simple CMS have changed the reality.

WordPress is no longer easy. And people no longer need PressThis (have they ever?), need the Comments or even use the posts at all. The Media API is not flexible for document management. The user flow is not decoupled enough for various cases. And there’s simply a lot going on in a single WordPress request, which is often an overhead.

7 years ago people thought that WordPress is a simple blogging tool. We hired a new junior frontend developer this month who was building sites with Joomla and different frameworks since he had no clue that WordPress is usable for real projects. But now Wix, Squarespace, Tumblr even let you build a simple business site in a way that’s much more intuitive. Enterprise users still prefer Java or .NET, or Rails for stability and security. And the middle tear have different needs, which are not always doable with WordPress out of the box.

While I love WordPress and I don’t plan switching away over the next 3-4 years, I would love to use BackPress in some of our projects. We have several applications that could utilize the WordPress database and the core APIs but don’t need the template engine, the admin dashboard, some of the core features that come with a standard WordPress install.

Running a heavy application with the WP-API right now is not straight forward, mostly due to the way WordPress works in general. Various bots hit sites through the XML-RPC API, iterate with WP-Cron, the admin-ajax.php script or hit the standardized login form. While all of those have a solution, it’s not integrated in a standard WordPress install. And the more we trim, cut, remove and detach here and there, the more obvious it is that a simplified “framework”-alike version of the platform would be a great asset for many WordPress developers.

The post BackPress and WordPress Development appeared first on Mario Peshev on WordPress Development.

Introducing Yoast Comment Hacks

Yoast Comment Hacks IconComments are awesome, but the WordPress comments system is sometimes slightly lacking. Several large sites have, in the first few months of this year, announced they were no longer allowing comments. We, at Yoast, don’t understand that. We’ve found that there’s huge value in discussing our posts with our community. Over the years, we’ve made several plugins that all make the comments system slightly better. Today we’re announcing a new plugin that bundles some of that functionality into one simple to install plugin: Yoast Comment Hacks.

This plugin has 5 modules, all of which were previously separate plugins, some feature highlights:

Minimum comment length

By default, a comment of even 1 character is long enough to be saved. We think that’s weird. If someone wants to leave a comment, we’d prefer it if they have something real to say. This module allows you to set a minimum length and prevent people from leaving a comment if they’re under that.

Comment redirect

One of our “old time classics”, this module allows you to redirect first time commenters to a thank you page. You can use this page to inform them about other nice things on your site, stuff they should really read, etc. Want to see how that works? Well. Leave a comment on this post and you’ll see!

Clean notification emails

This was actually not a plugin of ours. The original plugin which inspired us for this was built and released by Mike Davidson in 2008. Mike is now the head of design at Twitter and obviously has better things to do, so we emailed him a while back asking if it was ok for us to update his old plugin. He gave his OK so we went to work on his old code and brought it into this decennium. The code does one “simple” thing: make comment emails look better! See this example:

Screenshot of a clean comment email

There’s more

Check out the Yoast comment hacks plugin page for the other 2 modules and more screenshot examples. You can also check the code on GitHub, or file an issue there if you find a bug or have a great new feature idea. The plugin is of course also available on WordPress.org.

It doesn’t stop here!

We’ll probably add more small comment hacks to this plugin as we go along and find more small ways to make the WordPress comments system easier to use. Do tell us what you’d like to see in the comments below!


This post first appeared as Introducing Yoast Comment Hacks on Yoast. Whoopity Doo!

How to Cloak Affiliate Links on Your WordPress Site

Do you want to cloak affiliate links on your WordPress site? Not sure what does link cloaking means? In this article, we will explain what is link cloaking, and how you can cloak affiliate links in WordPress.

Link Cloaking

What is Link Cloaking and When do you need it?

Link cloaking is a technique used to make long affiliate links into a shorter and more branded link.

Often affiliate links are lengthy, hard to remember, and show your affiliate username or ID like this:


Link cloaking allows you to shorten these lengthy ugly link into branded URLs like these:


You can use anything as base URL. We use refer in our cloaked links on WPBeginner. Some other popular URL bases are out, go, recommends, etc.

If you are someone who uses affiliate links in your blogs to make money, then you should to cloak links. Many site owners cloak links to properly manage their affiliate links.

Link cloaking allows you to create easy to understand URLs for your outgoing affiliate links. It can also help you add an additional layer of click tracking to ensure you are getting paid for every sale you refer.

You can also protect your affiliate links from getting hijacked by using link cloaking. Lastly, cloaked links allow you to easily manage your affiliate links from your WordPress admin interface.

Video Tutorial

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

How to Cloak Affiliate Links in WordPress

Since affiliate marketing is an important source of income for many bloggers, there are many WordPress plugins available that allows you to cloak your affiliate links and easily manage them.

We have hand-picked some of the best WordPress link cloaking plugins for you.

You can use any one of these plugins to easily add your affiliate links into WordPress and cloak them to get maximum benefits.

1. ThirstyAffiliates

ThirstyAffiliates is one of the best affiliate link manager and link cloaking plugin for WordPress. It allows you to easily add your affiliate links in WordPress and manage them from one single dashboard.

You can insert your affiliate links in any WordPress posts or pages from the buttons on the post editor screen.

Another great feature is that you can automatically replace selected keywords with affiliate links. Aside from that you can choose the base URL, automatically nofollow links, A/B test your offers, geo-target your offers, get stats, and so much more.

We use ThirstyAffiliates on WPBeginner. See our guide on how to add affiliate links in WordPress using ThirstyAffiliates.

2. Pretty Link Lite

Pretty Link Lite

Pretty Link Lite is another WordPress link cloaking plugin. It allows you to easily manage your affiliate links. You can auto add nofollow tag to affiliate links, shorten links, and redirect them properly.

Pretty Link Lite also provides analytics with an easier way to purge older hits from your database. This ensures that these hit logs don’t take too much space on your database and backup files.

3. Easy Affiliate Links

Easy Affiliate Links settings

Easy Affiliate Links is an easy to use link cloaking plugin for affiliate marketers. It allows you to cloak links, add and manage all your affiliate links from a single dashboard.

Basically it has all the features that you would want from a link management plugin with a nicer and easier interface.

4. WP Wizard Cloak

WP Wizard Cloak

WP Wizard Cloak is another WordPress affiliate link management plugin. It comes with all the whistles and bells you would need from an affiliate link management tool.

It provides URL shortening and link cloaking with easy to use tools to add and manage your affiliate links in WordPress.

5. Links Auto Replacer

Link Auto Replacer

Links Auto Replacer is a bit different than most other plugins in the list. As the name suggests, its main use is to automatically add links for certain keywords. You can manage your links and add new links just like any other link management plugin.

6. WooCommerce Cloak Affiliate Links

WooCommerce Cloak Affiliate Links

As the name suggests, WooCommerce Cloak Affiliate Links plugin is for eCommerce sites built on WooCommerce platform.

This plugin cloaks all external links on a WooCommerce site automatically. You can choose a URL slug by visiting Settings » Permalinks page. You can also change the redirect type. But that’s about it, this plugin is not a link manager so you cannot use it to add or manage your affiliate links.

7. Affiliate Link Manager

Affiliate link manager

Affiliate Link Manager plugin takes a different approach for link cloaking. It does not add a URL base like most other plugins in the list. Instead it allows you to use a keyword as the URL slug for the cloaked link. In terms of features it is very limited, but it does the job. It also offers some basic stats for your cloaked link views.

We hope this article helped you learn how to cloak links on your WordPress site. You may also want to check out 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 Cloak Affiliate Links on Your WordPress Site on WPBeginner.

WordPress SEO 2.2

Both WordPress SEO Premium and the free version of WordPress SEO have been updated to version 2.2. This new release brings quite a few changes and some nice new additions. We’ll explain the changes in this post.

Security fixes

This release contains a fix for a potential XSS issue in the admin, specifically the snippet preview. It was caused by issues in our JS, which is why also did another overhaul of our admin JS. The XSS issue required you to be logged in, so the risk level was relatively low.

Community input

This release contains code that was suggested by 5 people outside of the core WordPress SEO development team. We particularly want to highlight and thank Gary Jones as he’s done several great suggestions for this release. We’ve also had great feedback from Gary and several others on how to improve the accessibility of the plugin, all of those changes are incorporated in this release.

No more tracking class

We’ve removed our external tracking. We were doing opt-in tracking of a couple hundred thousand sites, but as WordPress.org is improving how it does its stats, we’d rather focus on other things. This means we’ll no longer give you a popup asking for permission on new installs.

Recognize your redirects

Recently, while Joost was helping on a major domain migration, he couldn’t locate which bit of code was creating a particular redirect. Annoying as this was, he decided it was time to invent a new HTTP header, to be sent right before a redirect header. This header, X-Redirect-By, identifies the piece of software that created the redirect. We’ve implemented it in WordPress SEO immediately and hope it’ll save a few of our users a headache at some time.

Premium: better redirect notices

As Joost wrote about last week, we improved the notices that urge you to redirect changed / deleted posts and terms if you’re using WordPress SEO Premium. These should help you to keep your site optimized. If you’re not using WordPress SEO Premium yet, you really should consider it. Not only will you get more features and support from our team, you’ll also help fund the further development of the entire plugin.

Integration with other plugins

We love it when plugins integrate nicely with our SEO plugin. Nested Pages is one of those. It’s an intuitive drag and drop interface for pages in the admin. It’s so nice, we dare say it’s what the WordPress interface should look like. When you run WordPress SEO, it highlights the SEO score (through our simple color coded circles) right on the overview:

Nested pages example

Joost recently submitted a patch for Nested Pages so it will show blue for noindexed pages, a patch that was promptly accepted. We love open source!

We’ve done some work in this release to make sure that we in turn integrate well with Nested Pages. This means that when you delete a page, the notice you get to redirect the URL will work, which it didn’t before because you weren’t on the normal edit pages screen.

Other bugfixes & changes

A couple of the changes we’ve done:

Redirect to about
Quite a few people complained about the redirect to our about page after an update. We’ve heard you and changed how it works. You’ll now get a dismissible notice with a link to the release notes, we’ll no longer redirect you.

Fixed multisite settings import
You should now be able to properly import settings on multisite environments.

Facebook Insights authentication
Next to moving this to the bottom of the Facebook tab (it’s not that important), we’ve changed how you can authenticate to get access to Facebook insights. This knowledge base article is probably the best explanation. If you were already authenticated you don’t need to change anything.

Under the hood
Also in this release, we’ve cleaned up all our JavaScript and, more important: documented all of it and made sure it no longer gives JS Hint warnings. We did more cleanup like this, in our continuous effort to both write better code and improve how we do so.

News SEO

Our News SEO plugin has had a small update too, fixing some sitemap caching issues people were having. If you don’t know our other premium SEO plugins, check them out.

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

WordPress Core Contributors Call for User Testing on the Menu Customizer Plugin


Ryan Boren published a post to the Make/WordPress Core blog this afternoon, titled Trust, Live Preview, and Menus in the Customizer. In it he clarified the reasons why he and several other core contributors are committed to iterating the customizer and identified the feature as a means of building user trust through live previews.

Being able to make non-destructive changes and preview them is an important component of building that trust. This is perhaps most noticeable in the “save and surprise” approach of the widgets admin screen – every time you add a new widget, modify its settings, or move one around, the changes are saved and appear live on your site, even if you’re not ready yet. The customizer is our framework for live previewing changes. We are committed to providing live preview for all aspects of site customization and making it usable on all devices from phones to large screens.

Boren briefly summarized the history of the customizer and alluded to a few possibilities the framework may offer in the future:

The customizer has come a long way, but it still lacks some features and needs time to mature. We have many improvements planned and in progress, including transactions, partial refresh, theme installation, speedier loading, scaling to large screens, and possibly even integration with front end editing. Our live preview framework offers many possibilities.

The Menu Customizer plugin was tentatively approved for merge during last week’s core development meeting. In order for the it to be officially approved for merge on June 17th, the plugin will need to meet the feature plugin criteria outlined in the core handbook.

“We have eight days to get the Menu Customizer plugin ready for merge,” Boren said. During this time the flow team will be testing and documenting the flow and visuals for the menu customizer.

Boren invited anyone who wants to contribute to this effort to create flow comparisons of the existing flow through Appearance > Menus versus flow through the customizer. This essentially involves walking through the experience of setting up menus, taking screenshots of the flow, and publishing them as a captioned gallery.

“Please help us capture the flows through Appearance > Menus used by you and your clients,” he said. “We need this information to ensure our new interfaces are mindful and aware of how WordPress is actually used.”

Anyone can contribute to WordPress in this way, as it doesn’t require any coding. The core team is looking for people to capture real user scenarios to help in making the final decision.

There is No Timeline for Removing the Appearance > Menus Screen

In the original merge proposal for the Menu Customizer the plugin’s author, Nick Halsey, outlined what he called a “fairly aggressive” plan for the removal of the old menus admin screen. As contributor resources are scarce when it comes to the Menus component, Halsey favored focusing all new development on the UI in the customizer.

The timeline he outlined was for WordPress 4.3 to point the Menus link in the admin bar to Menus in the customizer and later releases (WordPress 4.5 or 4.6) would remove all core links to the Menus admin screen.

WordPress users reacted strongly to this aggressive timeline for removing the old menus screen, but the timeline was merely a suggestion as part of the proposal. Halsey was not keen on merging the plugin without a definitive timeline for removing the old menus, a factor which he considered a “dealbreaker” for merge.

However, WordPress 4.3 release lead Konstantin Obenland confirmed that no official timeline has been set.

Ryan Boren also confirmed that WordPress will continue to maintain the Appearance > Menus screen should the plugin be officially approved for merge in the coming days:

Meanwhile, the Appearance screens will remain and will be maintained. Appearance > Menus recently received some attention in the form of a few fixes. More attention is needed and will be given. There are still differences in the flows each approach best enables, whether it’s new site/theme setup, small maintenance tasks, or dedicated content managers for heavy usage of widgets, menus, or other pieces of content that benefit from having a preview mechanism. We should gather quantifiable metrics when it comes to performance and time to completion for a given flow, as well as evaluating the less-objectively-quantifiable perceived performance. There may come a time where the worlds converge; however, that time is not now.

This confirmation should assuage those whose opposition to the Menu Customizer was solely based on the aggressive timeline proposed for removing the old menus screen.

The great divide on the Menu Customizer revolves around one aspect of improvement that Boren mentioned in his paragraph about the future of the customizer: scaling to large screens. The vast majority of WordPress users and developers who are following this debate are those who would be more likely to configure a menu in a desktop environment and not via mobile (where the customizer is currently designed to shine).

Many who oppose the merge of the plugin have identified the cramped UI as the primary reason that it does not provide a better experience for users. You would be hard pressed to find anyone who is opposed to live previews or better usability on mobile devices.

Those who manage WordPress sites via desktop are not willing to sacrifice the old menus screen for a new UI that currently caters primarily to smaller devices. Until the Menu Customizer can adequately provide a UI that fully adapts to all screen sizes, resistance to the feature is likely to continue.

Customizer typography project

Customizer Typography Screenshot

Over the past few weeks, I’ve been giving some thought about building a typography control class for the WordPress customizer. I started to write a tutorial on the process, but such a tutorial would probably be in the neighborhood of 4,000 words. With something so highly technical, I didn’t think a tutorial would be the best method of grasping the subject matter.

Yesterday, I had an afternoon of free time to devote to this and came up with a proof-of-concept plugin for the idea.

If you just want to skip the rest of this article, hop over to the Customizer Typography GitHub repo and play around with it. It’s only meant for development purposes and to show one method of executing the idea.

The approach

There were several considerations when building a typography tool for the customizer. The most important was not having to add tons of code while still providing the developer complete control over each setting.

Generally, when adding controls for such a thing, you’d have to follow a specific process:

  • Add setting for font family.
  • Add control for font family.
  • Add setting for font weight.
  • Add control for font weight.
  • Add setting for font style.
  • Add control for font style.
  • Add setting for font size.
  • Add control for font size.
  • Add setting for line height.
  • Add control for line height.

I wanted to simplify that. Fortunately, the Customization API in WordPress is pretty powerful and allows you to tie multiple settings to a single control. This simplifies the above process to:

  • Add setting for font family.
  • Add setting for font weight.
  • Add setting for font style.
  • Add setting for font size.
  • Add setting for line height.
  • Add single customizer control.

That’s not an insignificant amount of code that we just got rid of. Just to give you an idea of how all of this works, take a look at the following code from the plugin.

$wp_customize->add_setting( 'p_font_family', array( 'default' => 'Arial',  'sanitize_callback' => 'sanitize_text_field', 'transport' => 'postMessage' ) );
$wp_customize->add_setting( 'p_font_weight', array( 'default' => '400',    'sanitize_callback' => 'absint',              'transport' => 'postMessage' ) );
$wp_customize->add_setting( 'p_font_style',  array( 'default' => 'normal', 'sanitize_callback' => 'sanitize_key',        'transport' => 'postMessage' ) );
$wp_customize->add_setting( 'p_font_size',   array( 'default' => '16',     'sanitize_callback' => 'absint',              'transport' => 'postMessage' ) );
$wp_customize->add_setting( 'p_line_height', array( 'default' => '32',     'sanitize_callback' => 'absint',              'transport' => 'postMessage' ) );

    new Customizer_Typo_Control_Typography(
            'label'       => esc_html__( 'Paragraph Typography', 'ctypo' ),
            'description' => __( 'Select how you want your paragraphs to appear.', 'ctypo' ),
            'section'     => 'p_typography',
            'settings'    => array(
                'family'      => 'p_font_family',
                'weight'      => 'p_font_weight',
                'style'       => 'p_font_style',
                'size'        => 'p_font_size',
                'line_height' => 'p_line_height',
            'l10n'        => array() // Custom labels if wanted.

I could’ve simplified it further, but it would’ve come at the cost of decreased flexibility. This seems to be a good balance that exposes the API to developers rather than tucking it all behind something custom.

Feedback and patches welcome

Grab a copy of the Customizer Typography plugin and play around with it a bit. Let me know what you think and see if you can improve on it.

The post Customizer typography project appeared first on Justin Tadlock.

A Primer on Writing Good Documentation

JeffMatsonThumbnailThis post was contributed by guest author Jeff Matson. Jeff is the head of documentation for GravityForms. He is the creator of the Heartbeat Control WordPress plugin and is a fan of the 90s.

Often times, documentation is the most underrated piece of the development process. When we look at rockstars in the WordPress community, we typically look at developers, designers, and marketers. Little is known about the documentation writers out there who shed their blood, sweat, and tears to ensure everything runs smoothly.

This post is about those who day in, and day out stare at endless lines of code to decipher what the developer was thinking, and the true meaning behind the code that exists.

Good Documentation is More Than Words

Documentation Words
photo credit: Variatie – Tekst(license)

Good documentation writers provide more than an instruction manual, they provide an experience. I have known excellent documenters, coached beginners, and the largest difference between them is understanding the brain of those reading it. Just like a novel, documentation has a flow that keeps the reader interested and ingesting more information than they realize.

Quality documentation targets the users that are most likely to read it. It also provides a point of reference for those who are more unlikely to read it. For example, if documenting a particular hook, it’s typically assumed that a developer will be reading it, but what about those who have little development experience?

A good documentation writer will provide a point of reference for those who need more of a push in the right direction, without the need to contact support to spell it out for them.

Documentation Has a Larger Impact Than You Think

Impact Image
photo credit: Eruption(license)

Most simply ignore documentation, pushing it off into the endless abyss until they can’t take it anymore. I’m guilty of the same thing in some cases. What those people don’t realize, is that every moment their plugin or theme is left undocumented, user experience suffers.

Let’s take a look at your most common support ticket. If you better documented that issue, would those tickets go away entirely? Probably not. Would you get fewer tickets regarding the issue as well as increase you or your support agent’s productivity? I guarantee it. I think we could all use fewer support tickets.

As I mentioned previously, documentation makes a dramatic impact on user experience. If the user is able to locate the information easily and efficiently, they have saved their own time as well as yours. The average world life expectancy is 66.57 years and your users would rather be doing something else with their lives than fiddling around with poorly written documentation.

If a customer sees that you have put quite a bit of time and effort into your documentation, they will, whether consciously or not, better appreciate you. Good documentation shows you care about them after the initial sale.

Have you ever been left high and dry after spending hard-earned money and soon regretted the purchase? I think we all have. With proper documentation, you can avoid passing that feeling off to your customers.

How Can You Write Better Documentation?

The first step is to stop avoiding it. Once you’re good at it, writing documentation is more of a pleasurable experience than you think. In fact, it will become second nature. Just like everything else in the world, practice makes perfect.

One of the first steps you want to take when deciding to take your documentation to the next level is to determine your pain points. What are you being contacted about? If you start blindly writing about things, you may find that what you’re writing about isn’t making as much of an impact you would like it to.

One of the best techniques I have discovered is to track the number of tickets that are documented vs. those that are not, and break those that are not into categories. This way, you can better target your pain points, and revise the parts that may not be as helpful as they should be.

After you have determined what documentation you should write, you should determine your target audience, and break it down into developers, users, and power users. This helps you cater to that particular audience. We’ll go over how to target those users a bit later.

Next, you want to break down the document. For developers, you’ll want to break it down into raw information (accepted arguments, return values, etc.), specific examples and use-cases. For users, the best course of action is a walkthrough. Every step they will need to take, regardless of how trivial it may seem, is critical.

Spell it out to them every step of the way. Documenting for power users is very similar to a user scenario, but more structured and scannable. Be clear, but allow them to easily jump to where they need to go without reading the previous step first.

The Art of Writing Better Documentation

Documentation Art
photo credit: Space invader. Paris. Gare de lyon(license)

When it comes to the art of writing your documentation, write in a way that best targets your audience, but also use simple language that you know they will understand. One of the best reasons for this is due to translations. While Google translate does an excellent job, it’s much easier to translate the simple vocabulary of a 5th grader than that contained within a post-grad thesis.

Within your content, don’t be afraid to link to relevant content. This will allow you to avoid repeating yourself through multiple documents, as well as allow the reader to back-track if they need more information about a particular subject. After all, your main goals are to make the user happy, and save yourself time.

The documentation process doesn’t stop after you press the publish button. Go back and revise every document as needed. Almost immediately after the document is published, go back and see if the support tickets you tracked have declined, and traffic to that particular article has increased. Usually, if you’re getting more traffic to an article, it’s helping. If you’re getting more traffic but the same number of support tickets, you may want to look into that article to see why.

What We Have Learned

First, I hope that after making it this far, you have a better appreciation for those in the trenches writing the documentation that most of us take for granted. It truly is an art form that many of us who write documentation for a living truly enjoy and put many, many hours into.

I also hope that you come away from this article thinking more about your existing documentation and how it can be improved. Proper documentation can be extremely rewarding and once in practice, can actually be quite fun to write.

Document early, document often. A great product is more than great code, it’s also beautifully documented.

‘Policy’ on PHP Versions

The official stance of WordPress.org is that WordPress is supported on PHP 5.2.4 or greater.

The official stance of the Plugin Team regarding what version of PHP your plugins can use is .. not that.

We don’t have an official stance. We’ve never needed one. We do (often) test complex plugins on multiple versions of PHP (and sometimes HHVM) to make sure there’s proper degradation and support, but at the same time, we do not have an official requirement that you must support version X or Y.

This is not an official requirement post.

This is a reminder post.

Use whatever version of PHP works best with the code you’re writing. If you’re using, for example, Amazon S3’s library, you must use PHP 5.3 and up because otherwise the libraries won’t work. From that standpoint, your plugin should require PHP 5.3 and up. That’s a decision prompted by circumstances outside of WordPress.

For everyone who just wants to know what to do if your plugin must be on PHP 5.3 or 5.4, the answer is this:

Make sure your plugin checks for any and all requirements on activation and, if they’re not found, it should gracefully fail and alert the user as to why.

This includes things like required software (if your plugin is an add-on to WooCommerce, yes, check that WooCommerce is installed and active), but also PHP versions and (if needed) SQL versions. That’s your responsibility. We’re not going to force you to do it at this time, but understand that your plugin’s reviews and ratings will be directly impacted by how you handle those things.

Fail gracefully. Degrade gently. Error politely. Consider your users. Remember: WordPress can be used on anything.

This can be complicated or not, depending on your requirements. The main thing to think of here is that if you don’t support PHP 5.2, then your main plugin still needs to work in PHP 5.2.

Practical Examples

Let’s say you use a function that only works in PHP 5.3 and up. A simple function_exists check will do the job:

if ( !function_exists( 'some_function' ) ) {
    add_action( 'admin_notices', create_function( '', "echo '<div class="error"><p>".__('Plugin Name requires PHP 5.3 to function properly. Please upgrade PHP or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );

Note the use of create_function here, because anonymous functions (aka closures) don’t work in PHP 5.2.

The use of return prevents the rest of the plugin from executing here, preventing that function call later from causing a syntax error.

Sometimes though, you need more complicated checks. Let’s say your plugin uses PHP namespaces. Those are not supported in PHP 5.2, and will cause a syntax error just from having them in the file, before any of your code runs.

So, your main plugin file needs to not have namespaces and basically only be a shiv to load the rest of the plugin from another file if the requirements are met:

if ( version_compare( PHP_VERSION, '5.3', '<' ) ) {
    add_action( 'admin_notices', create_function( '', "echo '<div class="error"><p>".__('Plugin Name requires PHP 5.3 to function properly. Please upgrade PHP or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );
} else {
    include 'rest-of-plugin.php';

Here, the plugin does not load the files that can cause errors unless the requirements are met.

Maybe you need to check against the WordPress version. Plugins load in the global context, so the $wp_version variable is available to you to check:

if ( version_compare( $wp_version, '4.0', '<' ) ) {
    add_action( 'admin_notices', create_function( '', "echo '<div class="error"><p>".__('Plugin Name requires WordPress 4.0 to function properly. Please upgrade WordPress or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );

Although, if you’re requiring a specific WordPress version, then you’re more likely to be requiring a specific function instead, in which you should check for that specific function as in the first example.

If you want to be complicated about it, you can indeed do so. Here’s code for a plugin which will deactivate itself if the PHP version requirement is not met:

if ( version_compare( PHP_VERSION, '5.4', '<' ) ) {
    add_action( 'admin_notices', create_function( '', "
        echo '<div class="error"><p>".__('Plugin Name requires PHP 5.4 to function properly. Please upgrade PHP. The Plugin has been auto-deactivated.', 'plugin-name') ."</p></div>'; 
        if ( isset( $_GET['activate'] ) ) 
            unset( $_GET['activate'] );
        " ) );
    add_action( 'admin_init', 'pluginname_deactivate_self' );
    function pluginname_deactivate_self() {
        deactivate_plugins( plugin_basename( __FILE__ ) );
} else {
    include 'rest-of-plugin.php';

The reason for the unset of $_GET[‘activate’] here is so that the normal plugin activation process will not show the normal activation message, showing the plugin’s message only.

These are not the only ways to perform a check like this, however they should be enough to get you started. Remember: Make things obvious to your users what the problem is, so they can understand the situation and take action.

JavaScript templating in the WordPress customizer

In my previous tutorial on building a radio image control in the WordPress customizer, instead of using PHP to output data for the control output, I used JS. Specifically, this used Underscore’s templating engine that’s packaged with WordPress.

While I’m not well-versed in JavaScript, it’s something that will increasingly become standard for customizer controls and, most likely, other parts of WordPress in the future. Therefore, it’s something that all serious WP developers need to be studying and using.

Unfortunately, understandable documentation and tutorials are few and far between, which is bit crazy considering we’ve had Underscore.js in core since version 3.5. It might take a bit of trial-and-error and reading core code examples to figure things out.

When using a JS templating engine, you remove the PHP logic and just have a single template that’s reused. What changes is the data that gets output. This could also be done on the fly. It’s pretty powerful stuff when you think of some of the possibilities.

In this tutorial, I’m going to cover some of the things I’ve learned so far while working with JS templates in the customizer. If you want to check out some real-world code examples, I highly encourage looking over the customize folder in the upcoming version of Hybrid Core.

Mustache-inspired syntax

Because Underscore’s syntax will cause a fatal error on any WordPress site with asp_tags enabled in their php.ini file, core couldn’t use that. So, WP uses {{ mustache }}-inspired template tags.

There are three tags you need to know:

  • <# #> – Used for executing JavaScript code.
  • {{ }} – Used for outputting escaped data.
  • {{{ }}} – Used for outputting unescaped data such as HTML.

Once you get the hang of how those work, it’s pretty easy to make the jump from the PHP-coded output that you might be used to.

Building custom controls

I won’t cover the ins-and-outs of creating custom control classes. That’s outside the scope of this tutorial. Otto has a great tutorial on building controls that you can follow. Think of this as the next step.

Registering your control

I’m going to assume you have a custom control named JT_Customize_Control_Select in a file named /customize/control-select.php in your theme for the purposes of this tutorial. It’s going to output a basic <select>. Yes, core has a select option built in, but we just need a basic example.

In order to register your control type, you need to utilize the WP_Customize_Manager::register_control_type() method. This is important because we need WP to recognize our JS template output.

Here’s an example of how that’d look in your theme:

add_action( 'customize_register', 'jt_customize_register' );

function jt_customize_register( $wp_customize ) {

    // Load our custom control.
    require_once( trailingslashit( get_template_directory() ) . 'customize/control-select.php' );

    // Register the control type.
    $wp_customize->register_control_type( 'JT_Customize_Control_Select' );

As you can see, we just used the class name to register it.

Sending PHP data to JavaScript

If using JavaScript to build templates, we need a method for getting the data. That’s where the WP_Customize_Control::to_json() method comes in. In your custom control class, you’ll need to create that method to send over any data you’d like to use.

Let’s take a look at what a custom to_json() method might look like for a custom select control:

public function to_json() {

    // Call parent to_json() method to get the core defaults like "label", "description", etc.

    // The setting value.
    $this->json['value'] = $this->value();

    // The control choices.
    $this->json['choices'] = $this->choices;

Building the JS template

For those of you familiar with creating custom controls with PHP, you’re probably used to overwriting the WP_Customize_Control::render_content() method. Instead, we’ll overwrite the content_template() method for JS templating.

So, if you were building a <select> output, it would look something like the following. This is where we’ll be using the data passed from the to_json() method in the previous step.

public function content_template() { ?>

    <# if ( ! data.choices ) {
    } #>


        <# if ( data.label ) { #>
            <span class="customize-control-title">{{ data.label }}</span>
        <# } #>

        <# if ( data.description ) { #>
            <span class="description customize-control-description">{{{ data.description }}}</span>
        <# } #>

        <select {{{ data.link }}}>

            <# for ( key in data.choices ) { #>

                <option value="{{ key }}" <# if ( key === data.value ) { #> checked="checked" <# } #>>{{ data.choices[ key ] }}</option>

            <# } #>


<?php }

As you can see, the method utilizes the Mustache syntax to output the data. It’s not a huge stretch if you’re used to working with PHP. Keep note of where double braces, {{, and triple braces, {{{ are used. You want to make sure your data is escaped when it needs to be escaped.

Setting the data

One thing you might have noticed if you’ve built something with the code above is that the “Save and Publish” button is not triggered nor is the data saved. We’ll need to do that with JS too.

I always create a custom JS file called customize-controls.js and put it in my theme’s /js folder. There are two things you’ll need in your control class for this. The first is you need to define the $type property to something custom (should be doing this anyway).

public $type = 'jt-select`;

The next is you need to create the enqueue() method to load your script:

public function enqueue() {
    wp_enqueue_script( 'jt-customize-controls', get_template_directory_uri() . '/js/customize-controls.js', array( 'jquery' ) );

Then, you need to use the following in the in your script file:

jQuery( document ).ready( function() {

    // Watch for a change in the customize <select>.
    jQuery( '.customize-control-jt-select select' ).change(
        function() {

            // Assign this to a new variable.
            var choice = jQuery( this );

                jQuery( choice ).attr( 'data-customize-setting-link' ), // Gets the setting name.
                function( obj ) {

                    // Sets the new value based off the <select> value.
                    obj.set( jQuery( choice ).val() );

} ); // jQuery( document ).ready

There may be a much better way of handling that. Feedback is more than welcome.

Comments? Feedback?

As I said, this is entirely new territory for me. The best way I can learn how to do this is to put it into practical application and to write about it.

If you have any corrections or better methods for doing this, don’t hesitate to let me know in the comments. Otherwise, I hope you’ve found this tutorial helpful.

The post JavaScript templating in the WordPress customizer appeared first on Justin Tadlock.

Menu Customizer Tentatively Approved for WordPress 4.3

WordPress 4.3 release lead Konstantin Obenland posted notes from this week’s core development chat, confirming that the Menu Customizer plugin has been conditionally approved to merge. The approval is pending a few conditions that will be required before officially merging it:

  • Complete a11y audit.
  • Address possible blockers.
  • Merge php tests.
  • Add JS tests.

One of the most controversial aspects of the proposal submitted by project leader Nick Halsey was the timeline he outlined for removing all core links to the old Menus admin screen in future releases. Commenters on the proposal reacted strongly to this approach as well as this particular use of the customizer.

Discussion continued following the meeting, as Halsey wanted to address the critical issue of the timeline for removing removing the menus screen from the admin. He attributes the resistance to the customizer to a lack of education on the feature and strongly advocates “focusing on the new UI as the primary (and in terms of development, only) menus admin interface.”

For Menu Customizer, this idea has been part of the project from the very beginning. My GSoC proposal (3/20/14) states ‘If the Menu Customizer provides all of the features of the existing menu management screen, while clearly demonstrating that it is a better solution than the existing screen in user tests, it could potentially replace the existing screen entirely for users that can access the Customizer,’ and there has never been indication that this isn’t the direction we should move in, other than the general and ongoing resistance to the Customizer as a whole that we’ve seen from many community members (which I think is more of an educational issue).

Discussion continues on the matter and work will move forward on the plugin to ensure that it meets the conditions outlined for its merge into WordPress 4.3.

How to Create WordPress eCommerce Store With Shopify

Did you know that last year online sales crossed $1.47 trillion mark? This exponential growth became possible with tools like WordPress and Shopify which allow anyone to build their own eCommerce store and start selling. While there are plenty of WordPress eCommerce plugins available, often the easiest eCommerce solution to run your own online store is Shopify. In this article, we will show you how to create an eCommerce store with Shopify and add it to WordPress.

Why Choose Shopify?

Creating an online store on Shopify

Shopify is an eCommerce platform that lets anyone build an online store without any technical knowledge. It is a hosted platform which means all your store’s data remains on their servers. You can still use it with your self-hosted WordPress site with your own domain name.

Shopify offers a secure shopping cart, with 70 different payment gateways, shipping options, and is available in multiple languages. It can handle flexible shipping options and automatic tax calculations.

If you already run a WordPress site, then you can easily sell your products using Shopify without worrying about all the technical aspects of an eCommerce store such as setting up SSL, integrating different payment gateways, handling shipping, worrying about taxes, etc.

Not to mention, you can also sell in person using Shopify.

In other words, it’s a straight-forward eCommerce solution for beginners and business owners.

Getting Started With Shopify

First you need to visit the Shopify website and signup. Shopify offers three different pricing plans, and you can try it free for 14 days.

Once you have signed up, Shopify will setup a store for you with your own subdomain like example.myshopify.com. You will see your Shopify admin dashboard, which looks like this:

Shopify admin dashboard

To add your products, click on the products menu in the admin bar and then click on Add a product button. Here you can provide a title and description for your product, add images, pricing, shipping options, etc.

Adding products in Shopify

Once you are done, click on the save product button. Repeat the process to add your other products.

Adding Shopify To Your Self Hosted WordPress Site

The easiest way to add Shopify to your WordPress site is by adding the link called Store in your main menu.

You can do this by going into your WordPress admin area (Appearance » Menu).

Add Store Link to the Menu

Next click on the Custom Links tab and simply add your Shopify store link to the menu.

This will allow your users to see that they have a store. When a user clicks on the store link, they will be taken to your shopify store where the transaction may happen.

It’s a simple and straight forward process.

The only downside is that in theory the customer is switching domains. If you want to integrate Shopify within WordPress, then follow the next more complicated step.

Integrating Shopify with WordPress

To add Shopify products into your WordPress site, you will first need to activate Shopify Buy Button app.

You can do this by clicking on the App menu in the Shopify admin dashboard and visit their apps store.

Shopify Apps

Search for buy button, and then click on the ‘Get’ button to activate the app on your Shopify store.

Adding the buy button app to your Shopify store

After the app is activated, you will be redirected to its settings. This is where you can select the products you want to include into the buy button.

Creating your Shopify buy button by selecting products

Select a product from the popup and then click on the select product button to continue. On the next screen, you will see a preview of the product and how it will appear on your site. Click on the generate embed code to continue.

Generating embed code for a product

Shopify will now show you the embed code. Click on the checkbox ‘I need to add script tags separately’. This will break up the code into two sections.

Shopify embed code for WordPress

The first section needs to go into your WordPress theme’s header.php file just before the </head> tag.

Alternately, you can use Insert Headers and Footer plugin to insert this code into your theme’s header. You will only need to add this code once.

The next time you are adding a product, you will only need to add the code in the second box.

After adding the script code to your site’s header, you can now copy the code from the second box and paste it into any WordPress post, page, or widget.

Previewing a Shopify product embedded into a WordPress post

Repeat the process for other products on your Shopify store.

We hope this article helped you create your eCommerce store with Shopify and add it to WordPress. You may also want to check out 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.

To leave a comment please visit How to Create WordPress eCommerce Store With Shopify on WPBeginner.

Customizer radio image control

Layout customizer control

In this tutorial, I’ll be writing about a radio image control for the WordPress customizer. This was a request, but I honestly don’t remember who asked for it. Sorry for forgetting. I hope you’re following the blog. :)

This type of control is also something I’ve needed for a long while. It’s now being used in the revamped layout setting in the Hybrid Core framework.

Basically, a radio image control replaces your standard <input type="radio" /> fields with selectable images. So, it’s pretty cool for things like selecting a layout or any other setting where it’d be nice to have a visual representation of the option.

Like other advanced customizer tutorials, I’ll be moving through this fast and not explaining each detail. You need to be at least somewhat familiar with building settings in the customizer before moving forward.

Building the radio image control class

The first thing we need to do is build a custom control class that extends WP_Customize_Class. So, create a new file called control-radio-image.php in your theme’s /customize folder (or whatever structure you prefer) and place the following code into it.

Fair warning for those of you studying the code: you may be used to seeing a render_content() method in custom control classes. I opted to go with a JS template via the content_template() method. See core ticket #30738 for the main reason why. Admittedly, I’m a bit out of my element working with JS templates, but the best way to learn is to simply do and to teach others by writing about it. Feel free to correct anything I screw up.


 * Radio image customize control.
 * @since  1.0.0
 * @access public
class JT_Customize_Control_Radio_Image extends WP_Customize_Control {

     * The type of customize control being rendered.
     * @since  1.0.0
     * @access public
     * @var    string
    public $type = 'radio-image';

     * Loads the jQuery UI Button script and custom scripts/styles.
     * @since  1.0.0
     * @access public
     * @return void
    public function enqueue() {
        wp_enqueue_script( 'jquery-ui-button'          );
        wp_enqueue_script( 'jt-customize-controls', get_template_directory_uri() . '/js/customize-controls.js', array( 'jquery' ) );
        wp_enqueue_style(  'jt-customize-controls', get_template_directory_uri() . '/css/customize-controls.css'                  );

     * Add custom JSON parameters to use in the JS template.
     * @since  1.0.0
     * @access public
     * @return void
    public function to_json() {

        // We need to make sure we have the correct image URL.
        foreach ( $this->choices as $value => $args )
            $this->choices[ $value ]['url'] = esc_url( sprintf( $args['url'], get_template_directory_uri(), get_stylesheet_directory_uri() ) );

        $this->json['choices'] = $this->choices;
        $this->json['link']    = $this->get_link();
        $this->json['value']   = $this->value();
        $this->json['id']      = $this->id;

     * Underscore JS template to handle the control's output.
     * @since  1.0.0
     * @access public
     * @return void
    public function content_template() { ?>

        <# if ( ! data.choices ) {
        } #>

        <# if ( data.label ) { #>
            <span class="customize-control-title">{{{ data.label }}}</span>
        <# } #>

        <# if ( data.description ) { #>
            <span class="description customize-control-description">{{{ data.description }}}</span>
        <# } #>

        <div class="buttonset">

            <# for ( key in data.choices ) { #>

                <input type="radio" value="{{{ key }}}" name="_customize-{{{ data.type }}}-{{{ data.id }}}" id="{{{ data.id }}}-{{{ key }}}" {{{ data.link }}} <# if ( key === data.value ) { #> checked="checked" <# } #> /> 

                <label for="{{{ data.id }}}-{{{ key }}}">
                    <span class="screen-reader-text">{{{ data.choices[ key ]['label'] }}}</span>
                    <img src="{{{ data.choices[ key ]['url'] }}}" alt="{{{ data.choices[ key ]['label'] }}}" />
            <# } #>

        </div><!-- .buttonset -->
    <?php }

Loading scripts and styles

In the class above, you probably noticed that I enqueued a few scripts and styles. The jQuery UI buttonset() is the primary script that handles replacing the radio inputs with images. It’s included with WP, so we merely need to load it.

We also need a custom JS script to apply the buttonset() to our radio inputs and to handle the customizer setting when it changes. Place the following code in your theme’s /js/customize-controls.js file:

jQuery( document ).ready( function() {

    // Use buttonset() for radio images.
    jQuery( '.customize-control-radio-image .buttonset' ).buttonset();

    // Handles setting the new value in the customizer.
    jQuery( '.customize-control-radio-image input:radio' ).change(
        function() {

            // Get the name of the setting.
            var setting = jQuery( this ).attr( 'data-customize-setting-link' );

            // Get the value of the currently-checked radio input.
            var image = jQuery( this ).val();

            // Set the new value.
            wp.customize( setting, function( obj ) {

                obj.set( image );
            } );

} ); // jQuery( document ).ready

And, we need a little bit of custom CSS to handle styling the control. Place the following code in your theme’s /css/customize-controls.css file.

.customize-control-radio-image .ui-button {
    margin:        0;
    border-radius: 0;
    border:        none;
    background:    transparent;

.customize-control-radio-image .ui-button-text { padding: 0; }

.customize-control-radio-image img {
    box-sizing: border-box;
    max-width:  100%;
    height:     auto;
    padding:    1px;
    border:     4px solid transparent;

    .customize-control-radio-image img:hover,
    .customize-control-radio-image img:focus {
        border-color: #ddd;

    .customize-control-radio-image .ui-state-active img {
        border-color: #00a0d2;

Actually using the radio input control

OK, so you’ve got everything in place now. Awesome. Yeah, there’s a bit of setup, but it’s pretty fun to play around with this thing.

At this point, you just have a final step before doing cool stuff.

The following code is an example of using the custom control to output a layout setting with images that represent the various layouts. Note that you’ll actually need to replace the image URLs in the code with something relevant to your theme.

add_action( 'customize_register', 'jt_customize_register' );

function jt_customize_register( $wp_customize ) {

    // Load the radio image control class.
    require_once( trailingslashit( get_template_directory() ) . 'customize/control-radio-image.php' );

    // Register the radio image control class as a JS control type.
    $wp_customize->register_control_type( 'JT_Customize_Control_Radio_Image' );

    // Add a custom layout section.
    $wp_customize->add_section( 'layout', array( 'title' => esc_html__( 'Layout', 'jt' ) ) );

    // Add the layout setting.
            'default'           => 'content-sidebar',
            'sanitize_callback' => 'sanitize_key',

    // Add the layout control.
        new JT_Customize_Control_Radio_Image(
                'label'    => esc_html__( 'Layout', 'jt' ),
                'section'  => 'layout',
                'choices'  => array(
                    'content-sidebar' => array(
                        'label' => esc_html__( 'Content / Sidebar', 'jt' ),
                        'url'   => '%s/images/content-sidebar.png'
                    'sidebar-content' => array(
                        'label' => esc_html__( 'Sidebar / Content', 'jt' ),
                        'url'   => '%s/images/sidebar-content.png'
                    'content' => array(
                        'label' => esc_html__( 'Content - One Column', 'jt' ),
                        'url'   => '%s/images/content.png'

The post Customizer radio image control appeared first on Justin Tadlock.

Customizer Everywhere – No, Thanks, Here’s Why

When I wrote my post about the voluntarily business decisions last week, I tried to stress on the fact that a minor change may have a big impact, and for some this may be pretty critical.

Now we have a major decision that followed some other major ones, including the theme review requirement that Customizer is a “must” for WordPress themes.


As a side note, an online friend told me last week that I’m very positive. On the contrary, I’m in fact a realist that always evaluates the possible regressions that something may do – because, at the end of the day, I love to help, give back and give credit where credit is due. I despise injustice, political BS and other things that happen due to frivolousness caused by people with power.

Without bringing the same strong level of emotion to the matter in hand, the latest “goodie” is that the Menu Customizer is also to be merged in Core. I love the Core Leads and all active contributors that make WordPress what it is, but it doesn’t mean that I have to support every decision. And I don’t think that this one is a minor one.

As Sarah said on WP Tavern:

My initial impression after testing is that managing menus in the customizer makes me feel claustrophobic. The live previews and the mobile friendliness are the big wins here, but they come at the expense of a squished menu management experience. For sites that use WordPress as a CMS, with dozens and sometimes hundreds of pages and subpages, menu management in the customizer could become rather cumbersome.

There are at least a dozen golden quotes both on Make and on Tavern’s posts, and I welcome you to read them and join the discussion.

The only real use case when I’ve seen the Customizer to be helpful (other than changing the site title or the logo) is Conductor which is a premium plugin by my friend Matt. It’s just useful and makes the management easier. Other than that Customizer isn’t useful to me or our clients, and I have seen too many practical scenarios where options are simply lost.

settings-api-implementationThe fact that the Settings API is terrible doesn’t mean that we need to ignore or bury an API for the sake of moving large components to the Customizer.

Mind you, we had to build a new Menus design a few major versions ago that has two different screens since they didn’t fit on a single one. And now we move them to Customizer.

In case someone reads that as a rant, please go and see the comments on both sites. My Twitter feed is literally filled up with Customizer complaints due to the latest proposal. I don’t really think that everyone around me lives in the same bubble with me named the “tiny little group of people who don’t like Customizer” while we have no access to everyone else who seems to like it.

Since I’m biased, I admit that my great vision for WordPress would be a super stable core, detachable, a framework even (like BackPress) that could be bundled similarly to Drupal’s distributions. I know that it won’t happen, don’t worry. But the further we move from this and the more we try to compete with Tumblr (Post Formats UI) and Squarespace (Menu in Customizer), the harder would it be for us to land large clients without having to spend a crazy amount on updates all the time.

I know how long does it take now for our largest clients to update to a new major version of WordPress and update the plugins as well (not the security updates). It’s a lenghty process that occasionally leads to regressions in specific areas.

And the reason of this post is to explicitly state that this is not a rant, but a vocal expression of a personal opinion based on business experience. I honestly believe that the people behind this idea are not aware of the number of people who don’t support it at all, and the more feedback they receive, the clearer would it be that it’s not the way to go.

I’d even say “let’s revive WordPress Ideas“. Democracy would be insane with the large community that we got, but at least it would be clear when something on the roadmap gets no support at all, or the majority of the people find it to be an incredibly bad idea.

The post Customizer Everywhere – No, Thanks, Here’s Why appeared first on Mario Peshev on WordPress Development.

Menu Customizer Officially Proposed for Merge Into WordPress 4.3

Contributors on the Menu Customizer feature plugin are proposing its inclusion in WordPress 4.3. Nick Halsey posted the Customizer Team’s proposal last night, beginning with a summary of the purpose of moving menu management into the customizer:

In the process, we hope to offer an updated design with improved user flow, a mobile-first interface, improved accessibility, rebuild the administration UI from the ground up to be JavaScript-driven, solve long-standing problems with the current implementation, and clarify the purposes and capabilities of the menus feature. Additionally, Menu Customizer contributes significantly to the long-term goal to move all appearance functionality and, really, everything that could benefit from live previewing, from the admin to the Customizer.

Menu management in the customizer is essentially a full replacement of all the capabilities previously housed in the admin. It allows for editing, reordering, deleting, and adding individual menu items within any menu. The plugin adds a convenient global search that includes all post types, terms, and taxonomies.

The video below was prepared by Halsey’s team to demonstrate the capabilities of the Menu Customizer:

The dizzying speed with which she flips between panels in the demo is not representative of the capabilities of your average WordPress user. Given that the plugin currently requires WordPress 4.3 alpha, it’s not likely that it has not been widely tested by users of varying experience levels.

My initial impression after testing is that managing menus in the customizer makes me feel claustrophobic. The live previews and the mobile friendliness are the big wins here, but they come at the expense of a squished menu management experience. For sites that use WordPress as a CMS, with dozens and sometimes hundreds of pages and subpages, menu management in the customizer could become rather cumbersome.


I have no doubt that the Menu Customizer has been architected to perform better as a JavaScript-driven solution for managing menus. Halsey and the team employed no small amount of wizardry in creating the custom panel for implementing screen options and the sections that lazy load menu items.

But if you put a relatively new WordPress user in front of the customizer menu panel, will it be intuitive to use? Will stuffing menus into the customizer cause the usability of the feature to decline?

Reactions to the proposal in the Advanced WordPress Facebook group were less than enthusiastic, as not many favor expanding the customizer’s reach into menu management.

“I really don’t feel the Customizer is the correct place to manage menus or any content for that matter,” member Tom Hemsley commented. “If a theme offers styling options for a menu then fair enough – put those styling options in the customizer. But the customizer is not the place for managing content. Why not force people to create new posts using the Customizer, too?”

Lisa League’s comment accurately summarizes many others’ initial reactions to the demo video: “My first impression of Make was not ‘Cool, look how they did this with the customizer’ but ‘Whoa, there’s too much stuff in this tiny space.'”

If the Menu Customizer plugin is approved to merge into core, Halsey outlined a plan for the removal of the old menu admin screen in favor of focusing all new development on the UI in the customizer. WordPress 4.3 would point the Menus link in the admin bar to Menus in the customizer and later releases would remove all core links to the Menus admin screen, or point them to the customizer.

“The above plan is fairly aggressive, to eliminate any ambiguity about future plans and intentions and to avoid the potential for mass trac ticket rot,” Halsey said.

WordPress cannot move forward without making changes and taking risks. The question of whether or not to merge the Menu Customizer plugin should inspire some fairly active discussion in the days ahead. If you want to test the plugin for yourself, the easiest way is to install the WordPress Beta Tester plugin to get 4.3-alpha running and then install Menu Customizer from WordPress.org.

Core contributors will discuss the Menu Customizer proposal today during the regularly scheduled development meeting on Slack. According to the WordPress 4.3 project schedule, the feature plugin merge window will close June 17th and the official release is expected in mid-August.