[ad_1] Earlier this month WordPress.org meta contributors removed the active install growth chart from plugins, sending plugin developers who relied on this data into a state of dismay and outrage. The commit cited “insufficient data obfuscation” but there was no clear communication about when and where this decision had been made. Developers demanded more transparency around the charts’ removal but received no clear answers. Multiple opportunities to communicate the details behind the decision were deliberately forgone, as speculation mounted. Several contributors not directly involved in the conversations prematurely insisted it was removed due to a security or privacy concern, but Samuel Otto Wood has unequivocally confirmed that it was neither of these things. In a recent appearance on the WPwatercooler podcast, Wood elaborated on the decision, which he says was made in May through private channels via Slack DMs in a discussion initiated by Matt Mullenweg. “The reason is really quite simple,” Wood said. “It was removed because by and large, nobody was using them. Nobody was using the chart itself. By and large, the chart was not useful to the majority, and it didn’t really fit the purpose we had for it, that we had in mind when we implemented it.” Wood said the active growth chart was intended to just show growth or decline of a plugin on a weekly basis, but the data wasn’t working as intended: People wanted that feedback on whether plugin’s growing, whether it’s shrinking, et cetera. And that’s valuable information for developers to have, it’s valuable information users to know. But it really wasn’t working as that. The data that it provided was a percentage based data, and it was a very weak percentage based data. So by and large, the majority of use of that data was people scraping the data and using it to work backwards to the exact quote, exact numbers That was entirely the problem was that people were largely using it to get those numbers. Now, that’s not itself bad, but a, the reverse math didn’t work. It was wrong for a number of reasons, mainly because we were doing such a way obfuscating the data in such a way that it made that number wrong. Second, Actually, it’s kind of funny. It actually always gave numbers a bit too high, so it was giving people the wrong impression. Third, it really, people trusted it as an active number, as a number of active cells to the point where, to the point where they, they relied on it to make decisions and things like that. It was not a good idea. Although Otto was not involved in working on the project at the time, he was privy to the discussion and relayed some of the details: I read through all that discussion and we worked, they worked on it for a long, Scott and several people tried various things before removing it. They adjusted the values, they adjusted numbers. They, they went through a ridiculous amount of iteration and in the end, none of it worked. People were still using it even though it was giving them basically garbage. So finally removing it was the only thing to do. We did have a plan for replacing it. We just didn’t have a plan for replacing it immediately. Nevertheless, giving them active install count numbers that are wrong is more harmful, we felt, to both users and developers interests than simply not giving them at all. So that’s why it was removed. The concern podcast host Sé Reed and guest Matt Cromwell highlighted was that the decision was communicated in such a way that it suggested it was security related. Since it was not a sensitive security or privacy issue, Reed asked why was it handled in a private chat instead of the meta channel when the decision had such a profound impact on developers being able to track the trajectory of their plugins. Since the inaccuracy of the charts was well-known to those more intimately acquainted with the problem, Wood said its removal was “not quite the big deal” that everyone else ended up perceiving it to be. They did not anticipate the firestorm the charts’ removal would create in the trac ticket where developers were pleading to have them restored. “The physical visual chart itself is not so instrumental to the way I operate things,” GiveWP founder Matt Cromwell said. “But it’s the act of removing it without any conversation whatsoever. “And what does that mean for the long run of data about plugins on.org and the viability of their, of us, continuing to have them? That’s the real question. It’s an indicator of an underlying problem that isn’t getting better.” This incident has sparked discussions about what kind of partnership plugin developers should expect from WordPress.org, and whether it’s time they looked for support from one another instead of the platform, as Eric Karkovack suggested on The WP Minute. In light of plugin developers losing more valuable data that hasn’t been replaced, Alex Denning, managing director of Ellipsis, a digital marketing agency, makes the case that WordPress.org is ineffective for plugin distribution in 2022. He contends that new WordPress plugins are not passing the 100k, 500k , or 1m+ install thresholds and the directory isn’t giving plugins organic reach. The focus of the ticket has changed from calling on WordPress.org to bring back the active growth charts to be more about brainstorming helpful plugin stats and insights that plugin developers would like to see. It is still receiving angry and frustrated comments from developers who believe the data should belong to the community. “I cannot emphasize enough that conversations about what to replace the active growth chart with should be happening in a public Slack channel or on a Trac ticket,” Equalize Digital CEO Amber Hinds said. “This data should belong to the community and the community should be able to participate in deciding how (or not) to display it.” The reasons that purportedly necessitate obfuscation have
Continue readingTag Archives: Continues
Gutenberg 11.0 Includes Over 70 Bug Fixes, Continues Improving With WordPress 5.8 Just Two Weeks Away – WP Tavern
[ad_1] Gutenberg 11.0 landed yesterday with a pile of changes. The development team has been moving fast, and it shows. For a two-week cycle, version 11.0 includes an insane number of bug fixes. Contributors squashed over 70 in this release alone. This seems to be in preparation for WordPress 5.8, which is expected to land on July 20. The upcoming block-based Widgets screen had the lion’s share of bugs. However, the block library had nearly two dozen, many of those issues with new theme-related blocks. The downside of such a massive release is that there are too many features and not enough time to cover them all. I will be cherry-picking some of my favorites, but feel free to dive into the release notes for a complete picture. Theme and Template-Editing Mode Changes One of the primary Full Site Editing features making its way to WordPress 5.8 will be disabled by default for most users. In a rare move from the core project, the template editor will be opt-in, at least for users with classic themes. It is opt-out for block themes. As I wrote last month, until users are on actual block themes, the template editor is “a sort-of-OK-but-kind-of-amazing landing page creator.” Template-editing is really only as good as the weakest link in the system. This will almost always be the theme over the next few months. Because the template editor is a new feature that directly attempts to overwrite the front-end output, it will always be at odds with many themes that were never designed with it in mind. The opt-in approach is unlikely the best route to mass adoption, but it is in the interest of the user experience. Making it opt-in also allows theme authors to make template editing a smooth experience. Gutenberg 11.0 introduces a new defaultBlockTemplate editor setting. Theme authors can create the default blocks that users begin with when creating a new template. Starting with a custom default block template. Ideally, this default template should include some base layout components, such as a header, footer, and post/page content. However, themers are free to put their own spin on this. For more information on creating default block templates, theme authors should read Themes Team rep Carolina Nymark’s overview of WordPress 5.8 theme features. Media & Text Block: Drag-and-Drop Media Replacement Dragging a new media file into the Media & Text block. Users have long been able to drag and drop an initial image or video into the Media & Text block. However, they were unable to replace it using the same method. Gutenberg 11.0 creates a new “drop zone” over the media column, making it easy to change the media to something new. The feature already exists with the Cover and Image blocks, so this change brings Media & Text up to date. We probably should have had this feature months ago, but the patch sat in limbo waiting for a code review. Accessibility: Categories Dropdown Has Label Label difference between the Archives and Categories blocks. The development team added a new “Categories” label when the Categories block is shown as a dropdown. This is a welcome improvement to help those using screen-readers better navigate the page. The problem with this change is the lack of consistency. In Gutenberg 10.8, the team removed the .screen-reader-text class for the Archives block label, making it appear on screen for all users. These types of inconsistencies that seem trivial on the surface tend to pile up, creating code bloat for theme designers in the long run as they try to wrangle them. I would prefer both labels to be marked as screen-reader text. Regardless of the default, the two should match. Then, throw in an option for the end-user to decide whether to show the label similar to how the Search form handles it. The Return of Post Classes Post classes appear for Post Template block. For those theme designers who need them, Gutenberg 11.0 brings back post classes. If you are wondering where posts classes had gone, you may not be alone. In the world of blocks, they are not needed as much as they once were. Traditionally, WordPress theme authors used these classes to dynamically change the output of a post based on contexts such as type, format, category, and more. When the Post Template block (formerly named Query Loop) was introduced, there was a noticeable lack of the traditional classes attached to the wrapper for individual posts. This latest update brings them back. In the future, block themes will likely rely on these classes less and less. With much of the design configuration moving to theme.json files and user-controlled options, it is probably time to say goodbye to one of the core features of theme design over the past decade. However, it is a comfort to know it is there when needed. Decimals Allowed in Spacing Controls For those who are particular about getting their margin and padding just right, they can finally rejoice. Spacing controls now allow for decimal values and not just whole numbers. In past versions of the plugin, a value such as 1.5 would be rounded up to 2. When used with rem and em units, such rounding created a 50% difference between the intended spacing and reality. I am happy about this one. It is a fix for one of the tickets I opened (hooray for contributing!). However, I cannot take credit for fixing the problem. That honor goes to Themes Team representative Ari Stathopoulos. Like this: Like Loading… [ad_2] Source link
Continue reading