[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 readingTag Archives: plugin
A Second Look at ElmaStudio’s Aino Theme and Companion Block Plugin – WP Tavern
[ad_1] I am about a month away from my second anniversary writing for WP Tavern. There has been one project that I have followed since the beginning of this journey. In some ways, we are learning the ropes and growing in this block-based WordPress era together. In 2019, just before taking on this role, one of the first story notes I jotted down was some thoughts on ElmaStudio’s Aino Blocks plugin. However, it was not until nearly a year later when the team took the project out of beta testing, and I followed up with a review of the flagship Aino theme and plugin. Perhaps it is fortuitous that the team recently released version 2.0 of its theme at just about the same time I started taking stock of my time at the Tavern. Maybe this is fate’s way of telling me that we should always have a yearly update on Aino — sound like a good idea? It also did not hurt that Matías Ventura, the Gutenberg project lead, name-dropped their work in a conversation we had last week. “It fills me with joy when I see initiatives like [Aino] built by just a couple folks,” he said. “Apart from the user aspects of our work, it’s what makes it all worth it.” This was part of a more in-depth discussion related to the barriers to entry in the modern WordPress era. We agreed that one of the easier onramps was theme creation and site design, a focus area for Aino. It was time to dive back into the project. I had not looked into it deeply enough since my last review a year ago. Admittedly, at the time, I had mixed feelings about it. I initially thought the plugin launched too late. It seemed to be yet another block library after larger companies beat them to the punch. Ellen Bauer, who co-owns the company alongside Manuel Esposito, encouraged me to check back in as they continued building. They were merely setting the stage for their vision. “We wanted to release the Aino blocks and theme on WordPress.org since they are stable to use right now,” she wrote in the comments. “But the actual work is just starting for us, since we are now creating block patterns for our system, and I think it is only then that users will see why we built the theme and blocks in a certain way.” A Year Later One of multiple feature patterns from the Aino theme. The ElmaStudio team is taking that leap that most theme companies will inevitably need to take. They announced that Aino 2.0 ditched its classic garb and moved to 100% blocks earlier this month. For this particular theme, the move was not as monumental as it would be for others with more intricate layouts. Aino itself was always a minimal design, more of an open canvas for blocks than anything. It is the sort of theme meant to get out of the way and allow the user to create individual pages from the ground up. That may have been its downside a year ago. The team had built a plugin for easing users into the page-building process, but its single block pattern did not provide much of a starting point. Its Grid block is a powerful tool but also feels like it is catered more toward designers/developers. Its options may be too advanced to some end-users depending on their familiarity with CSS terminology. Today, this looks much different. The Aino theme comes with — count ’em — 42 block patterns. It is also where this project shines. I may have mentioned something about this being the route to go last year: The company’s best bet is to focus on building patterns. Its first pattern shows some promise. I am holding out hope for more interesting work to come. The team took that dev-friendly base of the Grid block and built a system of easy-to-use layouts on top of it. Users merely need to click to insert and customize. Aino’s Grid block used in a portfolio pattern. Because Aino’s patterns are built upon this grid foundation, the design studio’s layouts are fine-tuned for each screen size. Unless other theme authors build on top of the same plugin or a similar grid-based block, they are left with stock WordPress/Gutenberg. This provides limited options for responsively designing more complex layouts. This should be a focal point of the WordPress 5.9 release cycle, but it could be a while before we have something as powerful as the various grid blocks available via plugins. ElmaStudio’s groundwork in the previous two years is bearing fruit, at least in terms of what the team can create. With the foundational elements in place, nothing should stop them from building the next 42 patterns and more. A team pattern from the Aino theme (also built on the Grid block). I am still lukewarm about most of the blocks in the plugin, think the Hero and Testimonial blocks should just be patterns, and the [Aino] Buttons block should be an options extension for the one in core. The Grid layout is the feature that all the best things about the Aino project hinge on. The Aino theme itself seems unimpressive on its own, at least at first glance. However, the project is not whole until it is coupled with the Aino Blocks plugin. The theme needs some design work on its default spacing. For example, paragraphs that follow a wide or full-aligned block have no gap above them. Blockquote text butts against the side of the left border. Trivial bugs like these are easy fixes. Sometimes, it is not evident that there is an issue until a Gutenberg plugin update, which often leaves theme authors chasing changes. Such is the life of a designer living on the bleeding edge, supporting the latest features via a block theme. I am happy I once again had the opportunity to dive back into the Aino project. A year
Continue readingGoogle Site Kit Plugin Ships Hot Fix for Critical Error That Caused Broken Websites – WP Tavern
[ad_1] Google published an update to its Site Kit plugin for WordPress this afternoon with a hot fix for a critical issue affecting an unknown number of users. Reports of broken websites were popping up on Twitter and in the plugin’s support forum on WordPress.org. Users affected by the issue reported having a critical error on all sites using Site Kit, which forced deactivation of the plugin in recovery mode. In some cases it prevented them from accessing their dashboards. “On Wednesday, August 11, we identified a fatal error in the Site Kit plugin that could be triggered by other plugins or themes using an unprefixed version of Composer,” Google Site Kit Support Lead Bethany Chobanian Lang said in a pinned post on the support forum. Version 1.38.1 contains a hot fix for this issue, since it was critical enough to take down users’ websites. The plugin’s maintainers began investigating the issue less than 24 hours ago but are still not sure which plugins trigger the error due to their usage of Composer. “The reports do not include which specific plugins or themes were causing this, but the error message clearly highlighted the code in Site Kit that was the problem,” Google Developer Relations Engineer Felix Arntz said. “Technically, that problematic code had been in Site Kit since several versions ago (months back), so maybe another plugin/theme recently got updated with new code that exposed the problem.” After looking at popular plugins, Arntz said he hasn’t been able to find one so far that would have triggered the problem. Given Site Kit’s broad usage, other affected sites are bound to turn up once users realize there is a problem. Google launched the plugin in 2019 and has since amassed more than a million active installations. The majority of the plugin’s user base is running older versions, which may or may not be affected by the current issue. WordPress.org shows 35.6% of the plugin’s users are on version 1.38.x. The hot fix is not backported for older releases, but users running Site Kit version 1.38 with background updates enabled should automatically receive the fix. Like this: Like Loading… [ad_2] Source link
Continue readingEmoji Toolbar Plugin Brings an Emoji Picker Back to the WordPress Editor – WP Tavern
[ad_1] Earlier today, theme.es released its Emoji Toolbar project to the plugin directory. It is a simple picker that integrates with the WordPress Rich Text toolbar, allowing users to insert emoji directly from the editor interface. After Nick Hamze pulled his Emoji Conbini plugin from WordPress.org last year, there has been an emoji-sized hole in my editor toolbox. The plugin was the perfect implementation for quickly plopping a quick smiley face or any of the other thousands of characters available. Unfortunately, his departure from the WordPress space meant losing one of my favorite block-related plugins — and several others that I enjoyed. It was also on par with 10up’s Insert Special Characters plugin, a solution for users missing a similar picker from the classic editor era. Emoji Toolbar is filling that void and is a solid alternative for those who need a solution. The difference between the two implementations is the location. Emoji Conbini added the picker button directly to the toolbar, and Emoji Toolbar adds it to the “more” dropdown. Clicking the Emoji button in the Rich Text toolbar. Placing the picker button inside of the dropdown makes it a little harder to find. It also requires an additional mouse click to insert emoji. What matters is that the implementation works, but I would love to see it as a top-level toolbar item. Using the plugin is a simple matter. When in a Rich Text field, which includes blocks like Paragraph, Heading, List, and more, the Emoji Toolbar appears in the block toolbar. After clicking it, the plugin creates a popup of the emoji picker. Emoji Toolbar popup picker. From that point, users merely need to click the emoji they want to insert into the post. The plugin bundles the Emoji Mart library, which has quickly become almost a standard for emoji pickers. The component is a Slack-like box that categorizes each of the characters, and it provides a field for searching for that perfect emoji. There is still at least one emoji inserter alternative. Instead of adding a picker to the block toolbar, Emoji Autocomplete Gutenberg allows users to type : and use keywords for inserting characters. For those who prefer to work from the keyboard, it is a quicker method. Emoji Toolbar shines over Emoji Autocomplete Gutenberg and the now-retired Emoji Conbini based on how it formats its output. It inserts the actual characters into the content, but the other plugins insert an <img> tag instead. That method results in output that is not forward-compatible with any changes in the future or alternative libraries. Users who also prefer to disable image output on the front end cannot do so. This is a non-issue with Emoji Toolbar — it plays well with other solutions. On the whole, the plugin is solid. It has well-written code and provides an easy-to-use picker for inserting emoji. Like this: Like Loading… [ad_2] Source link
Continue readingThe Best WordPress SEO Plugin in 2021?
[ad_1] Trying to choose between Rank Math vs Yoast SEO as your WordPress site’s SEO plugin? In 2021, these are the two most popular SEO plugins and both are great tools that can help you set your site up for success in Google’s rankings. However, there are some notable differences between Yoast SEO and Rank Math, so you’ll want to understand what those are so that you can pick the best tool for your situation. In our hands-on Rank Math vs Yoast SEO comparison, we’ll dig into the important differences to help you decide. Quick Introductions – Popularity and Ratings To kick things off, let’s turn to the wisdom of the crowds and see how Rank Math and Yoast SEO compare when it comes to popularity and user reviews. This isn’t especially hands-on, but it does provide some useful context for why I said that both of these plugins can be excellent choices in their own rights. Yoast SEO is the big name in WordPress SEO. It’s been around forever (since 2010) and it’s become synonymous with “WordPress SEO” in a lot of people’s minds. It’s by far the most popular SEO plugin and it’s also just flat out one of the most popular WordPress plugins ever. Launched a few years ago in 2018, Rank Math is the comparative newcomer in the WordPress SEO space. However, it does come from a well-established WordPress company in MyThemeShop (our review), so the Rank Math team has plenty of experience to bring to bear. Since its launch, it’s quickly risen to become the second-most popular WordPress SEO plugin*. Here’s a table comparing the two plugins as of June 18, 2021: Metric Rank Math Yoast SEO Active sites 800,000+ 5,000,000+ Review Rating 4.9 4.8 Review Count 3,177+ 27,353+ Last 7 days download 349,847 2,333,715 *All In One SEO technically has more active sites than Rank Math, but Rank Math’s new download count is ~3X All In One SEO’s new download count (~349k vs ~111k), which is why I say Rank Math is more popular. Features With the introductions out of the way, let’s compare Rank Math vs Yoast SEO in terms of the features that they offer. To make this easier to scan, I’ll do this in table format. Here’s what the icons in the table mean: ✔️ – this feature is available in the free version of the plugin at WordPress.org. ✔️💰 – this feature is available, but only if you pay for the premium version (more on pricing later). ✔️✔️ – this feature is available in both plugins but one plugin does it notably better. E.g. both plugins support schema markup for rich snippets, but Rank Math’s feature is more advanced, so I would mark Rank Math with the double checkmark. ❌ – the feature doesn’t exist in either the free or premium versions. This is not a complete list of every single feature in each plugin – I just tried to pull out the features that most people will care about. Feature Rank Math Yoast SEO Set SEO title ✔️ ✔️ Set SEO meta description ✔️ ✔️ SEO title/description templates ✔️ ✔️ Focus keyword analysis ✔️ ✔️ Multiple focus keywords ✔️ ✔️💰 Focus keyword suggestions ✔️ ✔️💰 Social media graph control ✔️ ✔️ Readability suggestions ✔️ ✔️ Sitewide schema markup ✔️ ✔️ Per-content schema markup ✔️✔️ ✔️ XML sitemaps ✔️ ✔️ Link counter ✔️ ✔️ Google Search Console integration ✔️ ✔️ Google Analytics integration ✔️ ❌ Basic WooCommerce SEO ✔️ ✔️ Advanced WooCommerce SEO ✔️💰 ✔️💰 Single-location local SEO ✔️ ✔️💰 Multi-location local SEO ✔️💰 ✔️💰 Internal link suggestions ✔️ ✔️💰 Redirect manager ✔️ ✔️💰 404 monitor ✔️ ❌ Advanced Video SEO ✔️💰 ✔️💰 Advanced Image SEO ✔️💰 ✔️💰 Keyword rank tracking ✔️💰 ❌ Breadcrumbs ✔️ ✔️ Role manager for SEO access ✔️ ✔️ SEO reports (white label) ✔️💰 ❌ Full Elementor integration ✔️ ✔️💰 As you can see, Rank Math is the pretty clear winner both in terms of the number of features that it offers and the number of features that it offers for free. In fact, in terms of features, I think the free version of Rank Math might even have more features than the core paid version of Yoast SEO. Of course, having more features doesn’t automatically mean a plugin is better – it depends on whether you actually find those features useful. For example, if you just want a plugin to set SEO titles and meta descriptions and make some basic on-page optimizations, both are pretty much equal in that respect. Additionally, both plugins offer a modular approach to their features, which means you can disable any features that you don’t want to use. This helps you keep your site lightweight and simplify the interfaces. Speaking of interfaces, let’s talk about that next. Ease of Use/Interface Both Rank Math and Yoast SEO are pretty easy to use and beginner-friendly. If I had to pick, I would say that I slightly prefer the Rank Math interface because it’s a little more modern and provides slightly more useful suggestions, but I don’t think you’ll have issues with either. Both plugins work with both the classic TinyMCE editor and the newer default WordPress block editor. However, because the block editor is the default editor in 2021, that’s what I’ll focus on for this comparison. Let’s go through them… Rank Math Rank Math puts its settings in a sidebar panel that’s accessible from the top-right corner. The icon to open the settings also gives you a nice summary of your content’s optimization: Clicking that will expand the sidebar, divided into tabs. In the first tab, you can set the focus keyword(s) for your content and view the analysis. You can also get suggestions for keywords just by typing in the box: Rank Math’s analysis is a score out of 100, which gives you a detailed look at optimization. As I mentioned above, I also find its suggestions a little more useful and detailed than Yoast SEO, especially when it
Continue readingTermly Acquires GDPR/CCPA Cookie Consent Banner, Turns Free Plugin Into a Commercial SaaS Product – WP Tavern
[ad_1] Company A sells its plugin. Company B picks it up and moves forward with an overhauled version that looks and feels much different than the original. Users are outraged by the changes. It seems to be a repeating theme in 2021, almost as a rule rather than an exception. Last month, Termly announced its acquisition of the GDPR/CCPA Cookie Consent Banner plugin. The plugin was a simple tool for adding and styling a consent banner for the front end. It is now a SaaS (Software as a Service) product that requires a Termly account to operate. According to the team’s blog post, such changes were necessary. “Termly’s products, including the cookie consent management platform, are designed to cover the EU GDPR, the ePrivacy Directive, UK GDPR, and the CCPA. These laws require more than just a cookie consent banner to be compliant. Termly can help you build a privacy policy, create a Data Subject Access Request form, and comply with other privacy law requirements.” In the past couple of weeks, users have taken to the WordPress.org review system, handing out 21 of the plugin’s 29 total one-star ratings. The project has over 200,000 users, so more should be expected if the general consensus is that this was a poor move by the company. One of the complaints from users is the commercialization of the plugin. In the past, it was completely free to use. While there is still a free tier, users are limited to a mere 100 monthly unique visitors on a single domain. After hitting that limit, the banner will stop collecting consent records. The next level up costs $15 per month if paid annually. New pricing options for the Termly service. As Pattaya Web Services pointed out via Twitter, “GDPR/CCPA Cookie Consent Banner for #Wordpress has been purchased by #Termly and will now cost most website owners $180 per year.” Termly must get a return on its investment. The company has developers to pay, and they have families to feed. But, I suspect the average user will not warm up to the so-limiting-that-it-is-free-in-name-only introduction level. Having to pay for features that have been free for years will not sit well with many. Of course, there is always the option of using the old version, but Termly has no plans of maintaining it or ensuring that it meets compliance. The only alternative for small site owners who cannot afford to pay is to opt for another solution. “I guess GDPR Cookie Consent banner, now operated by @Termly_io didn’t learn anything from [the] fiasco with WP User Avatar plugin reported by @wptavern earlier this year,” wrote user Gennady Kurushin on Twitter. I believe they did. There are differences, and Termly’s handling of this showed a willingness to be transparent. And, I cannot stress this enough: the new plugin is not an entirely different one unrelated to its core purpose. It was overhauled and turned into a SaaS product. At the end of the day, it is still a cookie consent management plugin — just different and costs a lot more for most users. Unlike Dark Mode and ProfilePress, Termly did not make the changes in the dead of night. At least the company was upfront about everything. The team included an announcement in a point release two weeks before sending out the overhauled version. It disabled automatic updates so that users would not accidentally upgrade without being aware of what was coming. It even published a public blog post detailing what was happening. Prior notice of upcoming changes in 3.0 and disabled auto-updates. If anything, Termly took just about all the necessary steps it could have taken to prepare its user base. If a “right” way existed for a complete and utter makeover of a plugin, the company did as much. That level of honesty is a bit more than we have seen in the past. The changes may still leave a bitter taste in the mouths of many users, but Termly should at least get a few points for making them in the light of day. The result may be the same: fundamental changes in how the plugin operates, but users had a chance to ditch it or continue using the old version before anything went into effect. For some users, it may not be much, but that’s worth something. I won’t be breaking out my pitchfork today, but I do not use the plugin. As more and more users upgrade to 3.0+ and realize they are essentially on the line for $180 per year, the reviews could get ugly. Like this: Like Loading… [ad_2] Source link
Continue readingPublishPress Adopts Organize Series Plugin – WP Tavern
[ad_1] PublishPress, makers of the PublishPress and PublishPress Blocks plugins, have adopted the Organize Series plugin from Darren Ethier. Organize Series is a 15-year-old plugin for organizing and displaying posts in a series, useful for novel writers, educators, magazine sites, and anyone breaking their longer content up into a series. image credit: PublishPress PublishPress is also adopting seven extensions for the plugin that add features like custom post type support, shortcodes, the ability to add a post to multiple series, bulk publishing, and more. Ethier, who works as an engineer at Automattic, said he began losing interest in maintaining the plugin and knew it was time to search for a new owner. “Most of you have noticed that I haven’t been actively contributing to Organize Series or it’s extensions for some time now and it’s been bugging me,” he said. “I’ve been gradually losing interest in maintaining the plugin as I’ve expanded my developer horizons and as a result, I’ve struggled with making the time to work on it.” Ethier connected with PublishPress by describing his situation in a post on the Post Status community and agreed to transfer his plugin and extensions in exchange for a donation to a charity. “Darren asked us to make a charitable donation as part of the handover,” PublishPress founder Steve Burge said. “We chose the American Journalism Project. Over 2,100 communities in the U.S. have lost their local newspaper since 2004. The AJP is trying to reverse that trend. It is a non-profit that is investing in local news. Their goal is to help grow newsrooms that hold the powerful accountable, combat disinformation, and deepen civic participation.” Burge assured current users that the free version of Organize Series will remain free on WordPress.org with all of its current features and some improvements. The company will also keep the extensions freely available on GitHub but Burge said they plan to release a commercial version with updated versions of the extensions. With the adoption of Organize Series, PublishPress now has nine plugins available in its niche collection of publishing extensions as part of its mission to “help WordPress publishers succeed.” In the near future, Organize Series’ website content will be transferred over and the company will be changing the plugin’s name to “PublishPress Series.” Like this: Like Loading… [ad_2] Source link
Continue readingRevisions Extended Plugin Lets Users Schedule Updates to Published Posts – WP Tavern
[ad_1] WordPress has long had the ability to schedule content to be published in the future, but it can only make immediate changes to posts that are already published. If you want to schedule changes to published content, a plugin is necessary. Corey McKrill, a full-time sponsored contributor to the WordPress.org Meta team, has developed a plugin, with the help of contributor Steven Dufresnethat, which is now in use on WordPress.org. Revisions Extended allows users to schedule revisions, or updates, for posts that have already been published. It extends WordPress’ revision system to include a “future” post status as a revision post type. McKrill recorded a gif to demonstrate the UI: https://cloudup.com/cOHLm_77ECk Although there are existing plugins which already perform this functionality, McKrill said they were either inadequate for WordPress.org’s needs or add extra functionality that they don’t need. Revisions Extended supports the following for any post type that supports revisions: From the block editor, make changes to an already-published post and schedule those changes to go live at a later date. In the block editor UI as well as other admin screens, indicate when a post has a scheduled update. View a list of all scheduled updates Delete a scheduled update or trash/unpublish a post with a scheduled update Edit scheduled updates, including the content and the future publish date. Compare scheduled update content to the current published content. The ability to schedule updates is especially useful for ensuring that software documentation is updated when a new release is available or when API changes go into effect. The plugin entered the testing phase in March and is now used on multiple sites across the WordPress.org network. It makes it easier to schedule updates to lesson plans on the Learn WordPress site after a new version of WordPress is released. It also makes updates to HelpHub and DevHub more efficient. “If you need to schedule updates for published WordPress post/page/CPT without changing what’s already published (nor switching to draft), this is something we recently started using at the WordPress Docs Team and it’s a game changer,” contributor Milana Cap said. Revisions Extended is currently being developed on GitHub. McKrill said it may be be submitted to the official plugin directory someday when it is more ready for that level of exposure. “It’s a possibility,” McKrill said. “There’s a bit more functionality I think should be added first, namely the ability to create updates in a ‘draft or ‘pending’ status to go alongside the current ‘future’ status. Adding it to the plugin directory would allow a lot more people to try it out and give feedback, but it might also greatly increase the support and maintenance burden. So that has to be part of the calculation when deciding if/when to add it.” McKrill believes Revisions Extended could be a useful addition to core but there is not currently an active plan to bring it into WordPress. “Something like this might get traction during Gutenberg Phase 3, which will focus on collaboration tools,” McKrill said. For now, those who are interested to use Revisions Extended can download it and/or contribute to its development on GitHub. Like this: Like Loading… [ad_2] Source link
Continue readingIdentify and Select Blocks via the Wayfinder WordPress Plugin – WP Tavern
[ad_1] Christopher John, a Seattle-based designer and UX engineer, released his first project to the plugin directory yesterday. Announced via Twitter to high praise, Wayfinder is a block outline solution for the WordPress editor. Like similar plugins, the goal is to make it easier for end-users to select nested blocks, which can sometimes be tough to pin down. Wayfinder outlines each block in the editor on hover. It then displays the block name at the upper left of the box. My favorite feature that you will not find elsewhere is the addition of each block’s classes at the bottom right of the box. This makes it easy for designers or users who want to quickly find a class for styling. Outline of a Heading block. Users can also enable or disable the pieces of the UI they want to appear via the plugin’s setting screen. However, any changes affect all of the site’s user experiences. Currently, there are no per-user settings. At first glance, the plugin seemed to work great. The hover outline experience felt smooth, and I did not need to change the default options. Wayfinder almost seemed to be everything one might look for in a block-outline solution. It was besting existing plugins in nearly every way. However, things soon began rolling downhill when writing a typical blog post with nothing other than Heading, Paragraph, and Image blocks. I first noticed that I could not type the same number of words as usual on one line. My perfectly-tuned typography was breaking sooner than it should have. Spacing between paragraphs seemed a bit too large. My wide-aligned images were just a little smaller than usual. The user experience still felt good until this point, but the little oddities were stacking up. Something was not right. The plugin had been showered with praise on Twitter and already received three five-star reviews in its first 24 hours. Maybe my custom theme was the issue. However, similar problems arose when testing several others, such as Twenty Twenty-One, Nutmeg, and Eksell — each a well-rounded theme catered to the block editor. As clean as the plugin’s UI is, it more often than not wrecks the theme’s default block spacing. This becomes more noticeable as users begin adding nested layers of blocks. The problem is the plugin adds 18 pixels of padding around every block via its stylesheet. .wp-block:not(.block-list-appender) { position: relative; outline: 1px dashed transparent; padding: 18px; overflow: visible !important; } To the untrained eye, this may not be a visible issue in many cases. It will affect each site differently, but 18 pixels of extra padding on every block will undoubtedly mess things up to some degree unless the theme itself uses that exact same spacing in its design. The more noticeable issues are seen with blocks like Social Icons: Holy moly! Those are some gigantic social icons! But, even something as basic as a List block can be misaligned: List block shifted out of alignment. Theme authors can write custom CSS to overrule the plugin’s padding. However, the last thing the WordPress community needs is a specificity war between themes and plugins. Themers already have to do this enough to wrangle blocks now. Removing that one padding rule from the plugin’s editor-style.css killed 99% of its issues. Afterward, things were running like a well-oiled machine. As a developer, I would explore outline-offset for spacing between the block and its outline, maybe cutting that 18px down a bit. Because outlines are not a part of the CSS box model, it would not affect spacing. Adjustments may be necessary on a per-block basis, especially when those blocks are nested or small (e.g., Social Icons, Navigation). It would carry its own challenges but should be a less destructive course. To a lesser extent, the plugin’s overflow rule breaks the theme design from time to time. Its position and outline rules could overrule some edge-case block styles too, but they are necessary for the plugin to actually do its job. In particular, I could see positioning being problematic with sticky headers as we get into site editing. The only other issue might be themes that use ::before and ::after pseudo-elements on blocks, but the plugin also needs to overwrite those to display the block name and classes list. This is likely another edge case. Despite the issues, the plugin is ahead of the pack at this point. Gutenberg Editor Full Width Blocks Border (a bit of a mouthful), another recent plugin to offer similar functionality, breaks custom theme design across the board. It does accomplish the job of making blocks easier to select, but the sacrifice of a WYSIWYG is not worth it. The Editor Block Outline plugin has been my go-to recommendation for a while. It has a few design issues of its own, but some of those are adjustable on a per-user basis. However, as of late, it has made the editor feel sluggish. Plus, its misuse of the WordPress admin notice system for Twitter followers makes it something I’d prefer to steer clear of. EditorsKit has a similar “block guidelines” feature that uses a box-shadow instead of padding and an outline. It does not muck up most theme layouts with that technique. However, I have hit other style conflicts with the plugin. Plus, EditorsKit is overkill for users who simply want just one feature. That leaves us with Wayfinder. Warts and all, it is the best standalone option right now. Maybe that’s not saying much, but it is saying something. This is a feature that is hard to nail down. I do not envy the developers who are trying to make miracles happen. It is sure to please many who have been on the lookout for a block outline solution. It is in a position to pull farther ahead of the competition with its relatively solid first outing. With more thorough theme testing and a bit of adjustment to its approach, it could be even better. I am eager to test
Continue readingPrivate Note-Taking and Journaling With the Hypernotes WordPress Plugin – WP Tavern
[ad_1] Ella van Durpe, a core WordPress contributor and software engineer at Automattic, released a note-taking plugin earlier today. Hypernotes is a simple custom post type that allows end-users to take private notes or serve as a journaling tool. I have seen similar plugins in the past. I even began building one years ago before ultimately abandoning it for a simple Markdown solution in a private repository. What makes Hypernotes unique is its handling of “folders,” which essentially work like categories. However, each folder gets its own sub-menu link under the Notes section in the WordPress admin. Hypernotes’ folder system. This more closely mimics other note-taking apps where users can switch between various folders to quickly find notes. The code to make this happen is simple; the idea is ingenious. It is the sort of outside-the-box thinking I love to see from plugin developers. There are a few trivial issues with it, such as the folder names not being highlighted when viewing their screens. However, that is a WordPress-specific bug. A simple dash before each folder name could spruce up the UI a bit too. They sit below the “All Notes” menu item, so it would create more of a folder effect. On the whole, the plugin works well as a note-taking application. Writing a note in the WordPress editor. The plugin description does have a security note for users who are wondering just how private their content is: Only you will be able to see your notes within the WordPress admin, but the notes are NOT encrypted at the moment, so anyone with database access will be able to read them. Hypernotes also ensures that no post is ever accidentally published for all the world to see. Under the hood, it automatically sets all notes to the “private” status. The plugin’s post type cannot be publicly queried on the front end either. It is worth mentioning that the plugin does not create custom capabilities (permissions) for its post type and taxonomy. Any registered user on the site with the right post-editing capabilities can access others’ notes in the backend, such as people with the Editor role. This is unlikely an issue given the nature of the plugin. I imagine the primary audience will be made up of solo bloggers who want a simple note-taking solution. I ran into one not-so-trivial issue when I began trying out Hypernotes, believing my website was broken. This is usually because of a patch I am testing for the Gutenberg plugin or just one of its run-of-the-mill updates. However, the typical culprit was not to blame. After a half-hour or so trying to figure out why my theme styles were not appearing for Note posts, I finally cracked the issue. Hypernotes disables all theme editor styles. The beautiful typography of my currently active theme was gone, which would work well with a note or journaling plugin. This was easy enough to overrule with a few lines of custom code. If I was going to save a few quotes that I liked as personal notes, I at least wanted to do it in style: Bringing back my theme’s custom quotes style. The plugin also attempts to disable wide/full alignment and theme editor font sizes. The code it uses works for traditional WordPress themes but not for block themes, which have a different mechanism for registering such support. This was also one of the reasons it was tough to track down the issue. Everything else from my theme was working but custom editor styles. I understand the idea behind removing support for those features. Themes design the front end of the site, and Hypernotes is purely a backend tool. However, I would rather see an option for letting the user control what gets disabled. Some theme editor styles would pair well with the plugin. Disabling these features has other implications too. For example, all of my theme’s custom block style variations were registered and usable from the editor. However, because my styles were not loaded, they did not work correctly. Another option would be for the plugin to provide its own editor styles. There would still be some complications going that route, such as the block style variations issue, but the plugin could become a beautifully designed note-taking app in its own right. For a version 1.0 outing, I am a fan of the simplicity. More so, I am impressed with the clever method of handling note “folders.” I am eager to see how this plugin evolves over future iterations. Like this: Like Loading… [ad_2] Source link
Continue reading