[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: Install
How to Install and Setup WP Super Cache: Our Beginner’s Guide
[ad_1] For fast websites, caching is an important tactic. It will store files that see a lot of use in a portion of memory, which is faster to recall than loading them from the server. As such, there are lots of WordPress plugins available. A perennial option is WP Super Cache, for a few reasons. In contrast to other plugins such as W3 Total Cache, WP Super Cache is super simple. In many cases, you’ll use a minimal-click setup that will still give you a boost to your site’s speed. However, there are more settings under the hood, and it can fit your needs regardless. For this post, we’re going to go over how to install and setup the WP Super Cache plugin. Along the way, we’ll look to explain almost everything you need to know about the plugin. What the WP Super Cache Plugin Does for Your Site Your website’s server contains many different files, some of which will load more often than others. A fundamental of the internet is that files will move between servers, often across the globe. However, this distance coupled with the constant loading stream of data can slow down your site, and cripple it in the worst case scenario. This is where a plugin such as WP Super Cache comes in. It hooks into your site to provide a temporary storage option for those files your server will load on a frequent basis. This ‘cache’ will pull files out when there’s a request, which cuts down on loading time. It’s a near-essential piece of functionality you can implement in minutes. There are lots of WordPress caching plugins available. For instance, the WPKube blog uses WPRocket. However, WP Super Cache has a charm of its own, along with a nifty feature set. Looking at the WP Super Cache Plugin’s Features and Functionality WP Super Cache is almost as old as WordPress itself. It’s a longstanding option to cache files, and it’s also a ‘first-party’ plugin. This means Automattic looks after its development and maintenance, much like WordPress itself. This plugin takes your ‘dynamic’ WordPress files and turns them into ‘static’ HTML ones. The contrasting PHP files will be heavy and slow to move around. The HTML ‘copy’ of sorts is light and will give you the same level of interactivity in most cases. Here’s what else it can offer: It offers two modes: Simple and Expert. These will suit different types of users. In fact, most will likely choose the Simple option and never look back. There’s also a WP-Cache option, which handles the caching process for known users, certain URLs, and others. It’s more complex and slower than the typical caching options, but it also provides a greater level of dynamism with regards to your content. You can connect a compatible Content Delivery Network (CDN) if you use one, and WP Super Cache can leverage its functionality. There’s lots more to discover about WP Super Cache, but the best way to find out about it is to use it. Over the rest of the article, we’ll run over how to do so. How to Install and Setup WP Super Cache (In 3 Steps) WP Super Cache is so straightforward that in many cases you won’t need a tutorial. However, there is much more to the plugin than selecting the Simple mode and leaving it alone. The next few steps will look at the following: However, you’ll need to install and activate the plugin before anything else. Let’s deal with this first. 1. Installing the Plugin and Finding Its General Settings In the beginning, you’ll need to install and activate the WP Super Cache plugin. Because it’s free, you can do this directly from your WordPress dashboard. We have an in-depth guide on how to do this without fuss. Once the plugin is live on your site, head to the Settings > WP Super Cache screen: You’ll pop up on the Easy tab. The first radio button here will give you the option to turn caching on or off: However, we’d recommend you keep this to Off for now. This is because you’ll want to tweak all of the necessary and relevant settings before you pull the trigger. Speaking of which, we can look at this in the next section. 2. Customizing the Advanced WP Super Cache Settings The real main settings screen for WP Super Cache is the Advanced tab. This contains almost every option you’ll need, but requires heavy use of your scroll wheel: The top few options are simple to understand. There’s an option to turn on caching, then to choose the appropriate delivery method: The difference between delivery methods can be complex, but Simple uses PHP to serve cached files, while Expert uses your .htaccess file or Nginx rules. It also enables a few other options to leverage. If you use custom permalinks, you may not need to tinker within your server’s files. However, the Expert mode still requires some technical knowledge to implement well. While it’s faster, the negatives could outweigh the positives. Our advice is to use Simple mode, unless you are comfortable poking around within WordPress’ files. As for the other sections on the Advanced screen, let’s look at them in turn. Miscellaneous This section will help you determine how caching works for different users. The recommended approach is to disable caching (and associated functionality) for those users who log into your site. This is because the dynamic functionality is important for them. The plugin does a good job to note which options you should tick – everything that states its Recommended is a good idea. Here’s a quick list of options to go for: Disable caching for logged in users. Compress pages so they’re served more quickly to visitors. Cache rebuild. 304 Browser caching. As for the other settings, the only optional one you’d set is Don’t Cache Pages with GET Parameters. These types of pages will render on a per-user basis. As such, you’ll want
Continue reading