During a Q&A session at WordCamp Europe 2020 online, Matt Mullenweg mentioned that Gutenberg contributors were considering dual licensing for embedding Gutenberg in mobile apps, along with the requirement that they would need to get an agreement from all contributors. WordPress mobile engineer Maxime Biais has just published a proposal for discussion, recommending dual licensing the editor under GPL v2.0 and MPL v2.0.

“The GPL v2.0 license is a blocker for distributing the Gutenberg library in proprietary mobile apps,” Biais said in the corresponding GitHub issue. “Currently the only known users of Gutenberg on mobile are the WordPress mobile apps which are under GPL v2.0 (WordPress for Android, WordPress for iOS). Mobile apps under the GPL v2.0 are not common and this limits Gutenberg usage in many apps.

“Rich text editor libraries in the mobile space are lacking. There is no well known open source rich text editor for Android or iOS. We believe that Gutenberg could be a key library for many mobile apps, but that will never happen with the GPL v2.”

Mobile app developers are limited by the GPL, because it requires the entire app to be distributed under the same license. The team is proposing dual licensing under MPL v2.0, a weaker copyleft license that is often considered to be more “business-friendly.” It allows users to combine the software with proprietary code. MPL v2.0 requires the source code for any changes to be available under the MPL, ensuring improvements are shared back to the community. The rest of the app can be distributed under any terms with the MPL v2.0 code included as part of a “larger work.”

“The idea here is to keep some of the WordPress-specific modules under the GPL v2.0 only; some of them are not needed and not relevant for using Gutenberg in another software. Ideally, there would be a different way of bundling the project for being used in WordPress or in a non-GPL software,” Biais said.

The GitHub ticket has several comments from developers who hope to be able to use the editor in their own projects. Radek Pietruszewski, tech lead for a collaborative todo app called Nozbe Teams, has been requesting a relicensing of Gutenberg since October 2019.

“Our tech stack is essentially React on web and React Native on iOS and Android,” Pietruszewski said. “We’re a tiny company, and so we share >80% of app’s codebase between these 3 platforms.

“Our app sorely lacks a WYSIWYG editor. We had a working implementation on web, but we decided to scrap it, because there was no way to port it on iOS and Android. There are pretty much no viable rich text editors for iOS or Android, yet alone both. But even then, shipping three completely separate, but somehow compatible editors would be a vast amount of work.”

When Peitruszewski originally made his case to the mobile team, he identified Gutenberg/Aztec as a basic infrastructure that has the potential to enable many different apps:

And that infrastructure is sorely lacking. There are very few rich text editor libraries on both iOS and Android — and most of them suck. And if you want an editor that has a shared API for both platforms… you’re stuck. There are no options – Gutenberg is the only game in town (and it’s really good).

And it’s very hard to create this infrastructure. WYSIWYG editors are very hard, and it takes entire teams years to develop them (and they still usually suck). Almost no-one has the resources to develop it just for themselves, and if they do, they’re unwilling to open-source it.

Automattic’s mobile app engineers have struggled to get regular contributions to the apps, despite them being open source. Dual licensing Gutenberg could open up a new world of contributors with the editor being used more widely across the industry.

“While we might not be big enough to be able to tackle a challenge of developing a rich text editor from scratch, we’re big enough to contribute features and bug fixes to open source projects,” Pietruszewski said.

Matt Mullenweg was the first comment on Biais’ post in favor of the change:

I think Gutenberg has a chance to become a cross-CMS standard, giving users a familiar interface any place they currently have a rich text box. There are hundreds and hundreds of engineers at other companies solving similar problems in a proprietary way, it would be amazing to get them working together but a huge barrier now is supporting Gutenberg in mobile apps, which every modern web service or CMS has. (Hypothetically, think of Mailchimp as a possible consumer and collaborator here, but it could be any company, SaaS, or other open source CMS.)

Unless any major blockers come up in further discussion, this dual licensing change appears to be on track to move forward. Biais noted that a similar license change has already happened on Aztec-Android and Aztec-iOS. The last hurdle is gaining the approval of all the original code contributors or rewriting the code for those who decline to give approval.

Once Gutenberg can be used under the MPL v2.0, the editor will gain a broader reach, with people already on deck wanting to use it. Other companies and projects that are normally outside WordPress’ open source orbit will also have the opportunity to enrich Gutenberg’s ecosystem with contributions back to the project. At the same time, the MPL 2.0 protects Gutenberg from companies that would try to re-release the code as a closed-source project.

In August, GitHub announced that it would change the “master” branch name for all new repositories created on the platform to “main” starting October 1. The date is less than two weeks away, and WordPress developers need to be prepared for the change if they use the service for version control or project management.

The larger tech and web development community began conversations through various venues in June, a time in which the Black Lives Matter was gaining more traction in the U.S. and worldwide. The discussion centered on removing any terminology that could be discriminatory or oppressive to specific groups of people. This ongoing discussion has shown that there is a deep division over whether such changes are necessary or even helpful.

The WordPress community is dealing with this division itself. Aaron Jorbin proposed a change at the same time to rename the default branch name on WordPress-owned repositories. Through discussion on his post and elsewhere, the community landed on “trunk,” which keeps WordPress projects in line with its SVN roots.

“To close the circle on this, a decision was made in June and earlier today (August 19),” wrote Helen Hou-Sandí, a lead WordPress developer, in the comments of the original proposal. “I updated the default branch name for new GitHub repositories under the WordPress organization to be trunk after GitHub enabled early access to that feature.”

As evidenced by the comments on the Tavern’s coverage of the proposal and those on the original post, the WordPress development community as a whole did not support this decision.

Jorbin has updated several of WordPress’s repositories and switched them to use trunk instead of master. However, there are still some lingering projects yet to be updated, including the primary WordPress and WordPress Develop repositories. He left a comment with an updated list in June. There is no public word on whether the existing, leftover projects will be changed.

WordPress Developer Preparations

Customizing the default branch for a user’s GitHub repositories.

GitHub is merely changing the default branch name for new repositories starting on October 1. This change does not affect existing repositories. Individual users, organization owners, and enterprise administrators can customize the default branch via their account settings now before the switch is made. Owners can also change the default branch name for individual repositories.

The biggest thing that developers need to watch out for is their tooling or other integrations that might still require the master branch. There may be cases where an alternative default branch name will break workflows. If planning to use a different branch name, the best thing to do right now is to spin up the tools you use on a test repository. If something breaks, check to see whether the particular tool you are using will be getting an update. In most cases, this should not be a problem because customized default branch names will be an industry standard.

The great thing about how GitHub is rolling out this feature is that it offers a choice. Those who believe that “master” is oppressive can change the branch name to something they feel is more inclusive. For those who believe otherwise, they can keep their master branch. But, everyone can use the branch name they prefer.

For existing repositories, GitHub is asking that developers be patient for now. The company is investing in tools to make this a seamless experience later this year. There are a few technical hurdles to clear first.

Developers should read the full GitHub guide on setting the default branch for more information.

Over the past two weeks, Matt Mullenweg and Jamstack community leaders have forged a new rivalry, after Mullenweg told The New Stack that he sees Jamstack as “a regression for the vast majority of the people adopting it.”

“The usability and functionality is actually lower,” Mullenweg said to Richard MacManus in an email. “Even rebuilding sites in Jamstack harkens back to the Movable Type days, where the bigger your site gets the slower it is to rebuild or update templates.”

Mullenweg also described a “fragile” chain of services required to run Jamstack sites.

“You can patch together a dozen services, each with its own account and billing, for hundreds of dollars a month, to get a similar result you’d have for a few dollars a month using WordPress on shared hosting,” he said. “And it would be more fragile, because the chain is only as strong as its weakest link. You are chaining together different toolsets, logins, billing, hosting… any part of it going down can break the entire flow.”

Mullenweg has since further clarified his comments while also doubling down on his original premise, saying that “there isn’t a vast number of people adopting Jamstack in the first place, and those who do are probably fully aware of the tradeoffs.” He outlined how he sees WordPress providing a better experience for users in terms of performance, security, scaling, and developer experience. 

Mullenweg’s provocative remarks set off a chain of open letters from the CEO’s of Jamstack-related services. They are convinced that the LAMP stack is on its way out and that Jamstack is on the precipice of replacing its incumbent as the most dominant architecture of the web.

Ohad Eder-Pressman, co-founder and CEO of Stackbit, was the first to fire back. He believes that Jamstack is a “disruptive innovation” that may appear to be inferior now because it is still relatively low level and new when compared to a 17-year old product like WordPress.

“We should be asking whether Jamstack is a better architecture than LAMP and what gaps currently exist with products and solutions built on top of the Jamstack,” Eder-Pressman said. He agreed that Jamstack tools are still largely focused on developers but makes a bold prediction on the stack’s future reach:

The achievements of WordPress in terms of market share and how it democratized early web publishing are amazing. When it comes to architecture I think it was best in class for the early 2000s but it’s time to move forward. We already see cohorts of websites where Jamstack adoption crosses 20% – it’s no longer a question of if the Jamstack becomes the predominant architecture for the web but a question of when. The cliche is a cliche but it also rings true – First, they ignore you, then they laugh at you (we are here), then you win.

Eder-Pressman agreed with Mullenweg regarding Jamstack’s lower usability and functionality but touted the architecture as “infinitely more resilient” due to being hosted on a CDN. He admitted that rebuilding larger sites can be slow but cited developments like build parallelization, build cache, partial rebuild, and incremental static regeneration as optimizations as efforts the Jamstack ecosystem is exploring to solve this known issue.

Netlify CEO Mathias Biilmann, who originally coined the term “Jamstack,” goes so far as to hail “the end of the WordPress era” in his article refuting Mullenweg’s remarks.

“There’s often a moment right around the time when an old technology is about to be displaced by the next thing, where the main leader in the field goes out and makes a strong argument that absolutely nothing is happening,” Biilmann said. “A moment that ends up looking like a turning point where the new was undeniably present enough to be worth being in denial about.”

The Bet: By September 2025, what will be the predominant architecture for the web?

In a brief exchange on Twitter, Mullenweg and Eder-Pressman made a wager for five years into the future, to see if Eder-Pressman’s prediction will hold up, as measured by the Alexa top 10k. In order for Jamstack to become the predominant architecture for the web, it will need to surpass WordPress’ numbers, which are currently hovering at 39.75% (via BuiltWith) and 38.4% (via w3techs).

“I’m happy to make a long bet: 1 year, 5 years, 10 years,” Mullenweg said in another thread in response to Netlify’s CEO. “We’re building and rebuilding WordPress to be generational. We’ve navigated and created bigger architectural shifts in the past, and will do so in the future.”

“I’m a developer, founder, and investor in the space of web technologies – if I’m not willing to engage in a public discussion and share my predictions for where the web is heading then what merit does my work have?” Eder-Pressman said when I asked him why he was willing to make this public wager.

“I felt compelled given Mullenweg’s comments and what I believe is the lack of appreciation for how much adoption and momentum Jamstack technologies already have. If anything I would say that my bet is actually pretty cautious.”

Eder-Pressman and his team at Stackbit are working on a tool to track Jamstack adoption across the web, as BuiltWith does not yet have a Jamstack stat panel that correctly aggregates all the technologies associated with this relatively new category of websites.

“We’ve built an internal tool that tracks adoption of Jamstack technologies across different cohorts of websites which we find informative,” he said. “This isn’t unlike what say Builtwith provides except that we track a few technologies that they don’t and we bundle this into a Jamstack adoption indicator. We’ve used this internally up until now and are planning to release some public facing version of it later this year.”

As the CEO of Stackbit, a service that cranks out Jamstack sites in 60 seconds while bypassing any requirement to use the command line or download npm packages, Eder-Pressman is actively engaged in trying to bring this technology stack to the masses. The company aims to solve the very problems that Mullenweg identified in his critical comments, as is evident in the marketing copy on the Stackbit website. It acknowledges that piecing together a Jamstack website can be challenging even for developers:

“In a fragmented Jamstack environment, developers struggle to glue products together when trying out the latest tech. Stackbit connects the best tools on the market, and helps them play together.”

A year ago, Stackbit caught my attention and I contacted them to find out when WordPress would land among their list of CMS import options. At that time they said they were considering WordPress as a headless CMS option but did not have it on the immediate roadmap. One year later, Stackbit is no closer to building import capabilities for the most popular CMS on the web.

“It’s on the horizon but its not something we’ve prioritized,” Eder-Pressman said. “WordPress is a full blown monolithic CMS. It has been used before as a headless CMS but there are better headless CMS choices out there. Even Mullenweg agrees it’s a complicated premise.”

When asked if his recent conversations have changed the company’s plans to support WordPress imports, he said, “No, it doesn’t make us want to do this any more or less. I really enjoyed the conversation and am glad that Mullenweg recognizes the rise of the Jamstack so much so that he found it necessary to take aim at it. We as a company are driven by the market, user demand, growth opportunities and a healthy vision for the future of the web.”

Jamstack will need to make itself accessible to the wide world of non-technical website owners if its advocates hope to capture any meaningful segment of the Alexa top 10k marketshare. Stackbit, for one, is still grossly underestimating WordPress’ ability to sustain its phenomenal growth, and doesn’t see the necessity for creating a simple path to convert WordPress users. Eder-Pressman believes that making Jamstack accessible starts with developers.

“The Jamstack is an architecture which is winning the minds of developers around the world and across the web development stack,” he said. “Adoption for new architectures often begins with developers so I’m excited to see a company like say Netlify boast over 1 million developers on its Jamstack platform.”

Eder-Pressman’s tool for measuring Jamstack adoption will need to produce some compelling data on the stack’s growth, if his bet is going to materialize. While nearly every offering in the Jamstack ecosystem still falls squarely within the realm of experienced developers, it doesn’t seem likely that five years is enough time for it to overtake WordPress as the predominant architecture for the web. WordPress hasn’t achieved its dominance by prioritizing developer happiness over usability.

Looking at the numbers five years from now, will we see Jamstack overtake WordPress as the most popular way to build a website? Will Jamstack grow with developer usage and then plateau once it fails to reach regular people who don’t have a git-based workflow at the top of their wishlists? Are we going to find Jamstack and WordPress neck and neck in the battle for the predominant architecture for the web? Those who work with a hybrid of both technologies see no need for this kind of rivalry.

Shifting the conversation towards collaboration: “Jamstack can be an opportunity for our industry, rather than a threat.”

“Reading Mullenweg’s comments and the responses from CEOs in the Jamstack community make me feel caught in the middle and a bit frustrated,” Shifter COO Daniel Olson said. “I see friction between two communities that have so much in common.”

Olson has been a proponent of using Jamstack with WordPress for the past four years since launching Shifter, a static site generator and hosting company that supports headless WordPress sites on the Jamstack.

“If you look for the most secure, cost-effective way to build and host a high-traffic website today, the cross-section you’ll arrive at is the Jamstack. Looking at how it offers each of those benefits, you will find inspiration and ways WordPress could do the same,” Olson said. “Rather than write something off wholesale, see what you can learn and apply it.”

Olson said his mission is to bridge the gaps between WordPress and the benefits Jamstack offers, while working through its early days and messy parts, innovating on the tools that work.

“We should be working together to address specific challenges and worry less about how we get there,” Olson said. “Some technologies are indeed a better fit for solving each of those challenges but you don’t need to leave one ecosystem for the other to do it. You can share knowledge and best practices and discover what’s possible. There’s a good chance you’ll end up creating something new, which is part of that innovation we need in our communities.”

Jamstack hosting services for WordPress are eager to remind users that they don’t have to go all in on the technology. You can have your JAM and spread it on top of WordPress, accommodating developers’ love for experimenting with new frontend technologies, while preserving the dynamic publishing power that has been refined over the past 17 years. These hybrid hosting companies aim to enable this without leaving users behind.

“Matt is absolutely right that the usability and functionality of the Jamstack is lower,” Strattic co-founder and CEO Miriam Schwab said. “The Jamstack is a great example of technology that is incredibly appealing to developers, but the actual end users – writers, marketers, business owners – cannot use it. I’ve heard many stories of major companies that have come to the decision to adopt Jamstack for all web development as a company-wide policy, only to find that their marketing team has gone rogue and is installing WordPress sites in order to get their job done.

“The reason for this is like Matt said: every Jamstack site is a compilation of layers of services, and each layer has dozens of options available: you need a static site generator, a CMS, static hosting, and a CDN – and you need to tie it all together with version control. This is all cool and shiny, and the output is truly fantastic because when you have a site that’s a collection of pre-rendered static files served up through a CDN it’s fast, secure, scalable and stable. But then along comes marketing and they want to set up a landing page and they are totally dependent on their dev team and can’t move forward without them. That defeats the purpose of a CMS-driven website! With WP, you get all the layers in one platform…but you don’t get the awesome output.”

Schwab said she sees WordPress having its age work both for it and against it, but ultimately she believes in enabling real world users to manage their own websites without having to rely on developers.

“I’ve seen many companies abandon WP for the shiny new stack, and then come back to it,” Schwab said. “Github is a good example of this – yes Github, the modern repository of cutting-edge code moved their blog off of WordPress, and then came back because it truly is the best tool for just getting your content out there. There aren’t a zillion steps and integrations – you write content, click Publish, and that’s it. It gets the job done, and the fanciest tools will never beat something that just gets the job done.”

At the same time, WordPress needs to be open to enabling diverse frontend implementations, if it wants to remain relevant for the next decade. “WP is running on legacy architecture,” Schwab said. “It’s showing its age, and it’s not appealing to new generations of developers. We need to keep WordPress appealing and interesting to developers in order to secure its future for years to come. If we don’t make developers excited, we will inevitably see a decline.” She encourages the WordPress community to embrace Jamstack as “a breath of fresh air.”

“Jamstack can be an opportunity for our industry, rather than a threat,” Schwab said. “There are ways for the two industries to collaborate, like in the case of headless WP deployments using Gatsby.”

Unlike many other Jamstack service companies, the team behind Gatsby has more readily embraced WordPress as a data source and a critical component of its continued success. The company hired Jason Bahl, creator of the GraphQL for WordPress project, to work on WPGraphQL (and its immediate ecosystem) full-time, while providing a bridge to the WordPress world.

“Maybe I’m getting caught up in semantics, but the JAM in JAMStack means JavaScript, APIs and Markup,” Bahl said. “It wasn’t long ago when Matt prescribed the WordPress ecosystem to ‘Learn JavaScript Deeply,’ and not long after that when a Jamstack application called Gutenberg was merged into WordPress core, along with React. Gutenberg is the JavaScript, the WP REST API is the API and the end result is markup. Jamstack isn’t a regression, it’s a future that Automattic is helping drive WordPress toward.”

When Mullenweg says he is ready to build and rebuild WordPress to be generational, it’s a promise he has already delivered on by introducing the React-based Gutenberg editor two years ago, successfully pushing past an enormous amount of resistance from the developer community.

Bahl said he sees this continued legacy of improvement happening over and over again in various ways, made possible by WordPress’ pluggable system:

WordPress ships with a lot of APIs, but often they are replaced with something newer and better. For example, it’s common for sites to offload images to a CDN instead of use the built-in file system for media. Or instead of using built-in WordPress MySQL search, users will reach for ElasticSearch, Algolia or Solr. In the case of WordPress and the JAMStack, reaching for Next, Gatsby or Gridsome to replace the built-in Theme API isn’t a regression, it’s using newer technology to handle things that built-in parts of WordPress might not do as well. The Theme API of WordPress is just one API and replacing it with technology that does the job better isn’t a regression.

Gatsby’s build step, which has received negative attention in the news recently, is one example of what Bahl thinks Mullenweg was referring to as a regression for users. Bahl is working with Gatsby to reduce the friction associated with decoupled architectures when using WordPress as the API in Jamstack.

“I don’t see Jamstack competing against WordPress,” Bahl said. “In my mind, Jamstack with WordPress as the API is the future of the web. WordPress is the best CMS. Gatsby specifically is trying to embrace this. This isn’t a zero sum game. If the Gatsby + WordPress experience can allow users to use the best CMS in the world while using modern dev tooling, it’s a win all around.”

Two weeks ago, Matt Mullenweg made some pointed remarks in an article from The New Stack, calling Jamstack “a regression for the vast majority of the people adopting it.” In preparation for an upcoming article that will include comments from leaders across both the WordPress and Jamstack communities, I asked Mullenweg if he stands by his remarks characterizing Jamstack as a regression. His response was lengthy and is printed here in its entirety to preserve cohesion.

Q: Do you stand by your remarks that Jamstack is a regression for the vast majority of the people adopting it?

Answer:

“Vast majority of people adopting it” was probably too harsh, because there isn’t a vast number of people adopting Jamstack in the first place, and those who do are probably fully aware of the tradeoffs. There are some good reasons, for certain situations, to decouple and add complexity to your architecture, and WordPress’ REST API works fantastically as a backend there. But I worry they are over-selling the promise of what’s really an architectural decision. If you look at the benefits they purport, it’s better performance, security, scaling, and developer experience:

Better Performance: You can achieve the same performance by putting a great CDN like Cloudflare on top of WordPress, and your life will be infinitely easier when you want to add dynamic features like a store or comments. You can also easily find a static WordPress host like Strattic or Shifter.

Higher security: I don’t believe that introducing a number of proprietary and sub-scale SaaS services like Netlify into your stack will make your site more secure. I believe the most secure thing you can do is run fully open source code, as widely vetted and used as possible, on servers you control, or from the fewest number of vendors possible. WordPress securely runs some of the most attacked websites on the internet, including major media, Facebook, and WhiteHouse.gov. Having this many moving parts doesn’t inspire confidence:

Cheaper, easier scaling: CDNs are more expensive than normal hosting accounts, and you can get WordPress running on a decent host for less than $5/mo. And there are even more powerful offerings: The personal plan on WP.com can serve tens of millions of visitors per day, to the website or the headless API, includes a global CDN, and a domain name for $4/mo, and we still have a profit margin. GraphCMS starts at $29/mo and only gives you “5,000 entities,” whatever that means. Contentstack is $3,500/mo. And that’s just for the headless CMS part! You still need to sign up and pay for a bunch of the other stuff in that graphic before you have a website a human can visit in a browser.

Better developer experience: If your developer wants to copy and paste updates from marketing to the website, sure, but if they want people to be able to update the website without their help, they should go with something easier for users like WordPress. If you’re curious about the developer experience, or an investor thinking about this space, I really suggest you watch this three hour and thirty minute tutorial to really understand what is being sold under the premise of “better”:

Have I ever built stuff like that? Totally! It can be a ton of fun, like building a rocket at home or fixing up an old car. I’ve seen some awesome sites built on decoupled architectures or static publishing, using headless WordPress rather than the CMS’s above, but still a similar idea. People are trying to paint me as being against Jamstack, but that is as foreign to me as being against duct tape — it’s good for some things, bad for others, and it’s not going away. I just wish they would be more intellectually rigorous and honest when marketing it. I expect a Jamstack-like approach to exist forever, just like the ideas behind Jamstack pre-date it getting jammed down our throats by Netlify’s marketing team.

Biilmann has got the Ballmer / iPhone story backwards — Microsoft’s mistake there was they made something too complicated, and the iPhone simplified it. Jamstack introduces numerous vendors, build steps, network calls, interfaces, even billing relationships for something that’s a single button press in WordPress.

The reason services like WordPress.com and Shopify are growing so much is they are taking things that were complicated and making them simpler and accessible to a much wider audience. My mission is to democratize publishing and commerce, to make it radically accessible to everyone regardless of technical or economic ability, and increase the freedom and openness on the internet. As I said on Twitter, the first 15 years of WordPress were just the first few chapters. I’m looking forward to building and rebuilding the platform the rest of my lifetime, and when that comes to an end I hope future generations will carry the torch.

Adjusting padding on a Group block.

When Gutenberg 9.0 landed earlier this week, it came with an experimental padding control for the Group block. Most users will not see it unless their theme has opted into supporting the feature using the experimental-custom-spacing flag.

This was not the first that we have seen of the padding option on a block. Gutenberg 8.3 introduced it for the Cover block. Since then, nothing has changed with the implementation.

The problem with the custom spacing/padding option is that it creates an inline style that does not adjust based on the design of the theme. Fortunately, the feature is still experimental. This means that we have time to reevaluate how it works.

Unless we’re doing away with any remaining illusion that themes will play an important aspect of WordPress’s future and front-end design becomes fully entrenched within core, theme authors need some level of control. And, even if themes are going the way of the dinosaur, custom padding numbers on the block level will create design consistency issues down the road. Using 100 pixels of padding might make sense within a site’s current design, but 96 pixels might make sense within a future design. When a user adds dozens or hundreds of blocks with custom padding today, it will wreak havoc on tomorrow’s spacing and rhythm.

Besides that, the average user has little concept of design rules. Having a standardized system for spacing would give theme authors control over the output while giving end-users the ability to customize the look.

I have argued that WordPress needs some sort of design framework. For example, Tailwind CSS has specific padding classes. So does Bootstrap and nearly every other CSS framework. The web development community has been down this road. It is a well-trodden path, and WordPress is not innovating by using inline styles.

If the WordPress platform is going to put this sort of power into the hands of its users, it should do so in a way that allows designers to do their thing and not push users toward semi-permanent, inline-style soup in their content.

Pre-Gutenberg, I would have been entirely against the idea of WordPress introducing any sort of CSS or design framework. However, the platform is consistently moving toward becoming a UI-based design tool rather than simply a way to manage content. Users will have design-related options on a global scale all the way down to individual blocks. Users should absolutely have the ability to adjust a block’s padding in such a system. They should not need an understanding of CSS to do so. Instead, for most use cases, users should be able to adjust padding based on whether they want larger or smaller spacing, not specific CSS values.

I propose a full set of standardized padding classes. The same would go for margins or other design-related options down the road. Gutenberg/WordPress should create a set of default values for these classes, which theme authors could override based on their design.

This is not a new concept. Dave Smith, a developer for Automattic, introduced a patch in 2019 that used named selectors for spacing on the Group block. He gave the following reasoning for choosing this approach over absolute values:

Imagine you are a Theme designer. You craft your CSS with spacing that is perfect for the design. You want to ensure that is consistent throughout your Theme, even if the page layout is being created by the end-user in the Block Editor.

With the approach I’ve taken here, when a size is selected only classes are added to the Block in the DOM. This affords the Theme creator the opportunity to provide custom sizes in CSS that are suitable for their Theme. If they opt not to do this then sensible defaults are provided.

With the pixels approach, we’re locking users of the Block into absolute values and asking them to make a lot of decisions that they’d probably prefer not to have to make. It could also lead to an inconsistent visual experience.

This ship has already sailed and sunk with custom colors and font sizes. Gutenberg had an opportunity to standardize class names for these options but left it to theme authors. As a result, there is no standard across the theme market, which means that choosing the “large” font size or the “blue” text color provided by the theme will likely not carry across to the user’s next theme. Now, we are on the cusp of far more design-related options as WordPress moves toward full-site editing. It is time to consider some standards on design-related class names and provide a framework that all themes can use.

Gutenberg could still provide a custom padding option just like it does for colors and font sizes. Users who choose to go this route would be making an explicit choice to work outside of the standard. But, let’s not go down this road of allowing users to set absolute spacing values as the default option.

On September 14, GoDaddy announced it had acquired SkyVerge, a major WooCommerce-focused development company, for an undisclosed amount. At the moment, GoDaddy is playing it close to the vest in terms of its future plans. It has not publicly announced anything beyond a continued commitment to current customers.

The initial announcement makes note that SkyVerge’s free plugins on WordPress.org have been downloaded more than 3.1 million times. However, the company’s nine plugins in the directory currently have over 155,000 active installs. Nevertheless, SkyVerge’s real value is in its team and its impressive array of free and commercial add-on plugins available directly from its site.

WooCommerce is a cash cow for companies with the right products and marketing at the moment. GoDaddy seems to be going all-in on the back of WordPress’s most popular eCommerce solution. It launched a managed WooCommerce hosting plan in October 2019. The hosting company has now added over 60 WooCommerce extensions to its inventory in one swoop.

“As more small businesses and entrepreneurs go online, having a highly performant eCommerce experience is becoming more important than ever,” said Rich Tabor, Senior Product Manager of WordPress Experience at GoDaddy. “Late last year we launched a Managed WooCommerce offering, bundling many WooCommerce extensions in the Managed WordPress environment.”

SkyVerge has quietly become a massively successful WordPress and WooCommerce business. It was bringing in $350,000 per month at the end of 2019. There was no response on how well the business has performed thus far in 2020.

The entire SkyVerge team came along for the transition to GoDaddy. “We’re just beginning to deliver more capabilities and an even better setup and ongoing usage experience for our customers,” said Tabor. “The SkyVerge team will lead and accelerate those plans. They are an incredibly talented and innovative team that lives and breathes WooCommerce. Joining forces with them advances GoDaddy’s WordPress strategy and enhances our ability to deliver intuitive eCommerce experiences that help everyday entrepreneurs sell online.”

With so many extensions in place, the big question for average users is whether those extensions will become a part of GoDaddy’s eCommerce hosting bundle. Tabor either did not or could not let slip any plans in the works. “We’re just beginning to determine how to best deliver SkyVerge’s wonderful products to GoDaddy customers. SkyVerge brings a lot of great software. It’s reasonable to expect we’ll be delivering that to our customers who are selling online.”

It is doubtful that GoDaddy went into this acquisition without at least some short-term plans or visions for how its managed hosting service would use these extensions. For now, we will have to wait and see.

It seems that the immediate plan will be to maintain business as usual. Tabor said GoDaddy had no changes to announce related to SkyVerge’s products and website. “We are committed to continuing support of SkyVerge’s customers and investing in the SkyVerge software,” he said.

SkyVerge also created Jilt, which is an email marketing platform for eCommerce sites. The platform currently supports WooCommerce, Easy Digital Downloads, Shopify, and Shopify Plus. Tabor did not directly respond to what the future looked like for Jilt’s non-WooCommerce customers nor did he give any indication of whether there were plans to expand Jilt to other eCommerce systems.

He did say that GoDaddy would continue to invest in its priority eCommerce platforms, which are WooCommerce and GoDaddy Websites + Marketing.

Max Rice, co-founder of SkyVerge, did leave some indication of Jilt’s future in his announcement post. “We made a commitment to be there for your business with software you can depend on, and we’re sticking to it,” he said. “We’ll continue to support our existing WooCommerce plugins and Jilt. While we’ll be building something new at GoDaddy, everything we’ve already built is a big part of that.”

If you haven’t played around with Gutenberg’s experiments lately, the Navigation block is getting some exciting updates. Version 9.0 was released today with drag-and-drop support added to the list view of navigation items.

Contributors have been working through several different prototypes aimed at unifying the controls and simplifying the menu building process. The Navigation screen included in version 9.0 has been redesigned to improve the “Create Menu” flow and includes the following changes:

• New Header and Toolbar components.
• Manage Locations has been rewritten and is now a popover.
• Add New form has been rewritten and now appears inline in the toolbar.
• Automatically Add Pages checkbox and Delete menu button has been rewritten and now appears in the block inspector.

The screen is starting to take shape but is still very much a work in progress. If you want to test it, you can enable it under Gutenberg > Experiments.

The Query block was another main focus fr the 9.0 release. It is taking a giant leap forward with new features like search, filtering by author, support for order/order by (date + title), and tags. This block should be tested locally and is still behind the __experimentalEnableFullSiteEditing flag since it requires full site editing blocks to display queried content.

Other notable UI enhancements include a new drag handle added to block toolbar for drag-and-drop capability. (It is not visible on the top toolbar). Blocks can be dragged to other areas of a post as an alternative to using the up/down arrows.

This release also removes the Facebook and Instagram blocks from the inserter, as Facebook will be dropping unauthenticated oEmbed support on October 24. WordPress core is also set to remove Facebook and Instagram as an oEmbed provider in an upcoming release.

For a full list of all the enhancements, bug fixes, experiments, and documentation updates, check out the 9.0 release post on WordPress.org.

Članak je takođe dostupan na sprskom jeziku.

Everyone’s story is unique. Our life journeys differ in so many aspects and these experiences shape us into who we are now. Therefore, things that we, as individuals, learn along the way can’t always apply to someone else’s life goals, potentials, aspirations, and struggles.

But, sometimes, knowing about other people’s mistakes and successes can help us navigate through our life challenges better. We can avoid making the same mistakes and, even better, we can get inspired to accomplish similar achievements.

That is why I decided to share a few things that I have learned by trying to become a freelancer. Spoiler alert – I’m a corporate employee now.

My career path was a bit unusual. I wasn’t quite tech-savvy until 5 years ago and my entire focus was around the fitness industry from 2006 until 2015. Being a fitness trainer was a dream job for me when I was 26 but, by the age of 35, it became somehow, well, boring.

Then I had a huge epiphany – numerous opportunities come with WordPress and freelancing was one of them. So, if you are at the stage of your life when becoming a freelancer seems like a good idea, read on.

I will try to break down 5 things that helped me in starting my freelance career. They are formulated as general tips for beginners but some of them can also be applied when changing the course of your career. So, let’s dive right in.

Question your motives

The first and the most important thing that you should ask yourself before you do anything in your life is why. “Why am I doing this?”

So, why do you want to become a freelancer?

Is it because you need an extra income? Or maybe because of flexible working hours. Or because you will be able to work from different locations? Or you see freelancing as just a phase before you get enough experience to open your agency and have others working for you.

Be honest with yourself. List all the reasons why you want to become a freelancer. This will help you later on in choosing the right jobs or maybe in considering some other alternatives to freelancing.

For example, these are my top 3 motives to become a freelancer:

• Opportunity to grow intellectually and learn new things
• Flexible working hours (by not being forced to work 9 am to 5 pm every day, I was able to avoid the boring routine)
• Peaceful and quiet working environment – quite opposite to the gym where everything is so loud

So, after you question your goals and motives, and you are certain that you want to become a freelancer what’s next? My suggestion is – develop WordPress related skills.

Get the skills – choose WordPress

Why WordPress you might ask? Well, for a start, WordPress gives various opportunities and it is not a developer-only niche.

Although, when someone thinks of freelancing and WordPress, web developer and web designer are first associations, there is a huge variety of WordPress related freelance jobs:

• Web developer (coding websites, themes, and plugins)
• Web implementor (creating websites from existing themes without coding)
• Web designer (designing website mockups, editing images or creating infographics for websites)
• Client support professional (helping people with their websites)
• Website maintenance professional (takes care of the website to make sure that WordPress, themes, and plugins are up to date and new backups are created regularly)
• WordPress teacher (teaching clients how to use WordPress or teaching other web professionals)
• Content writer
• Accessibility specialist (making sure that certain standards are met and suggesting solutions for accessibility barriers)
• SEO consultant
• Statistics consultant (especially for webshops)
• WordPress assistant (adding new content and editing existing posts)
• Website migration specialist (moving websites from one server to another)
• Web security specialist

Another reason why WordPress is great for freelancers is a strong community that exists around this CMS. There are regular meetups, WordCamps, and other events (they are now switched to online), where you can get a ton of useful information, and also get to ask like-minded people literally anything. The community is so large and diverse, that you will definitely find the answer to any question. It’s much easier to start your freelance career when you have such a great community around you.

Plan in advance

Now that you know where the opportunity lies, you can start planning your career.

Becoming a freelancer is a process. At the beginning of that process, you should acquire or improve relevant skills that will make you stand out in the freelance market. And, of course, as you learn and grow, you will be able to take more challenging and better-paid jobs.

Which skill should you focus on? If you already have a basic skill set for at least one of the previously listed jobs, you can improve your knowledge in that direction and specialize in that area.

However, if you don’t have any relevant skills, in my opinion, it would be the easiest to step into the freelancing world with a job that has a shorter learning curve and build your knowledge around that. Example – you can start with either content writing or as a web implementer since these jobs have a shorter learning curve than SEO related jobs or web development. Then, from content writing, you can expand your knowledge towards SEO and from a web implementer, you can become a developer. Just don’t stop learning.

Also, if you have specific talents or hobbies like writing or design, you can base your career on that.

There is nothing better than doing what you love.

Additionally, it would be a good idea to analyze the market before you jump into the learning process.

For example, now it would not be the best time to specialize in writing travel-related content, while it would be a great moment for any job related to webshops and online sales.

If you want to learn web development, web design, web security, or SEO, you should always focus on new trends, so your skills can be useful in the future as well.

For different jobs, working terms often vary so you should take this into consideration when choosing your career path. At some jobs, you can work flexible hours while at others you have to be available during predefined hours. This is what you should have in mind when specializing in a certain area or looking for a first job.

Hurray, it’s time to get a first freelancing job

If you currently have a job, it would be wise to either save some money before you quit your job to become a full-time freelancer or try freelancing for a few hours per week, in the beginning, to see if you like it or not. If you become successful and decide that freelancing is something that fits your needs, only then quit your job, not before.

Although some people do benefit when taking a risk, think twice before you take any irreversible actions.

And here are some tactics that worked for me when trying to get my first freelancing job:

Use a freelancing platform – although this is not mandatory, it is much easier to get the first job when you are using a freelancing platform. My choice was Upwork back in the day, but there are several platforms that you can use to get the first job faster.

Triple-check your resume – I guess that this is not something that I should mention but I will anyway, just in case. Don’t make spelling mistakes in your resume, it will give the impression that you are not thorough and that you will oversee mistakes in your other work as well.

Present yourself in a professional manner – Take the time to present your professional skills in the best possible light but still stay humble. Don’t write: “Best WordPress developer that never wrote a bad code”. This is not evidence-based, and it will make you seem arrogant. Instead, you can write: “Web developer with 3 years of experience and over 50 satisfied clients, specialized in WordPress.” This statement is based on facts and it shows your credibility.

Fill up your portfolio – If you have any previous work (that is presentable, of course) you should put it in your portfolio. Emphasis on presentable. If not, you can make a few websites, designs, or write some example texts if you are a content writer in order to showcase your skills. This is not applicable to all jobs, like SEO consultants or customer support but if you have the opportunity to create a portfolio, use the opportunity.

Use video material – Short introductory video will make you stand out since making promotional video material is not something that many freelancers do. It will help you create a more human professional approach. For your clients, you will not be just a list of skills and previous experiences, but a real person that has these skills and experiences and that provides a certain service for them.

Have a detailed strategy when choosing your first employer – Choose your first employer wisely, very wisely. I can’t emphasize enough how important this is so I will give you an example. When I had to apply for my first job, I considered the following:

• How this employer was rated by other freelancers which worked for him previously
• How the employer rated other freelancers
• How much money he had already spent on this platform and if he posts regular job offers
• The number of open positions for this job and the number of freelancers that have already applied. In my case, the job had about 10 open positions so that amplified my chances of getting hired, even if the competition is high.

The first job is not all about the money – Don’t get greedy on your first job. If you get good reviews, your second job can be paid 2-3 times more. And your third job can go up to 5 times more. That was my experience at least.

Be careful, you are an adult

Individual responsibility is key when it comes to freelancing. You have the freedom to choose who you are going to work for, what kind of job are you going to take, and how it is going to be delivered. And freedom often comes with responsibility. They are like two sides of the same coin.

You should never miss a deadline. If you are not sure that you are going to be able to deliver, don’t take the job or as an alternative have someone very reliable as a backup, just in case. When you miss a deadline, your client loses money, and they have every right to be angry. This will very likely affect your reviews after the job is complete. And then, the opportunity to get your next job and so on. This can start a downward spiral for your career.

However, we are all humans and unpredictable things can happen. If for some reason you are not able to complete your work in a timely manner, let your client know immediately so they can have enough time to hire someone else.

Also, it is important to make everything clear in advance, before you accept the job. Let your clients know what your expectations are and make sure that you understand what they expect from you. For example, if you are a content writer, make sure that you know the length of the text in characters or words, ask if some keywords should be used and how frequently, what writing style your client prefers, and so on. And if you are a designer, specify how many revisions are included in the price.

The clearer the initial arrangement is, the more satisfied both you and your client will be at the end.

If you have flexible working hours, don’t let other people interrupt you. If your friends and family wouldn’t show up in your office every day if you were a bank clerk, they shouldn’t interrupt you when you work from home. It’s the same principle and it’s up to you to set the boundaries and let them know about your working schedule. It’s not up to them.

So, these are some basic guidelines that helped me in starting my freelance career and I hope that they will be helpful for you as well.

There is no unique recipe and one size doesn’t fit all when it comes to the path you ought to take.

It’s just important to stay focused on your goals and to be open to new opportunities.

If you were wondering why I’m not a freelancer anymore, this is where the answer lies. By constantly being interested in different opportunities, I realized that freelancing is not the only way to achieve my goals. There are companies that offer flexible working hours and peaceful work environment while stimulating professional growth and creative thinking.

Plus I gained something very precious by joining a team – my colleagues became my support system both professionally and privately, and that is what I have been missing while being a freelancer.

I wish you a lot of luck and success in the future, regardless of the path you choose to take.

Kako postati frilenser – stvari koje sam naučila pre nego što sam odustala

Naše životne priče su različite. Svako od nas ima svoj jedinstveni životni put, a iskustva koja steknemo oblikuju nas u osobe koje smo danas. Zbog toga, stvari koje mi, kao pojedinci, naučimo na svom putu ne mogu uvek lako da se primene na situacije kroz koje prolazi neko drugi.

Ipak, ponekad sagledavanje tuđih uspeha i grešaka može da nam pomogne da se bolje snađemo u sopstvenim životnim izazovima. Možemo da izbegnemo da napravimo istu grešku koju je napravio naš prijatelj ili, još bolje, možemo postati motivisani da postignemo jednak ako ne i veći uspeh kao neko iz našeg okruženja.

Zbog toga sam odlučila da sa vama podelim ono što sam naučila pokušavajući da postanem frilenser. Spoiler alert – sada sam zaposlena u korporacji.

Moja karijera je isla pomalo neuobičajenim putem. Nisam uopšte bila naklonjena informatici do pre pet godina. Tačnije nisam znala skoro ništa o toj oblasti. Bila sam potpuno fokusirana na fitnes industriju i radila sam isključivo kao fitnes trener od 2006. do 2015. To je za mene bio posao iz snova dok sam bila mlađa ali mi je oko moje 35. godine već pomalo dosadio.

Tada sam otkrila WordPress i shvatila da se mnogobrojne prilike otvaraju bas sa poznavanjem ove platforme. A frilensing je jedna od njih. Tako da, ako ste trenutno u fazi kada vam se frilensovanje čini kao dobra ideja, nastavite da čitate.

Pokušaću da detaljno opišem pet stvari koje sam naučila pokušavajući da postanem frilenser. Formulisala sam ih kao uopštene savete za početnike, ali neki od njih mogu da se primene i kada menjate kurs svoje frilens karijere.

Preispitajte svoje motive

Prva i najvažnija stvar koju treba da se zapitate pre nego što uradite išta u životu je zašto. “Zašto to radim?” Zbog čega želite da postanete frilenseri? Da li zbog toga što vam treba dodatni prihod? Ili zbog fleksibilnog radnog vremena? Ili da biste mogli da radite sa bilo koje lokacije na svetu? Ili frilensing vidite kao fazu pre nego što steknete dovoljno iskustva da možete da otvorite svoju agenciju.

Budite iskreni prema sebi. Popišite koji su to razlozi zbog kojih želite da budete frilenser. Ovo će vam kasnije pomoći pri izboru adekvatnog frilensing posla ili pri razmatranju neke druge alternative.

Na primer, ovo su bila moja tri glavna razloga:

• Prilika da naučim nesto novo i da se intelektualno razvijam u nekom novom pravcu
• Fleksibilno radno vreme – time što sam imala fleksibilno radno vreme bila sam u mogućnosti da izbednem dosadnu “od 9 do 5” rutinu
• Tiho i mirno radno okruženje, potpuno u suprotnosti sa teretanama u kojima je uvek bučno

Nakon što ste preispitali svoje ciljeve i motive, i sigurni ste da želite da se bavite frilensingom, šta dalje? Moj predlog je naučite nešto što je vezano za WordPress.

Steknite znanja vezana za WordPress

Sada se možda pitate zašto baš WordPress. Za početak, zato što WordPress nudi mnoštvo raznovrsnih prilika, i to ne samo za developere.

Iako, kad se pomene WordPress, prvo što će nekome pasti na pamet je ili developer ili web dizajner, postoji veliki broj različitih poslova vezanih za WordPress:

• Web developer (kodira sajtove, teme i dodatke)
• Web implementator (pravi sajtove od gotovih tema bez kodiranja)
• Web dizajner (dizajnira skice sajtova, edituje slike i kreira infografike za sajtove)
• Korisnička podrška (pomaže klijentima kada se nešto desi sa sajtom)
• Održavanje sajtova (redovno održava sajt, kreira bekape, ažurira teme, dodatke i sam WordPress)
• WordPress predavač (uči klijente kako da koriste WordPress ili uči druge web profesionalce koji se usavršavaju u nekoj oblasti)
• Pisac tekstova za sajtove
• Specijalista za aksesibilnost (vodi računa da određeni standardi budu ispunjeni i predlaže rešenja za barijere u aksesibilnosti)
• SEO konsultant
• Statističar (najčešće radi za velike onlajn prodavnice)
• WordPress asistent (unosi novi sadržaj i menja postojći)
• Specijalista za migracije (seli sajtove sa servera na server)
• Specjalista za web bezbednost

Još jedan razlog zbog kojeg mislim da je dobro izabrati WordPress je jaka zajednica koja se okupila oko ovog CMS-a. Redovno se održavaju manja okupljanja (trenutno na daljinu) ali i ona veća koja su nazvana WordCamp (takođe na daljinu do daljnjeg) na kojima možete dobiti pregršt korisnih informacija i pitati druge profesionalce sve što vas interesuje. Zajednica je toliko velika i raznolika da ćete tu pronaći odgovor na skoro svako stručno pitanje. Mnogo je lakse započeti frilens karijeru kada su sjajni ljudi oko vas.

Planirajte unapred

Sada kada znate u kom ćete pravcu ići, vreme je da počnete da planirate svoju karijeru.

Postati frilenser je proces. Na početku tog procesa potrebno je da steknete ili dodatno unapredite svoje veštine kojima ćete se istaći u odnosu na konkurenciju. I naravno kako učite i napredujete, moći ćete da prihvatate izazovnije i bolje plaćene poslove.

Na koja se onda znanja fokusirati? Ukoliko već imate neko predznanje za neki od prethodno navedenih poslova, možete se dalje razvijati u tom pravcu i specijalizovati se za tu oblast.

S druge strane, ukoliko nemate nikakvo relevantno predznanje, po mom mišljenju bi najlakše bilo započeti sa poslom koji ima kraći period učenja pa da kasnije nadograđujete znanje. Na primer, možete početi kao pisac tekstova za sajtove ili kao implementator jer se ti poslovi brže savladavaju nego poslovi vezani za SEO ili web development. Onda od pisanja sadržaja za sajtove možete proširiti znanje na SEO a od implementatora vremenom postati developer. Samo budite radoznali i ne prestajte da učite.

Takođe, ukoliko imate specifične talente ili neki hobi kao npr. pisanje ili dizajn, možete da bazirate karijeru oko toga.

Najlepše je kad neko zarađuje od nečega što inače voli da radi.

Uz to, valjalo bi da proučite tržište pre nego što se “bacite” na učenje.

Na primer, sada nije trenutak da se specijalizujete za pisanje sadržaja koji je vezan za putovanja, a pravi je momenat za sticanje veština koje, na bilo koji način, imaju veze sa onlajn prodavnicama i prodajom putem Interneta.

Ukoliko želite da savladate web development, SEO, web dizajn ili web bezbednost, bitno je da se fokusirate na nove trendove, tehnologije i alate, kako bi vaše veštine bile primenljive i u budućnosti.

Za različite poslove, uslovi rada mogu biti veoma različiti, pa bi i to valjalo imati na umu. Za neke vrste posla, radno vreme je fleksibilno, dok za druge, morate biti raspoloživi tokom određenog doba dana (ako radite kao korisnička podrška, na primer). I ovo bi trebalo da uzmete u obzir kada birate za koju oblast ćete se specijalizovati.

Konačno! Vreme je za prvi posao!

Ako ste zaposleni, bilo bi pametno da prištedite novac pre nego što napustite posao da biste se bavili isključivo frilensingom. Druga pametna opcija bi bila da vam na početku frilensing bude dodatni posao uz ono što već radite kako biste videli da li vam takav način rada odgovara ili ne. Ako postanete uspešni i shvatite da je frilensing nešto što odgovara vašim potrebama, tek tada napustite trenutni posao, ne pre toga.

Iako neki ljudi profitiraju kada rizikuju, dobro razmislite pre nego što preduzmete korake posle kojih nema nazad.

Evo nekoliko taktika koje su mi pomogle kada sam pokušavala da dobijem svoj prvi posao kao frilenser:

Koristite platformu za frilensere – iako nije obavezno, mnogo je lakše doći do prvog posla kada koristite neku platformu namenjenu frilenserima. U to doba, moj izbor je bio Upwork. Svakako, sada postoji i nekoliko drugih platformi pomoću kojih možete brže doći do prvog posla.

Triput proverite svoju biografiju – pretpostavljam da to nije nešto što bi trebalo da pomenem, ali svejedno ću naglasiti, za svaki slučaj. Ne pravite pravopisne greške u biografiji jer ćete time stvoriti utisak da niste temeljni i da će vam se greške lako potkrasti i dok obavljate svoj posao.

Predstavite se profesionalno – Uložite trud da svoje profesionalne veštine predstavite u najboljem mogućem svetlu, ali i dalje budite skromni. Nemojte napisati: “Najbolji WordPress developer koji nikada nije napisao loš kod”. Ovo nije zasnovano na dokazima i učiniće da izgledate arogantno. Umesto toga, možete napisati: “Web programer sa 3 godine iskustva i preko 50 zadovoljnih klijenata, specijalizovan za WordPress.” Ova izjava je zasnovana na činjenicama i deluje verodostojno.

Popunite portfolio – Ako imate bilo kakav prethodni rad (koji je naravno reprezentativan), trebalo bi da ga dodate u portfolio. Naglasak je na reprezentativan. Ako ne, možete da napravite nekoliko sajtova, dizajnirate skice sajtova ili napišete primere tekstova kako biste prikazali svoje veštine. Ovo se ne odnosi na sve poslove, kao što su SEO konsultanti ili korisnička podrška, ali ako imate priliku da napravite portfolio, iskoristite priliku.

Koristite video materijale – Kratki uvodni video će skrenuti pažnju na vas jer izrada promotivnog video materijala nije nešto što mnogi frilenseri rade. Pomoći će vam da delujete ljudskije i profesionalnije. Za svoje klijente nećete biti samo lista veština i prethodnih iskustava, već stvarna osoba koja zaista ima te veštine i iskustva i koja im pruža određenu uslugu.

Imajte detaljnu strategiju pri izboru prvog poslodavca – Birajte svog prvog poslodavca mudro. Ne mogu dovoljno da naglasim koliko je ovo važno, pa ću vam dati primer. Kada sam se prijavljivala za svoj prvi posao, uzela sam u obzir sledeće:

• Kako su ovog poslodavca ocenili drugi frilenseri koji su ranije radili za njega
• Kako je poslodavac ocenio druge frilensere
• Koliko novca je već potrošio na ovoj platformi i da li redovno objavljuje ponude za posao
• Broj otvorenih pozicija za ponuđeni posao i broj frilensera koji su se već prijavili. U mom slučaju, posao je imao oko 10 otvorenih radnih mesta, što je povećalo moje šanse za zapošljavanje, čak i u slučaju da je konkurencija velika.

Kod prvog posla nije bitan samo novac – nemojte biti pohlepni. Ako budete dobro ocenjeni, vaš drugi posao može biti plaćen 2-3 puta više. A vaš treći posao može biti vrednovan i do 5 puta više. To je barem bilo moje iskustvo.

Vodite računa, odrasla ste osoba

Individualna odgovornost je ključna kada je u pitanju uspeh u frilensingu. Imate slobodu da izaberete za koga ćete raditi, kakav ćete posao prihvatiti i kako ćete isporučiti dogovoreno. A uz slobodu često dolazi i odgovornost. Oni su poput dve strane iste medalje.

Nikada ne smete propustiti rok. Ako niste sigurni da ćete uspeti da završite, nemojte ni prihvatati posao ili, umesto toga, za svaki slučaj imajte nekoga vrlo pouzdanog da priskoči u pomoć ako zatreba. Kada propustite rok, vaš klijent gubi novac i ima puno pravo da se naljuti. Ovo će vrlo verovatno uticati na vaše ocene nakon obavljenog posla. A posledično, i na priliku da dobijete sledeći posao i tako dalje. To može pokrenuti silaznu spiralu za vašu karijeru.

Međutim, svi smo ljudi i mogu se dogoditi nepredvidive stvari. Ako iz nekog razloga niste u mogućnosti da svoj posao obavite u roku, odmah obavestite svog klijenta kako bi imao dovoljno vremena da zaposli nekog drugog.

Takođe je važno da sve bude jasno definisano unapred, pre nego što prihvatite posao. Obavestite svoje klijente o svojim očekivanjima i uverite se da razumete šta oni očekuju od vas. Na primer, ako treba da pišete tekst za sajt, uverite se da znate dužinu teksta u karakterima ili rečima, pitajte da li treba koristiti neke ključne reči i koliko često, koji stil pisanja preferira vaš klijent itd. A ako ste dizajner, navedite koliko je revizija uključeno u cenu.

Što je početni dogovor jasniji, to ćete na kraju biti zadovoljniji i vi i vaši klijenti.

Ako imate fleksibilno radno vreme, ne dozvolite da vas drugi ljudi prekidaju. Ako se vaši prijatelji i porodica ne bi svakodnevno pojavljivali u vašoj kancelariji da ste bankarski službenik, ne bi trebalo da vas prekidaju ni kada radite od kuće. To je isti princip i na vama je da postavite granice i obavestite ih o svom radnom vremenu. To nije njihov zadatak.

Ovo su neke osnovne smernice koje su mi pomogle u započinjanju karijere frilensera i nadam se da će biti korisne i vama.

Ne postoji jedinstveni recept i jedna veličina ne odgovara svima kada je reč o putu kojim treba da krenete.

Važno je samo ostati fokusiran na svoje ciljeve i biti otvoren za nove mogućnosti.

Ako ste se pitali zašto više nisam frilenser, evo odgovora. Stalnim sagledavanjem različitih mogućnosti, shvatila sam da frilensing nije jedini način da postignem svoje ciljeve. Postoje kompanije koje nude fleksibilno radno vreme i mirno radno okruženje, istovremeno stimulišući profesionalni rast i kreativno razmišljanje.

Uz to, stekla sam nešto vrlo dragoceno pridruživanjem timu – moje kolege su postale moj sistem podrške i profesionalno i privatno, i to je ono što mi je nedostajalo dok sam bila frilenser.

Želim vam puno sreće i uspeha u budućnosti, bez obzira na put koji ste odabrali!

The post How To Become A Freelancer – A Few Things I Learned Before I Gave Up appeared first on HeroPress.

In an extraordinarily inconvenient API change, Facebook and Instagram will be dropping unauthenticated oEmbed support on October 24, breaking content across millions of websites. The change will force users to generate an app ID with a developer account in order to continue embedding links via oEmbed:

Changes to tokenless access for User Picture and FB/IG OEmbed endpoints: By October 24, 2020, developers must leverage a user, app, or client token when querying Graph API for user profile pictures via UID, FB OEmbeds and IG OEmbeds. Developers should provide a user or app token when querying for profile pictures via a UID or ASID, though client tokens are supported as well. Please visit our changelog for User Picture, Facebook OEmbed and Instagram OEmbed for details on how to start calling these Graph API endpoints today.

Facebook for Developers blog

In 2008, Leah Culver, one of the collaborators on the oEmbed spec, said it was created to be “an open web API standard for fetching embed code based on a URL.” Requiring authentication in order to use oEmbed links seems like a violation of its intended purpose. For more than a decade, oEmbed has made it possible for users to easily share media across websites and social networks, without having to touch any code. It underpins a flourishing, connected landscape of web sharing that opens up new audiences for posts that might otherwise be buried in a social network’s fast-moving timeline.

In pursuit of a more secure walled garden, Facebook will now require all publishers to obtain developer app credentials in order to embed content that was previously available through simple URLs. Many users will be understandably frustrated when they find they can no longer embed Facebook and Instagram links the way they could in the past. Some will not be motivated to surmount the hurdle of setting up a Facebook app and may resort to posting screenshots or omitting the content altogether. A feature so widely used by non-technical users should not be suddenly locked away behind developer credentials.

At the time of publishing, none of the original oEmbed spec authors were available for comment regarding Facebook’s API change, but we will update the post as new information becomes available.

WordPress to Remove Facebook and Instagram oEmbed Providers

In response to Facebook’s API change, WordPress will be removing Facebook as an oEmbed provider in an upcoming core release. This will break a lot of content – many years’ worth of posts in some instances, and will require users to install a fallback plugin. WordPress plugin developer Ayesh Karunaratne has created a new plugin called oEmbed Plus that brings back support for Facebook and Instagram content embedding. It guides users through the process of setting up Facebook developer app credentials.

For those who are using the Gutenberg plugin, the Facebook and Instagram blocks have been removed as part of tomorrow’s version 9.0 release. oEmbed links will continue to work until Facebook’s API change goes into effect.

Moving forward, publishers will need to re-examine how they include social media links within their content. Hulu recently dropped oEmbed support after being available as an oEmbed provider in WordPress for the past 11 years. As major players like Facebook and Instagram follow suit in abandoning open web API’s, the web is growing increasingly more fragmented. Facebook’s upcoming API change will leave millions of broken embeds in its wake, with little pieces of embedded history lost along the way, in instances where website owners are no longer updating their content.

After publishing a post about the new Recipe Block plugin last week, several people were quick to point out that WPZOOM had released a recipe-related block plugin two years ago. Among them, was the plugin author, Pavel Ciorici. I had previously tested the Recipe Card Blocks plugin and thought it fit into that “overly complex” category that is not ideal for the average user who wants to share a recipe here or there. However, it may fit the bill for more dedicated recipe bloggers.

Over the past few days, I have been testing the plugin and giving it a more in-depth second look.

My thoughts on the plugin? Not much has changed. I would still recommend the Recipe Block plugin that I covered last week for its simplicity and ease of use. However, this is not a comparison post. There is a lot to like about WPZOOM’s Recipe Card Blocks plugin, and it caters to a similar but somewhat different audience. It is also not a single block plugin and would never be in the official WordPress block directory in its current form. Instead, it is a more fully-featured recipe plugin. Blocks are merely its primary component.

Recipe Card Blocks is packed full of options and features. If that’s your thing, it might interest you as a potential user. And, the pro version tacks on tons more, such as star ratings, social sharing, and adjustable serving sizes from the front end.

Recipe Card Blocks

Using the Recipe Card block in the editor.

The primary feature of the plugin is its Recipe Card block, which outputs Schema markup. This could give a search results boost or at least help search engines understand that you have a recipe on the site. For serious recipe bloggers, this is probably one of the most important features this plugin offers.

The question is really if the plugin’s Recipe Card block is worth using. For users who want options, options, and more options, the plugin offers at least a couple dozen of them for this one block alone. It has a plethora of toggles, inputs, buttons, and other things to customize. The downside is that it can be a bit overwhelming. With so many options, it also means the plugin developers must maintain tighter control over the elements within the block, which can mean less flexibility in other ways.

The block includes the standard fields that one might expect for a recipe card, such as servings, cook and prep time, ingredients and directions lists, and an image. However, it goes above and beyond by including extra features like:

• Grouping for ingredients and directions.
• Recipe video section.
• Notes section.
• Pinterest button.
• Print button.

One of my favorite features of the Recipe Card block is that site readers can check off ingredients on the front end. For ingredient-heavy recipes, this can be a time-saver in the kitchen as you gather the things you need to get started.

Ticking items off the ingredients checklist on the front end.

The default design is beautiful. There is ample spacing between elements. The sections are clearly separate so that there’s no confusion for the reader. It simply looks good.

However, there are some limitations and issues. At times, the default design is too opinionated, overruling theme styles. It also does not support wide alignment and has a hard limit on its maximum width of 750 pixels. This could make it undesirable with some site designs. Nevertheless, the plugin team made generally smart design decisions. It should work well within most contexts.

What makes the Recipe Card block tough to use is that end-users must jump back and forth between the post content area and the block options in the right sidebar panel. For example, users must add the course, cuisine, and difficulty text in the sidebar but add the servings, prep time, and cooking time in the content editor.

Entering items in the ingredients or directions lists also requires more work than one might think. Typically, in visual editors, simply hitting the Enter key should create a new list item. This is not the case with the Recipe Card block. Even tabbing moves users to other controls instead of hopping between items in the list. It is particularly frustrating if you prefer to use the keyboard over the mouse.

These usability issues keep the plugin from being simply a good plugin rather than a great plugin. User experience issues are not insurmountable. They can be addressed, and I hope the team can continue iterating on and improving the experience.

I would also like to see the block opened up for the addition of other inner, sub-blocks. Currently, the layout is locked in place. While it may be suitable for some users, locking the block template means that users can neither move the current elements around nor add custom sections that suit their needs. Locking the block means that the plugin author retains control over much of the output, which can sometimes be a good thing — quality control. However, it makes the block less flexible.

This inflexibility is somewhat mitigated with the plugin’s other blocks. While the Recipe Card block is the primary feature of the plugin, it does break its sub-elements down into individual blocks that users can use to create their own layout by dropping them into a Group or other container-type block. It offers the following extra blocks:

• Details
• Directions
• Ingredients
• Jump to Recipe
• Print Recipe
• Nutrition

Separate Nutrition block in the editor.

With a little ingenuity and perhaps a plugin like Block Pattern Builder (a plugin that I maintain), end-users could create custom, reusable recipe layouts.

The Big Issue

The thing I dislike about the plugin the most is that it outputs a “RECIPE CARD PLUGIN BY WPZOOM” message in the front-end post content output. This message is hidden in the editor view. Plugin users can see it only on the front end. For the average user, there is no easy way to remove this message without upgrading to the pro version of the plugin, which costs at least $69.

Frankly, commercializing the removal of a credit link a shady business practice. It is a tactic that preys on those who do not know how to code. Sorry, I got no love to give for this.

This was frowned up 10-15 years ago when theme authors were doing it. It should be frowned upon today when plugin authors do the same.

Upsell custom branding. Upsell a 100 other things that add value. Don’t upsell removing a credit link that you are outputting in the user’s post content. This one problem with the plugin paints a stain over everything else that is good about it.

Final Thoughts

I do not want to end on a negative note. Recipe Card Blocks is a useful plugin for those who want more than a basic recipe block. It is almost more of a recipe management tool but not quite.

I would have taken a different route with some of the development based on the publicly-known plans for the plugin. For example, I could see creating a recipe custom post type separate from the block system. Then, allow users to insert these “recipe posts” into the block editor. With plans to add custom taxonomies to the plugin, it makes sense to keep the whole data layer separate.

It seems the plugin is torn between being a recipe block and a full recipe management plugin. I would like to see it fully commit to the latter because that seems to be the direction it is heading. However, from an architectural standpoint, it will need work to get there. It can still be done, despite two years of legacy code, and it has the opportunity to carve out its own space in the ecosystem.

If the plugin’s development team would remove the upsell of the credit link, I would absolutely recommend this plugin to people who want to run a serious, full-time recipe blog. It has those extra features like a nutrition label, a print button, and Schema markup that give it an edge over some of the competition. For users who simply want to add a recipe on their blog from time to time, it is overkill.

Since Akismet launched nearly 15 years ago, it has blocked 500 billion spam comments. We’re proud to have saved you countless hours of moderation time, reduced frustration for millions of people, and helped make the web a more beautiful place.

Akismet is the most powerful solution on the market for stopping spam, but spammers are continually inventing new ways to get past our filters. Adding new spam detection techniques will ensure we keep Akismet one step ahead of bad actors, but it will require additional investment. We don’t take changing prices lightly. In fact, we haven’t changed the price of the entry-level plan since it was introduced in 2005.

For commercial sites, the price of Akismet will be better aligned to API usage. This means that as you use Akismet more, the cost per API call will decrease.

For those that use Akismet on your personal sites — we’re 100% committed to offer Akismet at a price you can afford. Spam is a menace to the internet and we feel that everyone should have the ability to stop spam on their websites. Even if you’re not making money from your site, we want you to have the best spam filter available. We will continue to provide the option to pay what you can, and we thank you for helping to contribute to this project.

To our current customers, you don’t need to do anything now. Your plan will remain at its original price and API limits at least into 2021. If you’d like to switch plans or start a new account, your plan will start at the new price.

What’s different?

Personal

No changes. For sites that don’t sell anything, advertise, or have affiliate links, Akismet is available for whatever amount you are able to pay.

Plus

Akismet will block spam on one site for up to 10,000 API calls and provide priority support for $8.33 per month billed yearly. The price for monthly billing is $10. That’s equal to two months free for selecting yearly billing.

Enterprise

We’re decreasing the price of our Enterprise plan! Yearly plans will now be $41.66 per month, with the total yearly cost at $500 instead of $550. For monthly billing, the price is staying the same at $50 per month. For enterprise plans, Akismet will block spam on multiple sites for up to 60,000 API calls per month, as well as provide priority support on all sites.

Enterprise Plus

For our largest customers, we’re happy to provide discounted pricing and dedicated support through this new plan. If your sites have more than 60,000 API calls per month, contact us and we’ll be happy to set you up.

Thank you for your continued support of Akismet. If you have questions specifically related to your own Akismet account or API key, then please visit our Support page.

 

“My Podcast Set I” by brainblogger is licensed with CC BY 2.0.

Podcasting, like many other industries during the pandemic, is seeing a strong shift over the past six months, which has resulted in more shows and fewer listeners. While some avid podcast fans have taken solace in listening to their favorite shows to stay connected, many listeners who previously had podcasts built into their routines have turned to other forms of media consumption in the absence of a daily commute.

In April, global podcast listening was up 42% (and 53% in Europe) as lockdowns began in the U.S. and other parts of the world. Although listening in the U.S. went down 20%, certain verticals remained strong, such as true crime, music interviews, science, medicine, religion and spirituality, and self-improvement.

Prior to the pandemic, the podcasting industry was experiencing a boom, with experts projecting marketers to spend over $1 billion in advertising by 2021. The pandemic has thrown a wrench into the industry’s growth. In the months of continued isolation and social distancing, E-marketer recorded its first contraction in time spent listening since it began tracking in 2015 but estimates a rebound in the coming years.

Source: eMarketer, June 2020 (https://www.emarketer.com/content/time-spent-with-podcasts-will-dip-amid-pandemic-should-rebound-by-2022?ecid=NL1001)

The pandemic may have temporarily stunted the growth of listeners, but the team at Castos is witnessing a new trend emerging: individual creators and businesses are finding the time and inspiration for firing up new shows. From April until now, the podcast hosting company has seen a 300% increase in new trials, and a 102% increase in MRR over last two years. Castos currently has nearly 2,000 paying customers.

The company started in 2017 after non-technical founder Craig Hewitt acquired the Seriously Simple Podcasting plugin from its original creator, Hugh Lashborooke. Hewitt expanded the platform to allow both WordPress and non-WordPress users to create podcasts, and has grown the business to support seven remote, full-time employees. He attributes most of the industry’s fresh infusion of new shows to companies that are exploring new ways of getting into customers’ homes.

“Many brands are finding that traditional marketing efforts are falling short in these turbulent times, but great content that serves a specific audience always has an impact,” Hewitt said. “Many companies are pivoting from more conventional paid acquisition approaches to building stronger and longer lasting relationships with their audiences through podcasting.”

Hewitt said he expects the trend to continue after the pandemic subsides. Many of the companies Castos works with have reported that podcasting is likely to become a core part of their marketing efforts for the long haul, in both B2B and B2C environments.

“Like the move to remote work many companies are seeing that podcasting isn’t hard to do, and provides great returns for them in terms of branding and as a top of funnel customer acquisition strategy,” Hewitt said. “Whether in the midst of Coronavirus or afterwards this will continue to be true and the momentum that podcasting has gained should continue.”

Approximately 70% of Castos’ hosting customers are using the Seriously Simple Podcasting plugin. The hosting platform is unique in the podcasting market in that it automates YouTube Republishing, transcriptions, and Headliner integration, while allowing users to manage it all via WordPress. Castos recently hired Matt Medeiros, an experienced podcaster and YouTube creator, to help new podcasters keep pushing with their shows and convert into longterm customers. He shares Hewitt’s optimistic outlook on the future of the industry.

“There were early reports that podcast download stats dropped in tandem with listener commute times, but I think that opened up opportunity for creators to really capture their most loyal audiences,” Medeiros said.

“The other side of that coin are the businesses that needed to stay top of mind with the customers while their doors were closed. Spinning up a podcast is a perfect way to do that. Podcasts come in all shapes and sizes, so building one that’s tailored to your customers is what really matters and will survive through our post-pandemic ‘new normal.'”

Portability is the common denominator for podcasts – people are listening from their desktops, mobile devices, and smart speakers, using a variety of different apps. But audiences vary in their appetites for staying informed, educated, and entertained through the podcasting medium. Medeiros advises both new and established podcasters to find out what kind of show their customers want them to produce.

“Podcasts don’t have to be cookie cutter,” Medeiros said. “If you spend time getting feedback from your customers or audience, you want to tailor the show around that. Do they like 15 minute news highlights or 3 hour 1-on-1 interviews? Do they want hard news or laugh out loud entertainment? What’s in it for them as a listener? What’s in it for you as a creator?

“At the end of the day, the biggest opportunity for podcasting is that it opens the door to having your favorite creators and fans in the same room every time you publish an episode. It’s a chance to (literally) have a conversation and build trust through creative storytelling – your brand’s digital handshake.” 

Overnight, the Meta Team for WordPress.org flipped the switch for a new plugin author feature in the official directory. It allows plugin authors to opt into confirming plugin updates via email. Release confirmations will strengthen security and make sure any updates sent in are intentional.

Dion Hulse opened the original ticket six weeks ago with a detailed proposal and set of questions. WordPress 5.5 introduced automatic updates for plugin and theme authors. While auto-updates are completely opt-in for end-users, Hulse wanted to make sure that WordPress.org was on top of any potential disasters that may arise from the new system, such as accidental or even malicious plugin releases.

“I’d like to propose that we add an extra optional step into the release flow for plugins, not intended on adding friction, but intending to ensure that plugin releases only get made when they’re intended to,” he wrote. “A simple Email confirmation.”

At the moment, release confirmation via email is merely an opt-in feature that all plugin authors can take advantage of. However, the original proposal required it for high-usage plugins — there was never a definitive minimum install count that constituted “high usage” in the ticket.

The general agreement on how this feature should work seems to be:

• Opt-in for all plugin authors now.
• Forced opt-in and no opt-out for high-usage plugins soon.
• Opt-out for all other plugins in the future.

For larger plugins with multiple committers, there was some discussion on requiring confirmation from a separate committer who did not push the code live. This would essentially require two people to confirm that a plugin update is valid. This could potentially add to the friction that Hulse wanted to avoid in the original proposal. However, some friction for plugins with millions of installs might not always be such a bad thing. These plugins serve a massive user base and can damage WordPress’s reputation if a malicious actor gained commit access somehow. Having two people confirm an update is a good kind of friction in some cases.

However, requiring two-person confirmation is a more nuanced discussion that will need to happen. For example, Chris Christoff brought up examples in the ticket of not being able to send updates for plugins with two committers when one is on vacation or when the committers live in different time zones. Perhaps this will be an opt-in feature for plugin companies that choose to go this route in the future, depending on what fits their release flow best.

On the whole, the current implementation is a good starting position that will allow the community to iron out further details. This is about making WordPress more secure. If there is an extra step involved in publishing a code update, plugin authors should be on board with the process. Verifying the validity of a release sounds like a common-sense security feature. I would welcome WordPress.org making this a hard requirement — neither opt-in nor opt-out — in the long run after the feature has gone through a few rounds of real-world testing.

Theme developers do not have access to this feature at this time. However, the theme authors do not have access to SVN and must submit updates via a ZIP file. It is a much more manual process and should not be subjected to the same number of potential mishaps as plugin updates.

How Plugin Authors Can Enable Release Confirmation Emails

Enable email release confirmation form for plugin authors.

Plugin authors should now see a new administration option for each of their projects listed in the official plugin directory. The Danger Zone section of the Advanced View tab should display a new sub-section for enabling release confirmation emails. From there, authors merely need to click a button to turn them on.

It is important to note that, once enabled, release confirmation emails cannot be disabled from the same screen. Plugin authors are presented with the following notice before enabling the feature:

Warning: Enabling release confirmations is intended to be a permanent action. There is no way to disable this without contacting the plugins team.

Do not let the warning put you off if you are a plugin author. This is a good thing. Go ahead and enable it on at least one plugin if you want to test it first. I already have done so for one of my plugins. It is a simple process and helps add one additional layer of security over your plugins.

In August, following the suspension of the popular Astra theme, WordPress Meta contributors opened a ticket to add a new “delisting” status for non-compliant themes. Astra’s infraction, breaking the directory’s ban on affiliate links, put more than a million users at risk of not getting theme updates just as WordPress 5.5 was on deck for release. This week the team committed a patch for a delist status that will temporarily hide a theme from search, while still making it available directly. Alex Shiels outlined how the new status will work:

• Delist is only available from a published state.
• Relist will set the status back to publish.
• Delisted themes are excluded from site search.

While a full suspension may seem like the best retributive action when theme authors violate directory guidelines, the necessity for users to be able to continue to get updates outweighs throwing the book at the author, especially for a first-time offense. A delisting policy is more restorative in that it seeks to maintain the connection that users have with the theme’s author instead of merely imposing a penalty that might ultimately have a negative impact on everyone involved.

In the past, the Themes Team has been limited on available actions for responding to violations. Ionut Neagu, CEO of ThemeIsle, had his company’s popular Zerif Lite theme suspended from the directory in 2016 for a five-month period that left 300,000+ users without maintenance and security updates. It also resulted in a 63% decline in the company’s revenue for that theme, since ThemeIsle was using WordPress.org as the primary channel for distribution.

Neagu remarked on how the new “delist” status provides a less severe transition back into the directory for popular themes:

The practice of delisting is something that’s already been done by other companies in similar situations. For instance, delisting is what Google does all the time when they find a website that doesn’t comply. Then, the website is allowed to come back and appear on the ranking pages again when the issues are fixed.

In the end, I think this is a move in the right direction and an improvement to the process of what happens with a problematic theme.

Despite the controversial decision that slashed ThemeIsle’s revenue from $120k/month to $45k/month in 2017, the company continued to support the theme, as well as new products, with WordPress.org as the main place to find them. Neagu reported that when the theme was reinstated, its revenue continued to be hard hit. It lost momentum and was unable to ride the wave of its initial success. Astra faired much better in the aftermath of its violation, given its short-lived suspension.

WordPress Themes Team member Alexandru Cosmin requested the ticket for adding the delisting status receive prompt attention, as the team is set to introduce some new policies and requirements that are tied to it. The patch was committed and then reverted temporarily to review how it impacted theme trac tickets, but the bugs appear to be unrelated to the patch.

The volunteer Themes Team has essentially been the de facto guardians of the WordPress.org marketplace that sends millions of dollars to theme authors, and they perform a great service to the community. But in the interest of supporting and accelerating the growth of the WordPress ecosystem, the team needs to adopt policies that create a more restorative path for violators, instead of obstructing the growth of products where issues have been quickly resolved.

I could hardly sleep last night. Once in a blue moon, I have an idea I want to try out. While my day job as a writer means I spend far less time breaking sites through the rigorous trials and errors of building plugins and themes, some problems bug me with WordPress, the sort that keeps me from dozing into restful and peaceful dreams.

Last week, Gutenberg 8.9 dropped the experimental flag from its block-based widgets system. Overall, it was a solid first outing for a feature that should land in WordPress 5.6 this December. However, the largest problem centered on how theme authors would be able to style widgets in traditional fashion. Because actual widgets are being phased out and replaced with blocks, theme authors will no longer have access to the standard widget and widget title classes. This is problematic because there is no predictable way to style all widgets of a particular sidebar to look the same.

The classic example is of the boxed widget design. Many themes, such as the popular Colibri, employ such a design for their sidebars as shown in the following screenshot.

Boxed widget design in right sidebar of Colibri theme.

In its current state, there is no reliable way for theme authors to create such a sidebar design via the block-based widgets system. Because there is no way to exert any sort of control over the structure of whatever content users will drop into a sidebar, it would be easy to look at this situation and think that theme designers are losing control.

Based on a recent GitHub ticket and a related Slack discussion from earlier this week, it does not appear that the Gutenberg development team intends to create parity between the old and new widgets systems, at least as far as theme design is concerned.

It bears repeating. I am a fervent supporter of handing over this type of ultimate control to the user. However, we need to balance that with helping them to make smart choices.

Theme authors must begin thinking about how this impacts the work they do and come up with creative solutions for sidebars, widgets, and other areas that will be affected by full-site editing in the future.

A Potential Solution

That thing that kept me up last night was an idea of combining block patterns, one of my favorite features, with widgets. The trouble was that the block-based widgets system does not currently support block patterns. And, until a quick discussion with Mark Uraine, one of Gutenberg’s designers, on a GitHub ticket, the idea did not seem to even be on the table.

For theme authors, the traditional sidebar and widget system of the past was nothing more than a pattern. WordPress provided theme devs with the ability to set a wrapping HTML element for the entire widget and the widget title. It was a rigid and inflexible system, but it was a reliable standard.

Block-based widgets are the complete opposite. They are essentially a free-for-all where users can drop arbitrary content into a “block area.”

What happens when we combine the structure of patterns with the flexibility of blocks inside of sidebars?

That was the idea that got me out of bed and behind the computer screen early this morning after my restless night. It was such a simple concept. Theme authors could provide a “widget” pattern to their end-users. This would provide users with a choice between what the theme author thinks best and forging their own path — the best of both worlds.

Simple example of recreating a boxed “widget” pattern.

And, here is where the beauty of the block system really comes in. Theme authors can create any number of patterns. This provides even more options for users.

Regardless of whether the Gutenberg plugin currently supports patterns for the block-based widget system, the idea was simple to test. In a sidebar on the new widgets screen, I merely needed to add a new Group block with the widget class. Then, I added an H3 Heading block with the widget__title class. Those classes may even be unnecessary in the context of patterns unless theme authors want to directly target them. Outside of the custom classes, I added a simple background to the Group block and changed the text color of the Heading. I also inserted an empty paragraph where the user’s custom content would go.

Afterward, it was a simple matter of testing it with various blocks.

Faux block pattern in the widgets block editor.

I would love to know what theme authors and the Gutenberg team think of the idea. I think it has some merit while soothing some of the transitional pains between traditional widgets and block-based widgets.

The biggest issue I see is the discoverability aspect. Will end-users know these “widget/block patterns” exist if theme authors went this route?

The official AMP plugin for WordPress recently crossed the 2.0 milestone, a major release that closed 141 issues and merged 174 pull requests. The release was originally planned for v1.6 but due to the number of major changes the team decided to bump it to 2.0.

One of the most significant updates in this release is the expansion of the Reader Mode. The plugin has a lot of AMP-specific terminology associated with it and unless you are working with it every day, it’s easy to get confused by the different modes. Standard Mode is an AMP-first site where all URLs are presented as AMP pages. Transitional Mode uses one theme but canonical non-AMP URLs may offer a separate AMP version. Reader Mode uses two themes with the active one for canonical non-AMP URLs and a separate “Reader” theme for AMP URLs.

Version 2.0 introduces a new AMP Customizer for customizing the Reader theme. It loads with a mobile view and does not support widgets or homepage settings, as they are not applicable for the AMP version. The AMP Customizer makes it easy for site owners to make tweaks and changes that will only apply to the AMP version of URLs.

The Reader Mode is especially useful for sites that are not using AMP-compatible themes. Google engineer Weston Ruter described the expanded Reader Mode as follows:

Reader mode now allows for any AMP-compatible theme to be used to serve AMP pages, rather than just the legacy post templates. This allows for long-requested features including nav menus, logos, commenting, and template design variations. It also makes it possible to serve all URLs of a Reader-mode site in AMP, as opposed to just singular posts. 

One major usability update in version 2.0 is the addition of an onboarding wizard and revamped Settings screen that guides users through the different templating modes when configuring the plugin. Users who are routed to Reader Mode will be presented with a selection of themes for serving AMP pages and the wizard will handle installation. The final step of the configuration process allows users to review their choices in a preview screen.

Given the complexity of the AMP plugin and its many configuration options, the onboarding wizard was a critical addition if the plugin is going to grow past 500,000 active installs to reach a larger number of non-technical users.

Another notable update in this release includes a feature called “Plugin Suppression” that allows administrators to turn certain plugins off for AMP pages if they are causing validation errors. It also introduces mobile redirection for Transitional/Reader mode sites where AMP is intended to be the mobile version.

AMP is still far from a plug-and-play experience for WordPress users but the plugin does a lot of the heavy lifting and is evolving towards becoming more approachable for non-technical users. To that end, the AMP plugin team just announced a new video series that will focus on success with WordPress as a content creator, as well as performance and usability.

“We are crafting it with an audience in mind that covers both technical and non-technical users,” Google Developer Advocate Alberto Medina said. “The 2.0 version of the plugin makes an emphasis on providing options for users that are non technical but still want to take advantage of AMP to bring great page experiences to their users.”

The series will launch next week on Google’s AMP YouTube channel. Medina is also working on another series geared towards content creators that will cover topics like Web Stories in the first episodes.

“Organize your quarantine-inspired baking blog with a ‘Recipe’ block!” read the opening description of Kelly Choyce-Dwan’s new plugin, Recipe Block. That was enough to pique my interest. I love food. I love baking — mostly pizza and bread. Food-related plugins and themes almost inspire me to spin up a recipe blog of my own. Almost.

At least with plugins like this, I can dream of building that site. Or, I can vicariously live through those who have the inclination, passion, and drive to post recipes regularly.

For far too long, building a recipe blog has required specialized themes or overly complex plugins. I have been eagerly awaiting a simple recipe block because I have known since Day 1 of Gutenberg’s launch that it would be well-suited to such a feature. Choyce-Dwan’s Recipe Block plugin makes the complex simple and brings recipe-blogging to any WordPress user.

Using the Recipe Block

• Recipe Block
• Cover + Recipe Block
• EditorPlus + Recipe Block

Within a couple of minutes of installing and activating the plugin, I had a quick pizza recipe set up and published on my test install. It worked well with the several themes I tested it against. I did make a couple of spacing adjustments via CSS for my personal theme, but that is not uncommon for plugins that have front-end output.

Technically, the plugin adds four blocks:

• Recipe: Primary block that houses other blocks.
• Information: Sub-block for adding servings, time, and difficulty level.
• Ingredients: Sub-block for listing ingredients.
• Directions: Sub-block for listing directions.

The Recipe block also makes use of the core Image and Heading blocks. It is as simple to use as nearly any other block. Add the block to a post via the inserter or the /recipe slash command. From there, end-users can customize the output to their heart’s content.

Because the Recipe block itself lacks any custom colors or other stylistic options outside of wide and full-width alignment, the easiest way to spruce up the design a bit is to drop it into a Cover or Group block. Doing so provides a wider range of design options. For those users who need even more design control, Munir Kamal’s EditorPlus plugin is a nice addition when wrapping it with the Group block.

One of the best things about the Recipe block is that it is not locked. End-users can move sub-blocks around to their liking. It even allows nesting of other blocks. Not everyone creates the exact same type of recipe cards, so it makes sense to have some extra customizability.

The block is also flexible enough for recipes that have multiple ingredients and directions lists. So, that pie and pie crust recipe you want to share? No problem. You can split the ingredients and directions so that your readers are not accidentally dropping lard into the pie filling.

Missing Features

The Recipe Block plugin is by no means ideal for every situation. Some features could make it stand out a bit more. For the most part, I wanted a few additional styling options.

Choyce-Dwan makes it clear in the plugin description that it does not support Schema or structured content. That would make a nice block option for those who want to enable it.

I would like to be able to change the text and background color of the main Recipe block. However, this is easily done by wrapping it with the core Group block. Ultimately, I would like to have the option to add some different styles to it, such as a custom border. Such a feature should probably land in core WordPress first so that there is a standard.

It would be nice to allow users to change the font size and colors within the Information, Ingredients, and Directions blocks similar to how the core Paragraph block works. Again, you can wrap this with the Group block and at least set the colors at a higher level.

Deque Systems, a widely respected accessibility firm that has contributed to setting up automated accessibility testing for WordPress core, will be hosting a new “Axe-con” virtual conference focusing on digital accessibility. Axe-con is named for the company’s axe-core project, an open source library and accessibility testing engine that can be customized to integrate with all modern browsers and testing frameworks. It’s happening March 10-11th, 2021, and tickets are free.

Learning how to create accessible experiences for the web is challenging. Axe-con will bring together experts from around the world who can accelerate that journey for developers, designers, business owners, accessibility professionals, and anyone involved in the team effort required to make digital experiences accessible. The event will feature multiple tracks with a variety of topics, including sustainable accessibility, compliance, best practices, and case studies from organizations leading large-scale accessibility efforts.

For those interested in obtaining or maintaining IAAP (International Association of Accessibility Professionals) certification, attendance at Axe-con sessions can count towards IAAP continuing education (CE) credits.

The event will also include a hackathon where attendees will have the opportunity to network with each other while coding and collaborating on accessibility projects. A few examples include testing open source component libraries and logging issues, building new axe integrations, and working on personal projects.

Deque Systems is hosting this new conference the same week as the CSUN Assistive Technology Conference. The company is has attended and sponsored the event in the past but sees the need for a conference focused more on building accessible digital experiences. Deque could no longer meet this need by tackling those topics in a single sponsorship room limited to 100 people. When its CSUN 2020 sessions were forced to go virtual, the team discovered that thousands were able to join in on topics more related to digital accessibility.

Organizers anticipate that attendees will join both CSUN and axe-con in 2021. By scheduling the events in the same week, they are hoping to help attendees make more efficient use of their time that would normally be set aside for traveling to an in-person conference.

Registration is open and last week organizers reported there were already more than 2,000 people signed up. The Call for Papers will be open until 8:00PM ET Friday, October 23rd, 2020, and speakers will be notified by November 23. Talks will be broadcast in the Eastern timezone but international speakers are welcome.

On August 26, Automattic launched a new theme titled Seedlet that focused on integrating with the WordPress block editor. A few days later, it was also live in the WordPress.org theme directory. The theme development team wanted to produce a theme that would be in a good position to transition to full-site editing later this year as WordPress 5.6 lands.

Seedlet makes wide use of features that integrate with the block editor. It does so in what is the simplest of ways, which is a testament to how much easier theme development is becoming in the dawn of the block-based themes era. The theme makes liberal use of theme-supported features like custom font sizes, colors, and gradients. It takes its integration an extra step by registering block styles and patterns.

Seedlet almost feels like a skin around the block editor. It is a prime example of the future that we’re hurtling toward, which will mean less focus on code and more focus on design configuration. Themes will not be themes in the traditional sense. I use the term “skin” because it harkens to various systems in days gone by where designers simply added CSS to skin a site. WordPress themes will always be a bit more complex than a simple stylesheet but not much more so. We will be getting back to the basics of CSS and HTML.

That is what I see when I look through the Seedlet theme’s code. While it still has copious PHP, there is an unmistakable structure that clearly says that that theme development is changing — and here is what it looks like as we transition.

I have seen many themes that developers have built to work with the block editor. However, I have seen only a few that have taken a block-editor-first approach. It is almost subtle, and unless you have been neck-deep into theme development for years, you may miss it. Automattic’s theme team is riding the winds of change. Theme authors who want to ride along should pay attention to where this project goes in the coming months.

The one thing I do not understand is why Automattic did not choose to add the “Block Editor Styles” tag to the theme. It clearly adds such styles. This is a missed opportunity to help users find themes compatible with the block editor.

The theme will not suit everyone’s taste. It is a basic blogging theme at its core. However, its wide-open canvas makes it suitable for a variety of sites. The theme’s typography is on point, creating a comfortable reading pace for longer-form work. There is a lot to like about the theme, but I am primarily interested in what the development team has built for the block editor.

Kjell Reigstad, the primary designer on the theme, also announced the team is working on a completely block-based version called Seedlet Blocks. The current plan is to continue iterating on it and launching it as a separate, standalone theme in the future.

Experimenting With Block Patterns

While Seedlet includes only three block patterns, they immediately stood out to me. The patterns are not overly complex, but they are unique designs that make use of core blocks with a mixture of the theme’s presets, such as custom gradients and block styles.

The “Group with Split Background” pattern uses a Group block with the theme’s preset diagonal gradient to create a background for an Image block. It is not a particularly groundbreaking design. However, the beauty is in the simplicity. It shows that theme authors can create interesting designs without adding extra CSS code.

Group with Split Background pattern in the editor.

The theme’s “Group with Image Overlap” pattern kicks it up a notch in complexity. Starting with the same concept of a Group block with another custom gradient preset, it throws in a Columns block. In the left column, users can add two images, stacked. In the right column, users can add one image. The end result is a custom layout — primarily because of the gradient background — where the two images from the left column overlap the solid background.

Front-end output of the Group with Image Overlap pattern.

The technique is simple in terms of code, but it takes a good designer to create the concept. We are just now scratching the surface of what theme designers will be able to accomplish when they begin thinking about applying various techniques to the block system. Seedlet has some of that sort of outside-the-box thinking with its use of gradients. We need to see more of that from the theming community.

Admittedly, I am not a fan of the third pattern the theme adds. “Alternating Grid of Latest Posts” inserts the Latest Posts block into the editor with the theme’s custom “Alternating Grid” style. Mostly, I just do not care for the layout, but that is simply based on my personal taste.

Alternating Grid of Latest Posts pattern in the editor.

On the whole, I love what the theme is doing with block patterns. This type of exploration is exactly what the WordPress community needs right now.

Jetpack is firing up a new suite of email marketing tools in partnership with Endurance International Group’s Constant Contact brand. Last week version 8.9 of the plugin introduced a new newsletter signup form inside its Form block, based on an integration with the Creative Mail plugin that Constant Contact recently launched as a solution tailored specifically to WordPress and WooCommerce.

The release post highlighted the ability to add WordPress posts and WooCommerce products into email marketing campaigns, but today the Jetpack team elaborated on where they are taking the integration. The features Creative Mail has on deck for future releases are heavily geared towards e-commerce stores. The initial launch includes the ability for store owners to sync their contacts to their email lists in order to market to them directly. Curt Raffi, Senior VP of Product Innovation at EIG, said WooCommerce-triggered store emails are on the way.

“Soon, we’ll add automated customer lifecycle marketing journeys that are geared toward more advanced marketers and eCommerce seller,” Raffi said. The planned features include the following:

• Create triggered, multi-step customer lifecycle marketing journeys
• Send WooCommerce abandoned cart emails
• Send post-purchase follow-up emails
• Send emails about related products

Email marketing is a critical piece of the puzzle for online store owners looking to connect to customers, as they adapt to the pandemic with reduced foot traffic for brick and mortar locations. Stats from Campaign Monitor show that email send volumes increased by 31% for a random selection of their customers with mid-sized email lists during the 30-day period after March 17 versus the 30 days prior to that. Despite a sizeable increase in send volumes, average open rates for these decreased only slightly, from 31% to 30%, while click-through rates remained the same at 4%.

Even with all the perfunctory messages acknowledging “these uncertain times,” email is still an important channel for reaching customers. As social networks are becoming increasingly hostile and unfavorable environments for advertising, email stands as one of the few remaining direct lines where content won’t get instantly buried by potential customers doomscrolling their news feeds.

Automattic CEO Matt Mullenweg commented on Twitter last month about the value of having a follower’s email address vs a connection on a social network. “So many of these people with newsletters should really be blogging,” Mullenweg said.

“I do think that a follower you have an email address of and a direct relationship with is worth 1,000x a follower on a social network. Maybe it’s just about making things more website-first than email-first, especially for younger audiences that don’t use email.”

One response to his tweet caught my attention – a suggestion that Jetpack make it more convenient to manage a website-first solution for email marketing. It looks like this idea was already in the works with Creative Mail and the Constant Contact partnership.

Although Constant Contact already had an official plugin for WordPress, it only has 40,000 installs. Compare that with MailChimp, which is far and away the market leader when it comes to email marking providers. Mailchimp has many third-party plugins for WordPress, which collectively have more than a million users, including an official Mailchimp for WooCommerce plugin, with 800k+ active installs. Constant Contact stands to have a better chance penetrating the WordPress market by partnering with a highly successful plugin like Jetpack.

Email marketing is not an easy plugin niche to break into, which is evident by the slow growth of newcomers like Newsletter Glue. The plugin is marketed as a Substack alternative, with its “Send as newsletter” feature inside the WordPress editor. It connects to different emails services, provides easy-to-share past issues, and creates a search engine-friendly newsletter archive. Despite all the promotion and buzz on social networks, the plugin only has ~30 active installs after one month in the official directory.

With its deep integration with Jetpack and WooCommerce, Creative Mail has the chance to quickly become a contender among established WordPress email marketing plugins like MC4WP: Mailchimp for WordPress (1 million+ installs), MailPoet (100k), Email Subscribers (100k), and Newsletter (300k). Creative Mail has a broader scope of features that it will be supporting, but it may be able to find success on the basis of Jetpack’s ubiquity.

What level of control should users have over their WordPress support forum topics? That is the question at the heart of a recent discussion opened by Mika Epstein on the Make Support blog. The goal is to grant more power to users, particularly when they post private or privileged information to the public forums.

The proposal is twofold. One idea is to give users total control over deleting or “archiving” topics they create. This would remove it from public view at least. The second part of the equation would extend the amount of time users have to edit their topics.

Currently, users can edit topics for one hour after posting. For the most part, this is reasonable. However, there are some cases where users inadvertently post sensitive data and need to remove it later. After their hour is up, the only solution for editing is to contact a forum moderator, increasing the burden on the WordPress support team. The easiest solution is to increase the length of time to edit.

The big downside to editing topics is that they can be changed so much that replies are out of context. This can make discussions, particularly, lengthier ones with more replies, hard to follow. However, given the nature of the WordPress forums being for support instead of long-form discussion, increasing the time-to-edit should not hurt. It should help users fix mistakes and lighten the load on forum moderators. There are proposals for increasing the limit between three to seven days.

In general, I am supportive of increasing the time-to-edit for forum topics. There is some room for abuse of the system, but such abuse will not likely outweigh the benefits. However, the ability to delete a topic does not sit well with me.

I see the problem. WordPress’s user base has changed over the past decade. The average user from 10 years ago was tech-savvy enough to not drop private info — or info they are not legally allowed to share — into public forums. The game has changed. Users are no longer webmasters, running every aspect of their sites. They are using one-click installs to launch software they have no technical knowledge of. They do not know the difference between a debug log and server info. This is not a bad thing — the more WordPress users the more we inch toward that democratize-publishing goal. However, the makeup of WordPress’s users has shifted drastically to a point where many may not realize they are posting information they shouldn’t.

The burden ultimately falls on forum moderators. They do all the cleanup, and it is likely overwhelming at times to keep up. It is a decision that should probably fall into their hands.

One of the catalysts for this discussion was a forum topic from last week. “Someone had posted information that isn’t exactly ‘private’ but could land them in legal trouble for sharing,” wrote Epstein. “They did so by posting a debug log that had information that probably should not be public.”

The WordPress support system has had a long-standing, in-house rule of not deleting posts except under extreme circumstances. However, the proposal would allow users to delete their own topics at any time.

I dislike the idea of removing support forum topics. The best form of support is to already have a question answered. This gives others the ability to search and find the answer to their own questions. It allows moderators to link to existing answers for repeat questions. Allowing users to remove topics means that others could miss out on free knowledge.

I ran a plugin and theme support forum for over a decade. It racked up hundreds of thousands of posts. I personally answered every question or made sure that each was answered by someone else. Over the years, the forums became a wealth of knowledge because, except in those extreme circumstances, no topic was ever deleted. Granted, my support burden was far lighter than that of the WordPress support moderators. However, past forum topics were an important tool in the arsenal.

Moreso than my time running support, I have relied on past support forum topics for my edification throughout the years. Rarely has there been a time I have needed an answer that I could not find through a basic support search. No need to hassle others with my already-answered questions.

I dislike the idea of deleting knowledge.

Of course, we must weigh this against privacy. I doubt many users would take advantage of the ability to delete their topics. In those rare cases when they do, I imagine they will have a good reason for doing so, such as hiding information they no longer want to share publicly. Still, the idea does not sit well with me. I want a balance of retaining knowledge while removing personal data.

I do have respect for privacy. There are steps WordPress.org could take. Users should absolutely be able to remove their own accounts from WordPress.org. Currently, they can remove any personal data from their profile, which is essentially the same thing. The one problem with this is if their username, which cannot be changed, identifies the person (e.g., I use justintadlock for many online accounts).

I would still take this the extra step and allow users to completely delete their accounts. This would be a clean sweep, ensuring they did not accidentally miss something when clearing out their profile. After doing so, their former topics in the forums should simply be assigned to an anonymous account. It doesn’t matter who created a particular topic, only that the content still exists.

What steps do you think WordPress.org should take to provide end-users more agency over their support topics?

Last Tuesday, iThemes announced it had acquired the Restrict Content Pro plugin from Sandhills Development. iThemes is part of the Liquid Web family of brands. Pippin Williamson, Managing Director at Sandhills, said the company had no intention of selling the plugin last October when talks of the acquisition began. However, moving forward has created some opportunities for his company and narrowed its focus to its existing products.

Restrict Content Pro will remain an independent product with its own website. However, iThemes will include it as part of its Plugin Suite and Toolkit product bundles from the iThemes website. The Plugin Suite bundle runs at $249 per year, which is the same as the regular Restrict Content Pro price. However, the bundle includes other products such as the company’s popular BackupBuddy plugin. The Toolkit bundle runs between $700 and $997 per year. It includes the Plugin Suite, a themes package, training, and more.

This structuring of product sites falls directly within the company’s long-term plans. “Earlier this year we actually started down a number of avenues experimenting with moving some of our products off ithemes.com and over to their own sites,” said AJ Morris, the Product Innovation and Marketing Manager at iThemes. “When COVID became a pandemic, we paused a lot of those projects to provide relief and help to the WordPress community. Now that things have calmed down for us a bit, we’re going to continue on that path.”

Outside of the change of ownership, end-users should not see much change with the plugin or the site. Users should expect some admin-side changes in the future as the new development team refreshes the plugin.

The Membership Plugin Space

Membership plugins represent a slice of the overall WordPress market that still has no true dominant player. There are several solutions out there, but it is still an emerging area that any company can dive into and see returns on with a solid product. It is a niche that will undoubtedly continue growing along with WordPress and has plenty of untrodden ground just waiting for the right people to take their first steps across. There will always be a need for more fine-tuned control over users and permissions than what WordPress offers out of the box.

“We are always in the market looking at other plugins that make sense for our business,” said Morris of why they made the acquisition. “Our audience is primarily freelance developers that are building a wide range of sites for clients. Over the years, we’ve focused on a number of non-utility products (like iThemes Exchange) and we learned a lot during that time. We’ve also learned a lot over the years of running our own membership site. For us looking at a membership plugin played with into the iThemes strategy and really the Liquid Web strategy as a whole.”

I spent nine years developing and maintaining a membership-related plugin but sold it in 2019. If there is one lesson I learned during that time, it’s that no two sites have the exact same membership needs. There is always room for individual companies to build a product that meets specific user needs in the membership space.

“What I feel like is everyone is currently trying to create the best Swiss Army knife,” said Morris. “I don’t think that anyone sets out saying I want to be good at all things, but when you’re developing a plugin that has so much possibilities for the market it serves, you have to feel out where you want to play and claim stake to that area. You become the best you can in that area and work at making sure you succeed there. Then you can start to properly branch out to other segments of the space that are within close proximity to where your core is.”

iThemes is stepping into the game at an ideal time. Restrict Content Pro is currently a $500,000+ per year product, according to Williamson. In the right hands and with continued growth, it could become the go-to solution for memberships in the WordPress ecosystem. iThemes has a solid history in the plugin space. This is a good opportunity to see where they take the project.

The Future of Restrict Content Pro

Morris said that Sandhills Dev already had a solid short to mid-term plan for the plugin. These plans are providing iThemes with a head-start on features and ideas, some of which are already in progress. The team’s plan is to continue down this path, which matches some of the areas the company wanted to address.

“After that, we’ve got some ideas, but we also want to get to know the community around Restrict Content Pro,” said Morris. “[Matt Danner] has mentioned in several places that the RCP community is more developer-centric while the iThemes community is historically not. Right now we’re in listening mode. We’re starting conversations all over the web with RCP customers to get a sense of what they are looking at and apply those learnings with where we want to take RCP in the membership space. Right now, I think it’s a bit premature to talk about specific features we’re including or what direction we’re fully going.”

The one area that is currently lacking is the free Restrict Content plugin. Its user base is still relatively small (10,000 active installs). Its average 3.7 star-rating from end-users does not spell confidence, but it could be brought up with some active work.

Restrict Content Pro has long had the benefit of being associated with Williamson and Sandhills Development’s other products like Easy Digital Downloads and AffiliateWP. All of these projects fit well together — often a user of one plugin needs at least one of the others. The pro plugin has likely not relied on the traffic from WordPress.org for success. However, it would not hurt to bring those numbers up. While the install count from the free version does not always directly correlate to success with commercial versions, it is usually a good indicator. Putting some resources behind beefing up the free plugin could translate to better returns in the long term.

Morris said that iThemes will be sharing news about the free Restrict Content plugin soon. However, he is remaining tight-lipped about what those plans are for now.

When you are making a new post or editing the existing one, click on the “Options” button in the top right that looks like this:

That will open the menu shown below:

Click on “Post Settings” to see the settings for your post. Inside the “Post Settings”, you can set tags and categories, add a featured image, set a publish date,  and more.

To make a new page, tap the  icon and select your site, select “Pages” in the Android Dashboard, then tap the  icon in the bottom-right corner. You can edit any page by selecting it from the “Pages” screen.If you are looking for your drafts or your scheduled pages, check the menu across the top of the page and select the “Drafts” or “Scheduled” tab to access the list of the pages.

To make a new post, tap the  icon and select your site, select “Blog Posts” in the Android Dashboard, then tap the icon in the bottom-right corner. You can edit any post by selecting it from the “Blog Posts” screen.  If you are looking for your drafts or your scheduled posts, check the menu across the top of the page and select the “Drafts” or “Scheduled” tab to access the list of the posts.

WordPress’ Support Team contributors are discussing how they can curb support requests for commercial products on the official WordPress.org forums. Users sometimes seek help for commercial product upgrades on the forums of the free version, not knowing that the moderators’ official policy is to refer them to the extension’s commercial support channel. In other instances, it is not immediately clear whether the issue is with the free version or a paid upgrade that the user has installed.

“This has come up a few times the past weeks, mostly in relation to plugins that have a free base product on WordPress.org, but sell addons on their own site, and where the line is drawn on who can get supported where,” WordPress contributor Marius Jensen said during the team’s most recent meeting. “Authors are not allowed to support their paid products on WordPress.org as is, but where do you draw the line, for example, when a base plugin causes issues with a paid addon, should then support be allowed for the base product on WordPress.org, since that’s the root issue, or should it be shipped off to the author’s own site, since it affects a paying user?”

This type of issue is common among products where WordPress.org is the main distribution channel for a popular free theme or plugin. The support relationship between the free and commercial products often intersects in an ambiguous way.

“The goal is to ensure that paying customers and free users get the best support they can, from the ones that can give it,” Jensen said. Volunteers do not have access to the commercial products, nor is it their job to support them. This is the crux of the matter.

“It’s an unacceptable misuse of volunteers time to support a product someone else has been paid to support,” Jensen said.

Contributors discussed how they can handle different scenarios where it’s unclear where the root of the problem is, in order to move the burden away from the support moderators, allowing the extension’s author to discern if the problem is with the free version or commercial add-on. Volunteers should not have to familiarize themselves with the minute distinctions between the features that are offered for free or as an upgrade.

On the other side of these support scenarios, where it isn’t clear where the problem originates, plugin and theme authors can be inconvenienced when support topics are hastily closed.

“It’s just that the closing of topics seems counter productive for those (users and devs alike) that get it wrong,” plugin developer Arnan de Gans said. “Since plugin/theme makers do not have any control over these forums we can’t do a thing after topics get closed. Which works against the user experience by creating confusion.” He suggested the team consider a grace period where the developer has a day or two to respond.

Ben Meredith, head of support for a freemium plugin, chimed in on the discussion, urging the support team to consider how closing issues can sometimes create a bad user experience:

An issue related to premium products is raised, and summarily closed by forum mods for being about a premium product. This creates a “googleable” record of the error message/problem that then attracts other visitors. Once the issue has been closed, we get copy-cat issues “I am having the same problem (link to closed post)” We get those replies in both followup forum posts and internal tickets. To the layperson who has no idea the distinction between “WordPress core volunteer” and “Company I just paid money to,” this creates a bad experience all around.

Premium users are treated like second-class citizens on the forums. They don’t know the guidelines, and reached out for help. This may be their first interaction with the WordPress community, and sometimes a well-meaning forum moderator can come across as wrist-slapping the exact people we want to give white-glove service to (they just paid us!).

Michelle Frechette, Head of Customer Success at GiveWP, also shared this sentiment regarding the user experience.

“Something I’m not seeing addressed much here is how alienating it can feel to be corrected by the mods (or even the plugin authors) to be directed from the forums back to the paid support page,” she said.

Ben Meredith said that despite sticky posts telling users not to post questions about commercial products, notes in the readme file, website notices, and canned replies, users will inevitably end up posting in the forums anyway. Steering them away to commercial support channels should be done in a way that does not make seeking help on WordPress.org an unwelcoming experience.

“I want for the forums to feel as welcoming as a WordCamp,” Meredith said.

“The current enforcement of the ‘premium plugins can’t get support here’ is not in line with that overarching goal: users using and enjoying WordPress. Currently, premium users (who are potential community members and community leaders!) are getting a first impression of the community that is ‘You’re doing it wrong!’

“I’d rather their first impression be ‘Happy to help! heads up, for questions like this in the future, we need you to go here.'”

In trying to ease the burden placed on volunteer support forum moderators, it’s important to consider how any new policy might also negatively impact developers hosting their plugins and themes on WordPress.org, and what kind of vibe the response gives to users in search of help. There are more suggestions for solutions in the comments on the post, and the discussion is open until Saturday, September 12, 2020, 07:00 PM CDT. The Support Team is seeking to get a wider range of viewpoints from plugin and theme authors before making a final decision on new guidelines for addressing requests for support on commercial products. Make sure to jump in on the comments within the next week if you have something to add to the discussion.

On Wednesday, September 2, Gutenberg 8.9 launched with a set of new features, enhancements, and several bug fixes. The development team took the block-based widgets system out of its experimental stage, making it the default experience for all plugin users.

Block-based widgets have taken months upon months of work. The team has surpassed some of my expectations by essentially sticking a square peg into a square hole, granting the power of blocks to the sidebars/widgets system. On the whole, the system works. However, the team still has a lot of work to mold this feature into the shape it needs to be in for the upcoming WordPress 5.6 release in December. It is important that the community at large test, provide feedback, and contribute where possible.

Gutenberg plugin users who have not yet enabled block-based widgets via the experiments screen in past versions will be in for a surprise. The new system will have some of the familiarity of the block editor. However, it is a much different experience than traditional widgets.

The big questions we must answer is whether the feature is currently usable and whether it can be ready for WordPress 5.6.

New Widgets Screen

Block-based widgets screen.

Gutenberg completely replaces the old Appearance > Widgets screen in the WordPress admin. The plugin no longer has an option for end-users to disable it, which was expected. The goal is to begin getting users accustomed to building their sidebars with blocks rather than traditional widgets.

For the most part, the new widgets screen handles block-based widgets without issue from a usability perspective. Adding blocks is little different from working with the post-editing screen. It should feel relatively natural for users who are accustomed to the block editor. If anything, the experience seems scaled down in comparison.

Unlike widgets in the past, blocks cannot be collapsed (the sidebars themselves can be). As a long-time WordPress user, this feels uncomfortable. However, it is the sort of uncomfortableness that will simply take some adjustment time.

Core legacy widgets worked well. However, I could not get legacy widgets to work from several third-party plugins. Sometimes, they disappeared from the editor. Then, they would later appear, seemingly at random. Eventually, during testing, I completely broke the page to the point where it did not display anything. Fortunately, I was able to fix it by clearing out a few widget-related rows from the database.

As a developer, I want to simply wipe the slate clean and leave the old widgets system in the dust of history. However, doing so may very well alienate many end-users. For this feature to be successful, we need to carry them along and allow them to easily transition from their current tools to the new system.

Widget Blocks in the Customizer

Widget blocks section in the customizer.

While the primary widget blocks screen was generally solid, that was not the case with widget blocks in the customizer. At best, it was sub-par.

We may finally be at that point where I agree with all those earlier complaints of the customizer control panel being too narrow. The most obvious issue was that the block toolbar was too wide for the control panel, hiding pieces of it off-screen. For some blocks, there are buttons that users cannot access.

That is not the end of the issues. Block options are unavailable, so users cannot even add something as basic as an image alt attribute. The core legacy widget blocks are not editable. The “more options” button popup has a transparent background, making the text unreadable and, for all intents and purposes, not worth attempting a use.

I understand that WordPress is still far from launching widget blocks in the customizer, but the feature was practically unusable. It is still very much in an experimental state and probably should have remained optional for another plugin update or two or three. I cannot recommend using this within any sort of production environment. Stick with the widgets screen in the admin.

Widgets/Blocks Styling Issues for Theme Authors

No structured grouping of “widget” HTML.

One of the largest changes that theme authors need to be aware of is that blocks in sidebars do not have the typical widget HTML wrappers. This could present some issues with styling widgets in the traditional fashion. For example, themes usually register a widget wrapper element and a wrapper for the widget title. This allows theme authors to build consistent styles for each widget. With blocks, this becomes much tougher because the theme author loses that control — this control is passed to the end-user.

The great part of this system is that users can do some really interesting things and have the flexibility to style their sidebars in any way they want. The bad part is that if a theme author has any sort of intricate styles, such as a boxed widget design, there is no easy way for the end-user to simply drop widgets into place and have them all use that boxed design. There is no standard class name for the theme author to target with CSS, which is what is required for consistently-styled widgets.

This is not necessarily a good or bad thing in and of itself. It is simply different.

With that said, I would have much preferred the Gutenberg development team created a new and separate system from the old sidebars/widgets system. Leave that in place, then build and promote “block areas” as a new system for theme authors to take advantage of. In the long run, it would allow theme authors to make the transition and even potentially support both systems in their themes. Theme authors are down in the trenches, working with their users on a day-to-day basis. They are in a much better position to handle the transition from old to new.

Theme authors who are not prepared to go all in with block-based widgets in WordPress 5.6 can add the following line of PHP to their theme’s setup code to disable the widgets block editor:

remove_theme_support( 'widgets-block-editor' );

Over time, theme authors will want to fully transition to the new system. However, this will provide additional time for them to make any adjustments that may be needed with how widgets are handled.

Sunlit 3.0 was released this week and is now available in the App Store. The free photoblogging app is a companion app to the Micro.blog indie microblogging platform. Sunlit has some similarities to Instagram minus the deadweight of ads and algorithms. Users can follow each other, comment on posts, and timeline photos are displayed in chronological order.

“The idea is to get more people posting photos to their own blogs, whether that’s hosted on Micro.blog, WordPress.com, or a self-hosted WordPress,” Micro.blog creator Manton Reece said. Publishing to WordPress does not require any extra plugins, because the app uses the built-in XML-RPC support.

Sunlit uses Micro.blog’s infrastructure for the social aspect (replies and mentions). Users must be signed into a Micro.blog account (either paid or free) to view the timeline or reply to posts. In the current version, users are required to go to Micro.blog on the web to register first but Reece said his team is aiming to make this more seamless in the future so users can start using all the features in Sunlit right away.

“Some people use Micro.blog for their blog exclusively, and some people have a mix of a microblog or photoblog on Micro.blog, as well as a full blog on WordPress,” Reece said.

Sunlit also has support for following Tumblr photoblogs. In the app’s Discover tab, users can enter a Tumblr subdomain like “username.tumblr.com,” and then follow the blog even if the user is not on Sunlit.

“Micro.blog is based on blogs and IndieWeb standards so that it can integrate well with the rest of the web, not be walled off like a silo,” Reece said. “One aspect of this is that you can follow many blogs in Micro.blog even if the author of the blog hasn’t registered on Micro.blog yet, similar to how you can subscribe to blogs in a feed reader like NetNewsWire or Feedbin.”

Sunlit 3.0 has been redesigned with a new Discover interface and a faster, more flexible posting screen. Users can publish a quick photo or even a full blog post with text and photos uploaded to the users’ blog, along with the HTML layout for the post. This version also includes user search and support for mentions when replying to conversations.

Micro.blog is currently supporting the app’s development, and Reese said he has no plans to add any commercial upgrades into Sunlit.

“We support Sunlit as part of running Micro.blog,” he said. “Sunlit makes an existing Micro.blog subscription more useful, so it helps with the overall platform sustainability, even if not everyone using Sunlit is paying for a subscription. We hope that more people will sign up for a paid Micro.blog subscription, but it’s not required.”

Sunlit does not have an Android app but the teams would like to support Android in the future. The app is open source and available on GitHub under the MIT License.

“Because Sunlit for iOS is open source, this [Android support] might be something that comes from the community or it might be something we take the lead on. I personally have much more experience with iOS, so we started there.”

On May 4, the StudioPress development team made a small but significant user-facing change to its Atomic Blocks plugin (now rebranded to Genesis Blocks). It removed the “AB” branding from its block titles. This minor update changed block titles such as AB Accordion and AB Button to Accordion and Button, respectively. On the surface, this change probably seemed of little consequence to the developers on the project. However, for at least one user, it created a massive workload.

Unless users religiously followed the GitHub code commits, they would have missed this update. Stacked with several other code changes for a seemingly unrelated ticket, the team left a message that read, “Remove unnecessary ‘AB’ from block titles.”

The change made it into version 2.8.2 of the plugin, which launched a day later.

The problem was that there was no message in the change log that noted this. Users had no indication that the blocks from the plugin were being renamed. Typically, this would not be a big deal since the plugin team had merely dropped the “AB” prefix from the otherwise unchanged titles. However, what happens when one of those blocks’ titles matches a core block title?

That was the issue that Marcus Tibesar ran into. The AB Button block suddenly became the Button block. Thinking he was using the core WordPress Button, he made liberal use of it throughout his site. Throw in his decision to drop the plugin after StudioPress rebranded its plugin to Genesis Blocks, it became a bit of a disaster to clean up.

“I have been using the Button block for months now only to discover that I’m actually using the Atomic Blocks button block!” wrote Tibesar in a comment on the Atomic Blocks rebranding post.

Theoretically, he should have needed to update only any lingering blocks from Atomic Blocks that he had knowingly used. But, he was stuck with blocks that he had unknowingly added to his posts and pages through no fault of his own.

This particular scenario was made worse because WordPress 5.4, released on March 31, introduced a new Buttons (plural) block. The old single Button block was removed from the normal inserter. While not all block-naming issues are so convoluted, it still begs the question: how can plugin authors avoid causing these types of user-experience issues?

It is easy to throw blame toward StudioPress — and the team could perhaps use a scolding for not being clear about the change when it happened. However, this brings forth a couple of things the greater WordPress community needs to figure out. The first is whether plugin authors need to use a consistent, prefixed naming scheme for their blocks. The second is what can WordPress do to help mitigate issues.

Prefix All the Things

Buttons, buttons, and more buttons.

That is the common saying in the WordPress development world, right? Prefixing and namespacing guidelines generally apply to the actual code, which is where conflicts arise. However, there are times when prefixing public-facing text is warranted.

And those times are when plugins utilize a shared space.

The block editor is one such shared space. With more and more block plugins landing in the directory, it is time that plugin authors consider how block-naming schemes affect end-users. The issue is certainly not limited to Atomic/Genesis Blocks. This has been an ongoing trend with several block library plugins. Some do better than others, but it’s a toss-up each time a user installs such a plugin.

The easiest route is for plugin authors to simply prefix all custom blocks with their company branding (e.g., AB Button). On the other hand, not every block shares a title with one of the core blocks. For example, a block titled Product Carousel may not need to distinguish itself further from other blocks. It is unlikely that end-users are running multiple eCommerce plugins with blocks that share the same title.

“All, repeat all, should have a prefix,” said Tibesar. “The prefixes eliminate any confusion as to whether we users are selecting a core block or a third-party block. The most popular plugins appear at the top of the list, and it’s confusing from whence they came when prefixes are absent.”

At the very least, third-party blocks should have a prefix if their titles match one of the core blocks. End-users should not see two different Cover blocks in the block inserter, for example. Instead, they should see the core Cover and a second, uniquely-titled block. Prefixing is an easy way to do that. But, I could live with anything that does not cause user confusion.

Locating Instances of Block Usage

Manage Blocks screen.

In late 2019, the Gutenberg team released the first prototype of a potential block management area for the WordPress admin. The Manage Blocks screen from the prototype showcased an area that would allow users to manage every block on their site. One of the more important bits of information on this screen was an “Instances” count, which displayed the number of times a block was in use. It further linked to a screen with every post that had a particular block.

One of the reasons this feature is important is that it would allow end-users to locate posts that they may want to clean up. Using the Atomic/Genesis Button block as an example, Tibesar could track down all those old uses and make any changes he wanted.

He said he would absolutely welcome this feature in WordPress. “New users are tempted to load up on zillions of block plugins all to be forgotten later. Also, maintainers would use this tool when cleaning up broken sites. Just being able to see an overview of what blocks were used where, will allow publishers to dial back the number of block plugins installed on their sites, especially when new plugins and technologies emerge.”

Because this feature is not in core yet, he had to turn to the Find My Blocks plugin, which helped him identify 22 posts and pages where he had unknowingly used the Button block from Atomic/Genesis Blocks. In the long term, this is something that needs to be handled directly in WordPress. It is unlikely to be the last time a user needs to clean house and get rid of old blocks.

WordPress 5.5.1 was released yesterday with 34 bug fixes, 4 enhancements, and 5 bug fixes for the block editor.

Version 5.5 removed 19 legacy JavaScript localization objects, in favor of using the new functions and utilities found in the i18n package introduced in WordPress 5.0. One of the most notable changes in this maintenance release is the inclusion of a backfill for these now deprecated JavaScript globals, which were causing errors with many popular plugins and themes.

“If we only count plugins or themes with more than 100k installs or more, some of these already have an incredible impact, which is why we decided to patch this as fast possible.” Joost de Valk said in an update compiling a list of affected extensions, with the the help of Omar Reiss.

Themes impacted include Astra (1 million+ installs), Storefront (200k+), Hestia (100k+), and dozens more. A small selection of the popular plugins that were impacted include Advanced Custom Fields (1 million+), SiteOrigins Widgets Bundle (1 million+), AMP for WP, (100k+), WooCommerce Services (1 million+), Ocean Extra (600k+), and Rank Math SEO (400k+).

Theme and plugin developers still need to update their code to use wp.i18n but in the meantime the legacy code will not block JavaScript execution. De Valk said the new plan is to remove this fallback code in two major versions, so developers need to have their code updated by the time WordPress 5.7 rolls around in 2021. 

“It sounds like a question that also ought to be addressed is how such wide-spread breakage could happen, and how it can be prevented in future,” David Anderson commented on the announcement regarding the backfill. “What part of the release process ought to have flagged up that this was about to happen, how did that part fail, and how can future similar failures be prevented.” Jake Spurlock suggested a retrospective on WordPress 5.5 might be a good idea.

Three weeks after WordPress 5.5 was released, the Enable jQuery Migrate Helper has more than 100,000 active installs. The plugin is available as a stopgap for users who experience problems with jQuery after updating to WP 5.5. Although several bumps along the road are expected for users during WordPress’ process of updating to use the latest version of jQuery, the official support forums were inundated with reports of broken sites after 5.5 was released. Many users found out about the plugin after hours of troubleshooting and hunting for a fix. This is another issue that would be helpful to address in a 5.5 retrospective.

This maintenance release also removes the ability to alter the list of environment types in the new wp_get_environment_type() function. Contributors decided that introducing new types wasn’t the intention of the feature and that it makes it so that theme and plugin developers cannot rely on a set, predictable list of types. They are now limited to production, staging, development, and local, with definitions for each available in the announcement.

“By limiting the set of environment types in this way, WordPress core, plugins, and themes can change their behavior depending on this setting,” Joost de Valk said.

WordPress 5.5.1 also fixes XML sitemaps paginating incorrectly, adds the site environment to debug information, and improves a number of other features that shipped with defects. The full list of changes is available on the release page.