Tag Archives: WordPressorg

WordPress.org Experiments with Rejecting Plugin Submissions with the “WP” Prefix to Mitigate Potential Trademark Abuse – WP Tavern

[ad_1] Many in the WordPress developer community were surprised to learn that WordPress.org is rejecting plugins with the “WP” prefix in the name after Joe Youngblood tweeted the rejection note he received. Although that restriction was put into place approximately seven months ago, there was no official communication on the change. WordPress is now claiming that the @WordPress Foundation has demanded that the developers stop allowing "WP" to be used in plugin names. pic.twitter.com/FyyPJoqXmd — Joe Youngblood (@YoungbloodJoe) August 13, 2021 As the result of the controversy gaining attention on social media and other channels, WordPress Plugin Team member Mika Epstein posted an explanation on the original meta trac ticket, the reasoning for how and why “wp” is being blocked: Using wp- at the beginning of plugin permalinks, yes. Due to how we built this out, the display name is what gets checked and flagged. You can use WPPluginName (no space) and Plugin Name for WP. This stems from part of a longer conversation going on with the Foundation, regarding handling the actual misuse of ‘WordPress’ in plugin names (which, as we all know, is actually trademarked and as such should not be used in your plugin name at all). Because using WP Blah Blah as a name tends to lead to people changing it after approval to “WordPress Blah Blah” we put a pause on it to try and get a handle on how bad is this, what’s the depth of the problem (vs the actual headache of WC -> WooCommerce in names) and so on. There is also the reality that using ‘WP’ or ‘Plugin’ in a plugin permalink is unnecessary and can be harmful to SEO due to repetitive words. No one is claiming WP is trademarked, we’re just trying to minimize confusion and prevent people from accidentally violating trademarks in the future because they change WP to WordPress later on. Whether or not “wp” was trademarked became a particular point of confusion because the commit message on the change said: “Adding in some more things to block based on use and trademarks.” The conversation with the WordPress Foundation that Epstein was referencing was a private discussion about how the team can mitigate trademark abuse. “This came up in the midst of an ad hoc brainstorm about the ways that the loophole could be more effectively managed, and so there wasn’t a lengthy public discussion on it,” WordPress Executive Director Josepha Haden Chomphosy said. “It was part of an experiment for handling that loophole more effectively and wasn’t meant to be permanent. The great thing about experiments in WordPress is that when we see that we’re throwing out the good along with the bad, we can make the necessary changes to do it better.” Haden Chomphosy said that although the original discussion was private, the team plans to make it public via the new meta ticket that was opened yesterday for improving the checks on plugin submissions. “All future discussions will be on the ticket, so as people work on it, then the conversations will be available there,” she said when asked how the trademark abuse mitigation experiment will be evaluated. The WordPress Foundation does not have any employees, but Haden Chomphosy said the representatives who can help with the grey areas of trademark guidelines include herself, Andrea Middleton, and Cami Kaos. She also confirmed that “WP” is not a WordPress trademark and the Foundation is not pursuing trademarking the term. Although each of these individuals referenced have a long track record of protective care for the WordPress community and have demonstrated a sincere desire to see the project grow, they are all employed by Automattic. The Foundation could use some outside representation if those running it are engaging in private decision making and giving directives to the WordPress.org Plugin Team that have significant ramifications for the ecosystem as a whole. For years, the WordPress community has been encouraged to use WP instead of WordPress in plugin names, so the decision to reject plugins with WP in the name is a major, controversial change. The problem for me is 1. you are penalizing everyone for something a few people do. 2. it doesn’t actually fix the problem because I could change any of my plugin names to WordPress after the fact and 3. There’s NO official announcement explaining this. — Brad Williams (@williamsba) August 17, 2021 Those who oppose the current experiment have pointed out that it unfairly penalizes everyone for the few who change their plugin names after approval. It polices potential misuse instead of providing a solution that can flag actual trademark abuse. Some plugin developers have noted that having WP in the plugin name is necessary to differentiate it from extensions for other platforms, since WordPress.org is not the only place where their products are distributed. Many successful businesses have been created on top of plugins with WP as a prefix in the name, such as WP Mail SMTP, WP Fastest Cache, WP Migrate DB, to name just a few. Whether it is beneficial or detrimental to use WP in a brand’s name is immaterial to the discussion at hand. With the current trademark abuse mitigation experiment in place, all new plugin developers hoping to use the WP prefix will have their plugins rejected. Fortunately it isn’t retroactive, but if the team decides the experiment of banning WP in plugin names is a success, it may be up for discussion. Springing experiments on the community without publicly communicating the intent is a misstep for the Foundation. If allowing WP in the name creates wrong expectations for plugin developers regarding their ability to change the name to use WordPress, then the problem needs to be fixed at the root. WordPress.org needs to find a better way to inform developers about which terms are actually trademarked and develop a technical solution to flag name changes that do not comply. This may be a difficult technical problem to solve regarding plugin submission and updates, but it’s worth investing

Continue reading

The WordPress.org Block Pattern Directory Is Now Live – WP Tavern

[ad_1] Yesterday, the WordPress pattern directory went live to the world as the development team behind it put the finishing touches on the project. It will work similarly to the theme and plugin directories in time. Along with WordPress 5.8, users can browse and use block patterns directly from the post editor. Officially, the pattern directory shipped as part of the WordPress 5.8 release. The Tavern did not include this in its coverage yesterday because it was still listed as an “in-progress” project until several hours later. The team was still wrapping up several issues yesterday for the initial launch. Pattern directory homepage. The current patterns in the directory are a curated list of designs from over 20 volunteers. The team called upon the community in early June, and it answered. To date, there are over 70 patterns across six categories to choose from: Buttons Columns Gallery Header Images Text Thus far, translations are complete for 12 languages. Others are at varying completion percentages, but there are dozens more that are incomplete. This would be an easy entry point for anyone who wants to give something back to the WordPress project. I had a hand in building the About Me Cards and Team Social Cards patterns, but I cannot take all the credit. Kjell Reigstad and Mel Choyce-Dwan took my initial ideas and ran with them. It was a rewarding experience just peaking a bit into how other designers work. I only wish I could have put in more time during the initial submission window. About Me Columns (left) and Team Social Cards (right) patterns I look forward to submitting more patterns when submissions are open to everyone, the project’s next phase. “Work is now beginning on the next milestone, which will enable patterns to be submitted by anyone, similar to the Theme and Plugin Directories,” wrote Kelly Choyce-Dwan in the announcement. I am excited to see where the overall community can take the directory. Submissions have been limited and held to a specific aesthetic that will not be universally appealing. It may be hard for some users to look beyond centuries-old artwork, flowers, and the current fling with offset columns to see how a specific layout would work for their site. For others, it is perfect. Even I struggle with this. I can see the structure beneath the default images and text, but I am not inspired to use most of the patterns because they simply do not fit my personal style. When selecting one, I want to feel like the designer was building something just for me. I suspect that will play a part in winning over more users and bringing some holdouts over to the block system. Gallery-categorized patterns. One limitation of the pattern directory is the imagery. Now that services like Unsplash, Pexels, and Pixabay have put limitations on their licensing, it can be tough to find photos and artwork that meet the guidelines for submissions to WordPress.org. However, that could open up a bit with the potential integration of Openverse, formerly the Creative Commons search engine. Making it easier for pattern designers to find the perfect images to build out their visions would improve the overall quality. What will eventually make the pattern directory a worthwhile venture is when the best designers from the WordPress ecosystem step up and begin competing. I eagerly await a breadth of authors putting their own stylistic spin on submissions. Like this: Like Loading… [ad_2] Source link

Continue reading

WooCommerce Patches Critical Vulnerability, Sending Forced Security Update from WordPress.org – WP Tavern

[ad_1] WooCommerce has patched an unspecified, critical vulnerability identified on July 13, 2021, by a security researcher through Automattic’s HackerOne security program. The vulnerability impacts versions 3.3 to 5.5 of the WooCommerce plugin, as well as version 2.5 to 5.5 of the WooCommerce Blocks feature plugin. “Upon learning about the issue, our team immediately conducted a thorough investigation, audited all related codebases, and created a patch fix for every impacted version (90+ releases) which was deployed automatically to vulnerable stores,” WooCommerce Head of Engineering Beau Lebens said in the security announcement. WordPress.org is currently pushing out forced automatic updates to vulnerable stores, a practice that is rarely employed to mitigate potentially severe security issues impacting a large number of sites. Even with the automatic update, WooCommerce merchants are encouraged to check that their stores are running the latest version (5.5.1). Since WooCommerce backported this security fix to every release branch back to 3.3, store owners using older versions of WooCommerce can safely update to the highest number in their current release branch even if not running the very latest 5.5.1 version. At the time of publishing, only 7.2% of WooCommerce installations are using version 5.5+. More than half of stores (51.7%) are running on a version older than 5.1. WordPress.org doesn’t offer a more specific breakdown of the older versions, but it’s safe to say without these backported security fixes, the majority of WooCommerce installs might be left vulnerable. The security announcement indicates that WooCommerce cannot yet confirm that this vulnerability has not been exploited: Our investigation into this vulnerability and whether data has been compromised is ongoing. We will be sharing more information with site owners on how to investigate this security vulnerability on their site, which we will publish on our blog when it is ready. If a store was affected, the exposed information will be specific to what that site is storing but could include order, customer, and administrative information. For those who are concerned about possible exploitation, the WooCommerce team is recommending merchants update their passwords after installing the patched version as a cautionary measure. The good news for WooCommerce store owners is that this particular critical vulnerability was responsibly disclosed and patched within one day after it was identified. The plugin’s team has committed to being transparent about the security issue. In addition to publishing an announcement on the plugin’s blog, WooCommerce also emailed everyone who has opted into their mailing list. Concerned store owners should keep an eye on the WooCommerce blog for a follow-up post on how to investigate if their stores have been compromised. Like this: Like Loading… [ad_2] Source link

Continue reading

WordPress.org Meta Team Fixes Search Snippet Issue with Download Page Promoting WordPress.com – WP Tavern

[ad_1] Yesterday evening Chris Klosowski, Sandhills Development Partner and Director of Technology, tweeted out a problem with the way WordPress.org’s Download page was appearing in Google’s Search results snippets when searching for “WordPress.” Underneath the link, the preview text referenced WordPress.com’s hosting: WordPress.com is the easiest way to create a free website or blog. It’s a powerful hosting platform that grows with you. We offer expert support for your WordPress site. Others reported seeing the intended description when Googling, which is designated in the Schema.org tag in the head tag but not printed on the page: “Download WordPress today, and get started on creating your website with one of the most powerful, popular, and customizable platforms in the world.” The reference to WordPress.com came from the hosting providers listed at the top of the page, where it randomly displays two upon each page refresh. The Download button used to be at the top of the Download page but ever since mid-January 2021, it has been pushed further down below recommended hosts. This is presumably to help people who want to set up a self-hosted site but don’t know where to get started. “Google was skipping our defined page descriptions in favor of some in-page content,” WordPress lead developer Dion Hulse said, regarding the issue with the search results snippet. The WordPress Meta team was alerted to the problem and quickly put a solution in place to encourage Google to look somewhere else on the page for the main content. “The Download page has info about the mobile apps and hosting for WordPress,” core contributor Corey McKrill wrote in the commit message. “These are in section container elements, which might be the reason that Google is using the content of the hosting container for its search result snippet, instead of the meta description tag. By changing these containers to aside elements, hopefully Google will get the message that they don’t contain the most pertinent information for that page.” The meta team also marked the hosting recommendations on the download page as exempt from being included in the Google search result snippet, so that it doesn’t pull text from these aside elements. Here is what the updated search result snippet looks like after the changes were put in place: Klosowski’s tweet highlighted the perennial tension that arises from the confusion between WordPress.com and WordPress.org. The recommended hosting page has always been a contentious bit of real estate on WordPress.org but especially now that hosting companies are also prominently promoted on the Download page. https://twitter.com/cklosowski/status/1413264854643736577 In this situation, Josepha Haden Chomphosy, WordPress’ Executive Director, quickly acknowledged that the search snippet promoting WordPress.com was in fact a problem, heading off those who might promote the notion that it was intentional. The Meta team acted swiftly to resolve the issue and return the snippet to its former meta description. It is not known how long Google has been pulling from the text in the recommended hosts sections to populate the snippet, but the code is now more explicit about the fact that those companies are not the most important content on the Download page. Like this: Like Loading… [ad_2] Source link

Continue reading

Automattic Launches Mayland Blocks, Its Second FSE Theme on WordPress.org – WordPress Tavern

[ad_1] Automattic released its second block theme to the WordPress theme directory last week. Mayland Blocks is geared toward photographers and other users who want to showcase their projects. It is the child of Blockbase, a sort of starter/parent hybrid the company’s Theme Team recently announced. I had high hopes for Mayland Blocks going in. I have kept a loose eye on its GitHub repository in the last couple of months. It was one of the first 100% block-built themes the team seemed to be working on. While block themes are still experimental at this stage, I was admittedly disappointed. Maybe my expectations were too high. I was eager to be wowed when I should have gone into this review more level-headed. However, I am who I am, and that is someone who is genuinely excited each and every time a new block theme comes along. I am ready for the next big thing, but Mayland Blocks did not fit the bill. As I began the process of testing the theme, the first order of business was to recreate the Masonry gallery as shown in the theme’s screenshot: Expected gallery layout from Mayland Blocks My first thought was that the default gallery output would automagically work. It did not. Then, I looked for a Gallery block style. Nothing there. I searched for a custom pattern. Nothing there either. In short, it was impossible to recreate the gallery shown in the theme’s screenshot — one of the primary features that drew me to it. Bummer. I was looking forward to seeing a Masonry-style gallery of images built on top of the block system. Standard gallery output with Mayland Blocks. With a tiny bit of sleuthing and peeking under the hood of the theme’s demo on WordPress.com, I saw that it was using the CoBlocks plugin by GoDaddy. The thing that made the theme special had nothing to do with the theme. After a quick install, I converted my existing gallery to the CoBlocks Masonry block. Success! Masonry gallery output via CoBlocks. At that point, I began to wonder why I was even testing Mayland Blocks at all. Its claim to fame hinged on showcasing photography. The core Gallery block works well enough, and I can use CoBlocks with any theme. Most decent ones provide the sort of open-canvas template that is no different than Mayland’s front page. What would have made it a great theme would have been living up to its screenshot’s promise. This was also a missed opportunity to showcase some alternate Gallery block styles and patterns. If we want more users to buy into this system, some of our best design and development teams need to take that one extra step. For such a simple theme, one well-suited as a one-page design, this was the moment to lean into the photography angle. Provide users a Polaroid picture frame option: Add a “no gutter” block style: Bundle a few patterns that combine the Gallery block with others. Give us a little flavor. Mayland Blocks works well as a WordPress.com child theme because its suite of plugins is available to all users out of the box. For a publicly-released project on WordPress.org, it is a little disappointing that it was a straight port. The child theme is essentially its parent with an open-canvas front page template and some trivial font and color changes. Surprisingly, it made it into the theme directory with so few alterations. Two days later, another child theme was outright rejected for just adding “some minor changes which can be made directly from the parent theme.” The inconsistent application of the guidelines by different reviewers has long been a thorny issue, especially when more subjective rules come into play. However, block themes have more wiggle room at the moment. There are so few for users to test that it makes sense to let things slide. One of the Themes Team’s previous hard lines has been that bundled front page templates must respect the user’s reading settings. This meant that if a user explicitly chose to show blog posts on their front page, the theme must display those posts. Mayland Blocks is the first that I have seen get a pass on this, a hopeful sign of more leeway for directory-submitted themes in the future. Block themes are a different beast. HTML files are not dynamic, and there is no way to put a PHP conditional check in a front-page.html file in the same way as themers once did in a front-page.php template. There is a technical workaround for this, but I do not think it is necessary. Block themes are changing the game, and the guidelines will need to follow. I love seeing the contribution — any contribution, really — of another block theme to WordPress.org. However, I want to see more artistry on top of the Blockbase parent theme. Like this: Like Loading… [ad_2] Source link

Continue reading