Monthly Archives: July 2018

Facebook Shuts Down API for Publishing to User Timelines, Impacts Jetpack’s Publicize Feature

In the aftermath of the Cambridge Analytica data scandal, Facebook is tightening its control on third-party applications and will no longer allow apps to post to user profiles. In April, the platform announced sweeping changes to the publish_actions permission, which allowed apps to publish to users’ timeline on their behalf.

On August 1st, 2018, the Live API publish_actions permission, which allows an app to publish on behalf of its Users, will be reserved for approved partners. A new permission model that allows apps to publish Videos to their User’s Groups and Timeline will be created instead.

Access to the Pages APIs requires re-submission of the application for review before August 1, 2018. This will be required to continue publishing live and VOD video to Pages, as well as reading insights.

Facebook is notorious for swiftly changing its APIs in ways that break apps (sometimes without warning), often sending developers scrambling. For a long time, apps auto-posting to user timelines was part of the wild west of app permissions granted without much oversight from Facebook. Users often unknowingly gave permission to apps that would collect data and spam their Facebook connections with posts made on their behalf.

Those days are over, but an unfortunate byproduct of this restriction is that apps like and Jetpack’s Publicize feature can no longer automatically publish posts to user timelines. This change also adversely affects apps like Buffer and Hootsuite that allow users to schedule and publish posts to their social accounts.

Jetpack 6.3.3 removes the ability for users to select Facebook Profile connections and displays a notice regarding existing connections, so users will be aware of which auto-posting connections they are losing. Besides Jetpack, this Facebook API change affects tens of thousands of users who have this functionality implemented through one of many other plugins on

Users are now required to manually share their posts to their timelines. They can no longer schedule content to be shared to Facebook at specific times for different audiences.

Auto-posting to Facebook Pages still works, and one option users have is to convert their Profile to a Page or set up a new page. This may not be a suitable alternative for bloggers and those whose writing is not attached to a business or an organization.

In a recent post on his blog, Automattic CEO Matt Mullenweg commented on Facebook’s decision to turn off auto-posting to profiles.

“As it turns out, Facebook also is turning off the ability for WordPress sites — and all websites — to post directly to users’ profile pages,” Mullenweg said. “The decision to shut down the API is ostensibly to fight propaganda and misinformation on the platform, but I think it’s a big step back for their embrace of the open web. I hope they change their minds.”

If only a select few “approved partners” are allowed to automatically broadcast to user timelines, it puts smaller players at a disadvantage, requiring manual sharing each time they publish. Facebook is setting itself up as a gatekeeper that enables news from a small selection of partners to keep pumping through the platform on schedule. Individual voices on smaller websites are no longer able to syndicate to the Facebook platform unless they decide to create a Page.

Put a different way, the only syndicated content allowed on Facebook will be through channels the company can monetize – business/organization Pages or partners who are approved to post to user timelines. Users who care about retaining their Facebook audiences will need to remember to manually post their content to the social network after August 1, 2018, when the API changes go into effect.

Source: WP Tavern

WordPress Coding Standards 1.0.0 Released

After nine years since the project began, version 1.0.0 of the WordPress Coding Standards is available for download. The WordPress Coding Standards is a collection of PHP_CodeSniffer rules or sniffs to validate code developed for WordPress. It ensures code quality and adherence to coding conventions, including the official WordPress Coding Standards.

In addition to being a big milestone, 1.0.0 contains breaking changes. “A number of sniffs have been moved between categories and the old sniff names have been deprecated,” Juliette Reinders Folmer, a significant contributor to the project, said. 

“If you selectively include any of these sniffs in your custom ruleset or set custom property values for these sniffs, your custom ruleset will need to be updated.”

The WordPress-VIP ruleset has been deprecated as well. “This ruleset has not been valid for some time, as we have our own VIP coding standards, available for public use,” David Artiss, a member of the VIP support team, said.

“If you are a VIP client and you are not using the alternative rulesets, then we would strongly recommend switching to these. If you used the WordPress-VIP ruleset for any other reason, you should use WordPress-Extra or WordPress instead.”

Those who use the WordPress Coding Standards Sniffs are strongly encouraged to read the changelog before updating. WordPress Coding Standards is a free, open source project, that’s available on GitHub where contributions are welcomed.

Source: WP Tavern

David Needham Chats about Venturing Outside WordCamp to Visit Other Open Source Communities

While at WordCamp Europe I had the chance to chat with David Needham, a developer advocate at Pantheon, about his session titled “Intro to Drupal for WordPress Folks.” Needham frequently travels between the WordPress and Drupal communities, representing his company as a developer liaison. He has spoken at various Drupal camps and WordCamps and is also one of the organizers for WordCamp US 2018 in Nashville.

During our chat, Needham discussed some of the more notable differences between the WordPress and Drupal communities and how the two can inspire each other in various ways. He encouraged attendees at his session to venture outside of WordCamps and said he hopes to see more collaboration across the platforms in the future. From his unique vantage point, Needham said he doesn’t think CMS rivalries are as big of a deal as they used to be.

“We’re realizing that we’re really not competing,” Needham said. “The internet is a big place and there’s plenty of room for all of our communities to work together – especially since our values are so closely aligned already. If there is a rivalry, it feels a little bit more like a friendly sibling rivalry than anything.”

Source: WP Tavern

WordPress Developers: Learn How to Convert Shortcodes to Gutenberg Blocks

Gutenberg contributor Gary Pendergast has published a handy sample plugin that demonstrates how to convert shortcode functionality to a Gutenberg block.

The first file shows a basic example of how to register a block with JavaScript and add block inspector controls to the sidebar. The second file is the PHP code for the plugin that converts the existing shortcode logic into a block that will work inside the new editor.

“This sample uses the ServerSideRender element,” Pendergast said. “It’s critical to remember that ServerSideRender is a stepping stone to a full block editing experience: having to call back to the server to re-render is a worse UX than native JS rendering. Use ServerSideRender to get your existing functionality ready for WordPress 5.0 now, and plan to phase it out over time.”

With WordPress 4.9.8’s “Try Gutenberg” callout just around the corner, this sample plugin may be helpful for developers who have created custom shortcode plugins for clients. If you’re not sure where to start, Pendergast’s sample plugin makes Gutenberg block creation more approachable. The Gutenberg handbook has more in-depth documentation for developers who want to improve their blocks beyond this basic example.

Source: WP Tavern

Plugin Review: Theme Support for Gutenberg

As Gutenberg nears a merge with WordPress, Theme Authors are running out of time to ensure that their themes are compatible. The Gutenberg handbook has an excellent article on how to opt-in and add support for enhanced features.

Most themes will present the default blocks without any issues as the blocks themselves provide their own styles. If you use a theme that does not fully support Gutenberg such as the Wide or Full Block Alignment options, the Theme Support for Gutenberg plugin may be for you.

Created by Weweaver, Theme Support for Gutenberg claims to allow most WordPress themes to be compatible with Gutenberg. In addition to theme support, the plugin adds a Classic Editor button to the admin bar to easily switch between Gutenberg and the Classic Editor.

Since a default WordPress theme is used to show how this plugin is beneficial, I decided to try it for myself. I installed the plugin on a fresh install of WordPress 4.9.7, Gutenberg 3.3, and the latest version of Twenty Sixteen. I published a Gutenberg Demo post which uses many of the default blocks.

Twenty Sixteen Looks Better Without It

Here is what the Gallery block looks like in Twenty Sixteen with the plugin disabled. The content looks good and fits within the content column.

Theme Support for Gutenberg Disabled

When the plugin is enabled, the images are so large, a horizontal scroll bar appears.

Theme Support for Gutenberg Enabled

The plugin includes additional styling for default blocks. One block that doesn’t benefit from the enhanced styles is the Video block. With the plugin disabled, the video block appears normally.

Video Block With The Plugin Disabled

With the plugin enabled, the video block overflows the content column and breaches into the left sidebar.

Video Block With The Plugin Enabled

Although the plugin initially shipped with no options, version 0.2 includes new settings that provide better compatibility for some themes. I checked the box to disable Fitvids support which solved the video block issue. However, the other options had no effect on the oversized image blocks.

Theme Support Options

Twenty Sixteen and Twenty Seventeen do not work well with this plugin. There may be themes, particularly older ones that benefit, but more modern themes will likely be ok without it.

Source: WP Tavern

WooSesh Virtual WooCommerce Conference to be Held October 18-19

WooSesh, a new two-day virtual conference focused on WooCommerce topics, will be held October 18-19. While wrapping up another successful edition of WordSesh, Brian Richards announced WooSesh as the next event coming under the WordSesh brand. On Wednesday, nearly 500 attendees joined WordSesh. People tuned in from around the world, although the audience was heavily US-based due to the time the event was scheduled.

Since WooConf is not happening this year, WooSesh is an exciting alternative that will be accessible to anyone in the world. Co-organizers Brian Richards and Patrick Rauland will be hosting eight presentations each day, so the event will last between 8-10 hours both days, including breaks and announcements.

“Once we learned that WooConf wouldn’t be taking place this year we reached out to our friends at Automattic to see if we could work with them as well to still provide a high-quality event but for a much more global audience,” Richards said.

WooCommerce is sponsoring the entire event, making it free for all live attendees. Richards said they are working with other prominent companies in the WooCommerce space who are lending their knowledgeable staff as presenters, as well as providing the event with digital swag for attendees.

WooSesh organizers are employing an interesting concept for encouraging attendance and engagement. The conference will have a $200 ticket price for those who do not attend live. Those who register in advance and attend live will receive the $200 ticket for free.

“That means if a person joins the mailing list and shows up for the event, they’ll be able to experience the whole thing at no cost to them,” Richards said. “Similar to WordSesh, a ticket grants attendees access to the entire broadcast, chat, recordings, real-time transcriptions, and some cool digital swag. But with WooSesh they’ll also get some targeted follow-up content, and perhaps a private community, to further help them succeed and increase the impact of this conference.

“And I think it’s in everyone’s best interest to register and attend live – at least trying to make it to one of the sessions across the two days – so they can get all of that for free.”

Richards said recordings may still make it out there for people to view afterwards but none of the other perks and follow-ups will be available without purchasing a ticket or attending live.

“We talked about asking people for a credit card up front and building a mechanism that would either charge them after the fact (like a pre-order) or charge them up-front but then refund them after the fact,” Richards said. “Instead we’re going with the simpler route and asking only for a person’s name and email address up-front. If they come to the live event they’ll be able to access all of the content afterwards just as if they had paid, and if they don’t attend live they’ll instead be greeted with a payment form.”

Building on their collective knowledge of organizing successful in-person and virtual conferences, Richards said he and his co-organizer wanted to reduce the friction as much as possible for people getting into their seats and engaged with the speakers and other attendees.

“Making it a virtual event already knocks down a ton of barriers,” Richard said. “Making the content available for free eliminates even more. Except that, people will often discredit free things and we didn’t want anyone to think of this content as any less valuable or serious than it really is.”

WooSesh organizers plan to host compelling case studies, as well as talks about SEO, security, tips for building different kinds of e-commerce stores, and share advice from others’ hard-earned lessons. The event will also host sessions for developers that delve into WooCommerce architecture, performance, how to build and support custom extensions, and how to expand service offerings to better support e-commerce projects.

“Our biggest goal with WooSesh is that it will help store builders as well as coders to have more impact with what they build,” Richards said. “Specifically, we’d like to see them make some measurable progress in their own goals, whether that’s more sales, better customer experiences, greater depth of knowledge, or otherwise. We’re also hoping that some of these talks will inspire attendees to do more than they originally thought possible – either for their own e-commerce stores or for their customers/clients.”

Source: WP Tavern

Slack Acquires HipChat, Moves Blog from Medium to WordPress

Slack announced today that it has acquired HipChat from Atlassian. The friendly rivalry between the two competing group chat platforms will be laid to rest as Slack plans to retire HipChat and Stride. Atlassian will receive a stake in Slack’s business in exchange for shutting down its chat collaboration services and migrating all of its customers over.

Atlassian acquired HipChat in 2012 with the intention of scaling the business but found a formidable challenge in taking on the well-funded, market-dominating Slack app. As of May 2018, Slack reported 8 million daily active users and 70,000 paid teams. More than half of the app’s users are outside the U.S. and 65% of companies in the Fortune 100 pay to use Slack.

Atlassian and Slack are now joining forces to compete against Microsoft, who jumped into the enterprise collaboration market in 2016 with its Teams product. Teams’ free tier offers support for up to 300 people, with unlimited chat messages and search, and is aimed squarely at competing with Slack.

The news was announced on “Several People Are Typing,” the official Slack blog, which has just moved from Medium to WordPress. It is being hosted on the VIP platform.

The answer to that question, by the way, is ‘yes.’

Source: WP Tavern

How to Create A Gutenberg Block Attributes Glossary

If you want to see what Gutenberg blocks are available on a site along with their attributes, check out the Block Attributes Glossary plugin by NC State’s Office of Information Technology and Design.

Block Attributes Glossary Index

The plugin adds a Glossary Attributes Block to Gutenberg that when added to a post or page, displays an index of blocks that are available. Clicking on a block name will display its attributes.

Atomic Blocks Drop Cap Block Attributes

This is especially useful for creating block templates. Note that if you install plugins that add new blocks, you’ll need to visit the post or page that has the glossary, remove the Glossary block, and re-add it.

You can see a live demo of this plugin in action by visiting NC State’s OIT Block Attributes Glossary. The plugin is not available from the WordPress plugin directory but you can download it for free from the project’s Github page.

Source: WP Tavern

Font Awesome 5.2 Adds 372 New Icons, Introduces Automotive and Education Categories

image credit: Font Awesome

Font Awesome 5.2 was released yesterday with two new categories and 372 new icons, bringing the total number of free icons to 1,295. The open source vector icon font is used on more than 22 million sites across the internet. It’s also a popular icon font with WordPress theme and plugin developers.

Version 5.2 introduces automotive and education categories, which should be useful to fill the gaps for designers and developers creating sites around these subjects. The release also adds 66 new and updated icons to the Medical category and 126 new and updated Maps icons.

Font Awesome, originally created by Dave Gandy, is an SIL OFL-licensed icon font, with the code under the MIT License. Thanks to its GPL-friendly license, the icon font is widely used in WordPress’ theme and plugin ecosystem in both commercial and free products. Font Awesome’s Github issues queue is also loaded with icon requests that would be used in niche WordPress themes, as well as icons for WordPress-related company logos.

Two years ago, Font Awesome announced the beta release of its new CDN, which allows developers to implement it using a single line of code to bring the icons and CSS toolkit into their projects. At that time, Font Awesome was used by more than 300 plugins on In 2018, searching the official plugin directory turns up more than 800 plugins that make use of the icon font in some way. Thousands of free and commercial themes also use it to provide users with easy customization options.

Font Awesome support for Gutenberg is going to be fairly important, as hundreds of thousands of websites are using plugins like Better Font Awesome, Font Awesome Shortcodes, and Font Awesome for Menus to allow users to add icons to content and menus. Currently there are no Gutenberg-compatible plugins for adding Font Awesome icons to content.

Source: WP Tavern

WPWeekly Episode 324 – Getting NC State Gutenready

In this episode, John James Jacoby and I are joined by Jen McFarland, Web Services Coordinator at NC state’s Office of Information and Technology. McFarland describes how the campus is using WordPress, what they’re doing to prepare students and staff for Gutenberg, and what they’ve experienced thus far in the transition.

Near the end of the show, we cover WordPress 4.9.8 RC 1 and provide an update on WP-CLI Hack Day.

Stories Discussed:

Gutenberg 3.3 Released, Adds Archives and Recent Comments Blocks
WordPress 4.9.8 RC 1 Released
WP-CLI Hack Day Is A Success
Google Chrome Rolls Out “Not Secure” Warning for Plain HTTP Sites

WPWeekly Meta:

Next Episode: Wednesday, August 1st 3:00 P.M. Eastern

Subscribe to WordPress Weekly via Itunes

Subscribe to WordPress Weekly via RSS

Subscribe to WordPress Weekly via Stitcher Radio

Subscribe to WordPress Weekly via Google Play

Listen To Episode #324:

Source: WP Tavern

Frontenberg Lets Users Test Gutenberg on the Frontend

WordPress 5.0 will bring the world a brand new editor that is currently code-named Gutenberg. If you have been hearing the buzz around Gutenberg but have yet to try it, Frontenberg ( is the easiest way to check it out.

Frontenberg allows visitors to try Gutenberg without having to set up a separate test site of their own. It loads an instance of WordPress plus the Gutenberg plugin on the frontend so visitors don’t have to log in to play around with the new editor.

Frontenberg has a limited range of capabilities for testing purposes. Users have access to a pre-populated media library but cannot upload images to the test site. It’s also not possible to create shared blocks or save the post. Attempting to save an action will trigger an “updating failed” notice. Apart from those few limitations, Frontenberg allows users to test nearly all of Gutenberg’s features.

The tool was created by Tom Nowell, VIP Wrangler at Automattic. He launched the frontend testing instance on his own website at and the WordPress VIP team built its own version to handle more traffic. Frontenberg contains links to numerous Gutenberg resources, including, which has some free training videos the team created for VIP clients.

Nowell has written a post called How Frontenberg Works for developers who are interested in the tech behind the tool. In it he describes the challenges he encountered in building Frontenberg and the solutions he wrote to make it work.

The “Try Gutenberg” prompt will soon be going out to millions of users in WordPress 4.9.8. Those who conservatively opt to use the Classic Editor plugin can still give Gutenberg a try using the Frontenberg tool or install it on a test site to see how interacts with themes and plugins.

Source: WP Tavern

WordPress Core Fields API Project is Seeking New Leadership

In 2014, Pods lead developer, Scott Kingsley Clark, took over the primary lead role for the Metadata UI project. In 2015, the Metadata UI project was reborn as the Fields API.

The Fields API was developed to allow registering fields to different screens in the admin area through a single API. New meta boxes and fields within them could be added to posts while new sections and fields could be added to the profile screen.

The goal of the API is to integrate with all of the various admin screens including, Posts, Terms, Users, Media, and Comments and provide standardization.

Clark has been leading the project for three years and despite seeing renewed interest last year, announced in the project’s Slack channel that he is stepping down.

It is with a heavy heart that I must pass the torch on this project. After hundreds of hours of my time, I no longer believe I can effect change within WordPress core.

The Fields API vision was too big, too much of an undertaking for any one person. I believe so deeply that WordPress needs a Fields API, but the journey to where we are at with the Fields API has been long and arduous.

The truth is, I burned out years ago while building the first and second prototypes. Not everyone agreed on how to architect the code, it went through many revisions based on core contributor feedback. I just couldn’t get enough people excited about it, I couldn’t get enough companies and people interested in supporting it.

I need to let someone else have their chance, I am dragging it down. If someone steps up to lead in the future, then I would be happy to assist where I am able to. But I am unable to continue leading the Fields API proposal/project. I am sorry, please accept my apology and I hope you can forgive me for failing to take this project over the finish line. I still believe to be such a vital part of WordPress’ future success.

Scott Kingsley Clark

The Trials and Tribulations of Leading an Open Source Project

In the following interview, Clark explains why he feels personally responsible for the project’s lack of progress, why the API is important for WordPress’ future, and reflects on what he could have done differently.

Are you looking to pass the torch on to anyone in particular?

No, I’m not sure who would have the drive and the clout to see the project through. It’s a large scale project that should be approached with a long-term vision but in small enough increments to make it into WordPress core. It’s a lot to ask of somebody, it’s also not a priority for people right now since they are distracted by Gutenberg being released in the near future.

Why is the Fields API a vital part of WordPress’ future?

People look at WordPress today and wonder how they ever survived without the REST API. Well, at least I know I do! The same thing can be said about the Fields API even though it’s not there yet. There are so many cases where it’s frustrating to build solutions for WordPress across all of the different hooks.

For consistency, it’s the wild west out there. You get a meta box registered and you fill it with whatever you want. You need your own CSS to style the form fields and everyone has their own idea of how this interface should look. You are in charge of your own responsive layouts that are mobile-friendly, there’s just so much you have to handle on your own. You should be able to customize appearances, but every place you want to add a field or form to should really have a proper API.

Long-term, imagine registering fields to WordPress like you register post types. Imagine fields and their configurations being available to the REST API and accessible through the WordPress App or other custom apps.

The whole world opens up because you have a consistent API, the whole world make sense because you have a consistent interface for those fields across the various edit screens. Posts, terms, comments, users, media, even the Customizer would all have the same underlying API to add groups, panels, and fields to their screens.

If Gutenberg was done after the Fields API was in, migration for folks wouldn’t have been as difficult. Gutenberg could have automatically shown all of the Fields API interfaces like it does for the meta box backward compatibility. It would have looked so much nicer too.

Taking some time to reflect, what could you have done differently to get more core contributors to buy into the project and turn it into a higher priority?

I’m not sure, it’s a delicate balance of taking input and being confident in the end result. At first, the feedback was about how the API was foreign for WordPress, they asked if it could be similar in structure to other APIs such as the Customizer.

We scrapped the code and rebuilt from the ground up as a fork of the Customizer, it even supported having the Customizer utilizing the Fields API too. At the height of development, we had all areas of the Fields API implemented.

Core releases were moving pretty fast, there was a lot of code changes from WordPress release to release that we had to keep up with because we had essentially created a project that was a giant patch for WordPress.

There weren’t enough hooks in place to do what we needed to do, and many sections were not extensible because of code decisions that marked themselves as ‘final’, which means you can’t extend a specific class to customize how it works.

I wish I could have been at all the big WordCamps in the US and Europe, essentially lobbying for this feature. Gathering supporters and such, it feels like politics in a way. I hung around in Core dev meetings, trying to bring it up. I tried to legitimize the feature by having a dedicated channel in the official WordPress Slack, posting updates on, and holding weekly meetings.

Ultimately, I prioritized my time for development over the time to gather the troops. That was the downfall, I began to burn out quickly after the first few rewrites as I had many other responsibilities elsewhere on top of Fields API.

It’s not like companies will easily want to pay you to work on a project like this indefinitely, even though both WebDevStudios and 10up gave me time to push it forward. It wasn’t a blank check, at some point I had to get back to billable work. From then on, it was all in my free time and that was difficult to manage during times of financial stress and house selling/buying.

There’s demand for a Fields API in core but not enough hands to build it. Why do you think that is?

Everyone is focused elsewhere. There’s a lot of areas of WordPress that need people’s attention. There are things like Accessibility that deserve a lot more attention than it gets. But the focus to me, seems to be on Gutenberg and REST API.

Gutenberg especially has been a huge time sink for people contributing and people implementing. It’s a really large feature. It’s definitely larger in scale than Fields API, it’s like a whole new app that lives in WordPress. Integration with it has required a lot of education and trial/error. People’s focus is where it needs to be right now. It’s just unfortunate that Gutenberg came before Fields API in terms of priority and interest level.

What advice would you give to the next Fields API project leader?

This is a big project, everyone will want to say it should be a certain way. You have to evaluate the options and put forth something bite sized for core to start with. Build upon that, but never lose sight of the long-term goal of integration across all of the WordPress screens. Even the front-end comment forms could thrive with the Fields API.

Why do you feel personally responsible for the project not being a core priority?

At one point, we had momentum. We had at least three to four people who were active. It fell apart because I ran out of time. It’s my shortsightedness, it’s my fault. I spent hundreds of hours developing the project over a couple of years. I should have left myself much more time for organizing the feature proposal text and keeping the fires burning in our contributors’ hearts.

Considering the time and effort you’ve put into the project the last few years, do you feel any sense of relief passing the torch on?

If the torch gets passed or picked up, I will feel a ton better. The main relief is that it’s officially not a weight I have to carry alone any longer. It’s okay to try and fail, it’s still sad though.

I hope that someone or some company steps up and puts time into this. They could even reignite the fire in my own heart that burned itself out. For now, I have one less major to-do item. I still have a hefty plate but it’s no longer as heavy of a burden.

While the immediate future of the project is unclear, those interested in taking it over are encouraged to read posts marked with the Fields API tag on Make.WordPress.Core to learn about its history. You can also check out the project’s Github page.

If you’re interested in taking over the project, you can contact Clark on Twitter, Slack, or through his website.

Source: WP Tavern