Posted on

WordPress Form and Comment Spam

As with security in general, escaping the scourge of WordPress form and content spam requires a layered approach. Here is what works.

Databases and Behavioral Anti-Spam

The first step is the one that nowadays works the least well. In the beginning we had Akismet, and things got better, but this is an arms race, and Akismet has not been getting better. In WordPress, this battlefront has basically been ceded (with some exceptions, below). For things like Google's Gmail, this still works fairly well (along with manual rules), a vast majority of the time.

Manual Rules and Keyword Blocking

Manual rules and keyword lists help block a particular subset of spam, namely that manually created by humans, with the purpose of pestering someone to hire a so-called SEO Expert, Web Designer, or Marketing services. By placing these highlighted keywords in the WordPress Admin > Settings > Discussion > Comment Blacklist field, they are not only used as a filter by the WordPress commenting function, but also used by Contact Form 7.

Javascript and/or Session Detection

For the average bot, which is fairly simplistic and won't accept session cookies or have javascript enabled, testing for one or both of these conditions will generally allow those to be ignored. For Comment Spam (on sites that must have comments enabled), the WordPress plugin WP-SpamShield is a fairly effective option. In the future, it might be better to ensure no plugins do PHP Sessions, for performance reasons, but on a moderately busy site this shouldn't be much of a problem.

Honeypot Form Fields

Another way to detect bots is to provide form fields that they see but that humans do not (via CSS). Bots will attempt to fill out these fields, and thereby have their submissions identified and silently rejected. For Contact Form 7, a good choice is the aptly named Contact Form 7 Honeypot. For WordPress account creation/registration, there is the Registration Honeypot.

Captchas and NoCaptchas

Captchas are another older technology that there are several instances of. Google famously acquired ReCaptcha in 2009 for hundreds of millions of dollars. They introduced a new version in 2014, called NoCaptcha ReCaptcha. And in early 2017, the Invisible ReCaptcha was unveiled, so to speak. ReCaptcha has gone from a human vision solution to a fully automated approach (hence full circle back to the first item above, databases and behavioral). Personally, I've had so much nonsense from the Google ReCaptchas that either end up making me solve a half-dozen puzzles or more, or that insist on presenting in a human language I cannot read. Google is very bad at both of these issues (producing puzzles for humans, and providing better language support. In both cases the problem could very easily be made much, much less horrible, if simple human factors were taken into account, such as the size of text and providing a consistent language menu item that is labeled to be identified by non-readers of the currently selected language. Both huge failures for a company that should have worked this out a decade ago. There is one captcha system that actually works well, both for humans (to provide access to them), and for bots (to deny access to them), and that is the Really Simple Captcha. Orginally designed to work with Contact Form 7 -- which it still does -- it also can work well with other forms, and has a basic library that can be used by WordPress developers.

Summary of Anti-Spam Solutions

For contact forms, use: - Contact Form 7 - Contact Form 7 Honeypot - Really Simple Captcha - Add keywords to the > Settings > Discussion > Blacklist section For comments in general - WP-Spamshield - Add keywords to the > Settings > Discussion > Blacklist section For bot registration denial - Registration Honeypot

Posted on

Woocommerce Customization

Woocommerce is a fantastic, though complex, time-consuming, and/or expensive ecommerce system. That said, it is the most popular on WordPress, and has a lot of potential for the future. It is getting a lot of development effort at Automattic, and has a fairly extensive functionality set, and some loosely- and tightly-coupled extensions and sister-plugin functionality. That said, it is a whole other thing to learn, and out of the box it is pretty, damned, ugly. From what I can tell, the theme business at WooThemes is to generate a number of rather generic, though varied themes that integrate with WooCommerce (via a WooThemes Framework).

Start with a Theme

Once one has Woocommerce in mind, it is important to start with a theme or theme framework that will be flexible and fast. It seems that the Canvas Theme has a dedicated developer, is integrated with WooCommerce, and also is more or less a highly customizable framework-worthy theme.

Child Theme Files

  • style.css
  • functions.php
  • Copy any WooCommerce files to be customized into the /woocommerce directory There will be a lot of additions to functions.php and also to style.css.

CSS Guidelines

  • I want to get very strict on not using in-line CSS, and pulling out all such CSS into classes and placed in the single style.css file.
  • Still, if the Customizing Additional CSS part of the live preview editor lives up to its promise, one can quickly add, test, and deploy new CSS
  • Likely best to use that for testing, but then move any CSS code change to style.css

Shortcodes

There are a number of WooCommerce Shortcodes but also WooFramework Shortcodes, available in Canvas. See also the WooFramework Release Notes. It is clear that this is a shortcode-centric theme, which is highly desirable for developers and those who need to maintain sites, not just build something pretty.

WooCommerce Extensions

There are a wide variety of plugins that are WooCommerce Extensions, and supplement or modify behavior in some small or big way, including: - Aelia Currency Switcher - WC Variations Radio Buttons - WooCommerce Bookings - WooCommerce Checkout Add-Ons - WooCommerce Checkout Field Editor - WooCommerce Deposits

Other Woocommerce Compatible Plugins

There are also many other plugins that offer some degree of compatibility and/or interoperability and/or integration, including: - AffiliateWP (Affiliate Management) - Sensei (Course Management) - Follow-Up Emails (Drip Email and Newsletters) Others are mentioned in a previous note on the Woocommerce Ecosystem.

Update May, 2017

Woocommerce is a total shit show. They are on release 3.0.7, less than a month from 3.0.0. Haven't seen any negative press calling them out. All Woocommerce plugin and theme designers can't or won't criticize, so they are all slaving away madly. What a crock. I've revamped my outlook on this turdblossom. I believe it is safe to say that there is a part of the market that is tired of this nonsense, and is more interested in dealing with content and commerce in a sane way, but with some kind of baked-in extensibility (for example, multilingual). I realize there are tax issues and composite products, and this makes it more difficult, but lose that part of the market, or make it simpler and easier.

Posted on

WordPress Site Performance

Site performance comes down to two issues:

  • Perceived relevance
  • Perceived responsiveness

Actually, perceived responsiveness could be considered an aspect of relevance (but not the other way around). To be relevant is to be speedy and relevant.

Catch 22 - Speed vs. Functionality

For WordPress, the architecture is one where responsiveness goes down logarithmically to the amount of functionality and complexity of the system, that is, the more widgets and plugins. That is, the more relevance in terms of function, the less relevance in terms of responsiveness.

This is pretty much by design, as there is no way to try and register globally CSS or Javascript so that it could be managed centrally (via minification and caching). So instead, each plugin or widget makes its calls and shoves its code in a few select spots, in an order that is not fully predetermined.

Minification and Caching

The two strategies for speeding up sites are:

  • Minification (a two part strategy), and
  • Caching (also a two part strategy).

Minification consists essentially in compressing and combining files, with a variety of tools to do so. Compressions means the files are smaller, and combining them means there are fewer, and therefore fewer server requests.

Caching involves both placing files closer to the recipient, as well as keeping them there for future requests. This means both initial requests and subsequent requests are opportunities to prefetch through anticipation. And also to cache various different aspects in various different locations, and with a variety of strategies to expire content so that new content is fetched when needed.

note: cookies also have a caching mechanism

While minifications are essentially algorithms for compression done just after one or more fragments are constituted, caching is done in a variety of places (browser, forward cache, CDN, web server), and for a variety of things (database, page, object). HTTP headers are one place where caching information is kept.

The Cached and the Uncacheable

In order for these things to work well, there should be a single location where both minification and caching is configured, and a single set of benchmarks that could provide feedback on the best approach for a given site profile. Further, what can and what cannot be cached, and when the can/not caching may or may not be permitted. Various kinds of content might need to be uncachable, at least globally, including:

  • Location-specific content - information for visitors from certain places, such as currency
  • Language-specific content - information in specific languages, which may be identified by browser language
  • Group-specific content - information for people who are a part of a group, such as paying customers, or active leads
  • User-specific content - information for a specific person, such as their transaction history, available when they are logged in
  • Newly updated content - should replace any old content that it replaces in all caches

In most of these examples, there should be some way of changing preferences (location, language, group), when those options are otherwise free choices.

Instantclick / Turbolinks / Progressive Web Apps

Preloading is essentially what caching is, though where the preload happens can vary. By focusing not on the server-side, but the web application side (Instantclick, Turbolinks) and the browser requestor (Progressive Web Apps). By focusing on optimizing the browser render, these tools become much more responsive, such that relevance is increased (to the degree the application, page or site has the proper functionality and content).

Single Page Applications (SPA)

While PWA supports standard websites and is really trying to fix low bandwidth issues, IC and TL essentially turn websites into single page applications, as the entire page loading process is dispensed with, and only changes to pages are introduced. This is a noticeably faster approach. Unfortunately, much of the development, tools, plugins, etc., out there assume the basic model of a clean DOM for every page being called. This means whack-a-mole forever.

WordPress Minification

The big problem with minification on WordPress is that the way plugins interact, the minification process can break things, and ultimately some kinds of content cannot be minified. Thankfully, since plugins are open source on WordPress, it is possible to fork them and fix them (though a costly, time-consuming task). Ultimately, this kind of fixing needs to be accepted upstream, or a huge amount of ongoing maintenance will be needed. Ultimately, porting a number of plugins into custom posts instead is one option. But again, time and resources needed.

CSS Minification

One approach is to strip out all the CSS in every plugin and theme and add it to a single file (or a small set). Maintaining one file is much more manageable.

Javascript Minification

Javascript is a more complex problem because some of it needs to be in certain places in the page. Header, body and footer. Blocking and non-blocking. Essentially Javascript needs to be written for minification and deployed in a theme in such a way as to naturally fit.

Pre-minification of Content

Better is to not minify at page cache, but previous to that, or at least to the degree possible. For a given set of pages on a site, some set or subset of javascripts will be needed. Some will always be present, some will sometimes be present, and there will be a limited number of sets of javascripts. Also, there are certain aspects of the site such as menus which are constructed out of queries, but can also be minified and cached as a set. Contact forms, user account pages, empty shopping carts, and the like can be designed in a way to simply add one more javascript and html component.

Performance Testing Tools

Posted on

Mad WooCommerce Development

The WooCommerce team is introducing a huge amount of integrated functionality. WooCommerce must be considered a platform at this point (with WordPress as a much more generic, broader platform). Think of Windows and Office. Windows is a generic operating system and Office is a set of applications. While the analogies only go so far, WooCommerce itself is now a platform as integration with it adds value. In addition, many of the more functional applications show a lot of horizontal integration. There are now a large number of highly functional and interoperating applications in a variety of areas. Examples: - Follow-Up Email (FUE), now simply named Follow-Ups - An email management system (drip email, mailing lists, newsletters) (Follow-Up documentation) - Sensei - a Learning Management System (LMS), aka Courseware - WooCommerce Memberships - Time and membership level-based access to content, including drip-feed content, groups, access control, and recurring subscriptions - Note also the alternative Groups for Woocommerce, which enables selling group memberships (without recurring subscriptions) - WooCommerce Bookings for time-based rental/use - WooCommerce Subscriptions, for recurring and time-based services While several of these just appear to be extensions of ecommerce, there is a lot of data and organizational knowledge tied up in much of these, beyond inventory, pricing and transactions. The email marketing niche is really a brilliant approach as this is a very popular and necessary niche populated by expensive SAAS/Cloud service providers (MailChimp, etc.). The LMS courseware is equally a fascinating market, and has unique properties to a Memberships niche, which is not only about members but content management. Bookings with the focus on time-based services (from classes to hotels), as well as rentals (e.g., booking a car rental), is a very complex system, as anyone who has tried to get a reservation system up online that did the job (without paying a fortune), can attest. Finally, full support of subscriptions (time based, recurring, etc.) is widely in demand. Further integration among and between these fairly important areas of confluence between marketing, content, and ecommerce.

Third Party WooCommerce Integrations / Extensions

WooCommerce can't do everything (nor should it) so there are a few platform areas that are important but not yet under the sway of the Woo Team.

Customer Relationship Management (CRM)

Actuality Extensions has a very compelling CRM extension to WooCommerce. Though to be honest having something that extends user fields, pages, and reports is likely enough, and could be customized much easier, especially when combined with Follow-Up Email.

Events Calendar and Event Tickets

The Events Calendar Pro and Event Tickets Plus by ModernTribe are best in class for managing calendars, events, and ticketing.

Affiliates - A Crowded Field

Affiliates are still an area where there is lots of healthy competition. I still like my creaky old WP Affiliate Platform, it works and it's bulletproof (and also widely integrated). Unfortunately its getting a bit moldy, and the integration and functionality is not as awesome as competitors. For example, AffiliatesWP by the Easy Digital Downloads guys, has a slew of AffiliateWP Pro Add-ons including Direct Link Tracking which basically removes the whole issue of affiliate codes. Simple, sweet, and something the Tips-and-Tricks folks can't even determine how much it would cost to develop for the WP Affiliate System (when asked).

Multi-currency, Multi-paypal accounts

Though WooCommerce has many plugins, Aelia has filled a niche regarding multi-currency/multi-account paypal processing. This plugin is at base a multi-currency extension, but itself can be extended for the use of multiple accounts (determined by which currency is chosen). This is great if you want to avoid both cross-border charges (and have paypal accounts in multiple countries) and currency conversion charges. I would still like to have different paypal accounts based on the amount being sold. That way use of a micropayments-enabled paypal would help if a > $5 USD charge were being made.

Posted on

Email Marketing Automation

There are various aspects of email marketing automation, including: - Newsletters - Drip Email - Customer Relationship Management (CRM) Suffice it to say that all of these are connected in some kind of venn diagram. However, when it comes to each of these in terms of software integration, they all start from different sides of the triangle.

Newsletters

Newsletters start with the newsletter, that is the thing that is created and sent. Along with that of course are lists of subscribers (to whom they are sent). Newsletters are most like a website in terms of content being created and posted with dates/times. In fact newsletters are a favorite way of ensuring one stays up to date with new content on a website. All visitors to a site should be able to subscribe to updates for that site, naturally. ALO Easymail Newsletter is a really good option for newsletters (though not for CRM or Drip Email).

Customer Relationship Management

CRM must necessarily start with the customer, and then builds out various customer interactions and touchpoints, as well as tracking their behavior in different campaigns. CRM is usually big-picture and is database driven. This can be difficult to use on a content management site (WordPress), as one is based on content and the other on customer relationships. WooCommerce probably has the best built-in CRM based on its ecommerce engine. Lots of info is available, and private notes can be added to transactions and to customer accounts.

Drip Email

Drip Email are messages sent at different intervals (hence the drip part) but it can also be triggered based on behavior. For example, if a newsletter goes out, and some number of people click on a new product description, they could be added to that special interest (of course it is a guess, but better than nothing). Then custom tailored newsletters could be sent in the future to focus on what was engaged with in earlier newsletters.

Other Transactional Email

Other email functions on a site are best supported supported by a generic contact plugin such as Contact Form 7, which is simple, powerful, and extensible.

Email Marketing Automation Requirements

In order to get the whole ball of wax, the following needs to be supported: - Interact with Newsletters functions (ALO Easymail) - Interact with Ecommerce functions (WooCommerce) - Single user database - Easy to configure multiple workflows - Easy to configure triggers - Easy to configure messages - Automation - Analytics (behavior/reactions to emails, e.g., open, click, and unsubscribe rates) - Correlation analysis, campaign performance - Integration with Google Analytics events (if possible and desired)

WooCommerce Options

WooCommerce already is customer-centric (an account can have 0-n transactions). WooCommerce (and WordPress user accounts) may be the place to extend email marketing automation, in terms of managing users, groups, and managing the analytics. What we need most likely is a CRM-centric system that then integrates into Newsletters as well as drip email workflow. The content could and likely should be custom posts (even so far as being Newsletters managed in ALO).

Email Marketing Automation Components

Use of Postman SMTP and the wp_mail function may be all that is needed for the actual sending of email. However, creating trackable links and receiving, rewriting, and logging them is an important complication. Other aspects include: creating and managing different drip email campaigns, the sequence of email (message content and time interval or behavioral trigger), using the cron system for unattended execution, some kind of alert system on positive or negative events.

Follow Ups by WooThemes

Follow Ups -- aka Follow-Ups, Follow-up, Follow-ups, and possibly Follow ups, Follow Up, Follow-Up, and Follow up (yes, there is no consistency, and the original was called follow-up-emails, that's right emails) -- is in fact a drip email system with triggers and timers, and also supports newsletters. As well there is integration with Sensei and various WooCommerce extensions and plugins, such as Bookings. This appears to be a great option, as the focus is to have this kind of Email Drip directly inside of WooCommerce, with all the email/list/message/newsletter functionality needed.

Advent of CRM

By extending WooCommerce with some custom admin fields, and using FollowUp, a rudimentary CRM essentially exists, though there are also some WordPress CRM plugins that don't require an external SASS component, such as WP-CRM (rudimentary, but appears to be useful), WooCommerce Customer Relationship Manager (currently breaks my site), WordPressLeads (negative reviews), and UpiCRM (which looks to be the most promising).

ALO Easymail has a variety of functions that work well

  • Subscribe, unsubscribe, double-opt-in
  • Email open tracking, link click tracking
  • Email newsletter templates, newsletters as custom posts
  • Email sending queue, cron support, reporting on send success/failure

What ALO Easymail doesn't do or do well

  • It can't resend a newsletter to a different list (sending is a one-time event, have to recreate the newsletter, assign mailing lists, and send again), effectively it ties the recipients and the sending event (and success/failure) to the newsletter itself
  • API does not allow creation of a newsletter, assigning of lists to a newsletter to be sent, or sending of a newsletter (all manual processes currently)
  • While it can report on send/failure on a per recipient basis, that is at the level of the newsletter, and the user does not have their send history available across newsletters
  • No ability to annotate or add notes about recipients, lists, or newsletters
  • Have to make a duplicate of a newsletter in order to send to more recipients

ALO Easymail Configuration

ALO Easymail Integration with Contact Form Seven

get_posted_data();
    $fields['email'] = $data["your-email"];
    $fields['name'] = $data["your-name"];
    if ( function_exists ('alo_em_add_subscriber') && is_email( $fields['email'] ) )
    {
        alo_em_add_subscriber( $fields, 1, alo_em_get_language(true) );
        $subscriber = alo_em_get_subscriber( $fields['email'] );
        if ( ! empty( $data["easymail-lists"][0] ) ) {
            foreach( $data["easymail-lists"] as $list_id ) {
                alo_em_add_subscriber_to_list ( $subscriber->ID, $list_id );
            }
        }
    }
    return $cf7;
}
add_action( 'wpcf7_before_send_mail', 'my_easymail_add_subscriber' );
Posted on

Encrypted Data in WordPress

It seems that there are some simple things that are not managed well on the security front, specifically the lack of encryption of the data stored in the database. While backups can be encrypted (by most backup tools) the data itself is not encrypted in the database. The main counter to that is if the host is owned, then anything the host can do, such as decrypt data, is trivial. But is that really the case? It seems there is some confusion about the very concept of access control. For example, while root can change a password, it can't know a password. And so there can be similar features of certain subsystems having access control over certain functions. That access can be basic rights access and that can be adjudicated by third parties as well. For example, the encryption/decryption function might require a certificate of some kind. A third party certificate server would be the one to legitimate the identity of the subsystem in the process of encryption/decryption. OAuth certificates issued by providers essentially enable a specific application to have communication rights. The same can be used for encryption/decryption rights, which is just another communication protocol. Having an embedded OAuth server in a local or neighbor system might be viable. Some other notes/thoughts: - WooCommerce says not my problem - User Data Encryption discussion on wordpress.org - Where to store user data

Posted on

WordPress DevOps Lifecycle

> This is a set of notes and remarks rather than anything comprehensive or systematic. The main point is learning from the fact that there is a development lifecycle in terms of consuming software products, and make better adoption decisions through a set of heuristics. By development, we need of course to expand this to encompass what is generally known as design, development, devops, sysops and ongoing maintenance. The key to reducing risk in WordPress development is to understand the lifecycle.

WordPress Development

By WordPress development, we can include all of the following: - Selecting a new theme or theme framework - Making a choice between plugins - Deciding at what point custom development is needed - Themes - Plugins - Hosting decisions - Security issues - hosting and operating system configuration - security plugins - secure plugins Obviously the term development is being used in its very generic sense. Still, we can separate it from marketing and from content, which are the two other legs of the WordPress three-legged stool we use as a platform for publishing.

Development Lifecycle

By lifecycle we understand that there is birth, growth, decline, and death. Development itself can be understood as the building up of something. We usually understand development as a period of time for building and a period of time for maintaining. This is obviously an architectural metaphor. However, it is really not useful or apt when looking at software development. Why is that? - Software can be refactored - Software can be loosely coupled or integrated with other software - Software versions are released over time, which tends to include more features - Software can become obsolete when it is rendered incompatible with other systems, software, or coding practices - Software can become unusable when new versions introduce new problems - Software can become a greater risk to use when it is abandoned by its original developers Finally there are financial considerations such as when free versions of critical plugins or themes are no longer available, forcing all users to pay or to spend considerable time migrating to others.

Risk Management

All of this comes down to the basic concept of risk management. Risk is danger to an organization, in terms of the likelihood and severity of present or future costs. While deciding which plugin to use for a contact form seems fairly innocent (and generally it is), things like multilingual, ecommerce, or elearning systems require a much greater investment in installation, configuration and maintenance, with much higher switching costs.

Lifecycle Heuristics for WordPress Development

Because a lifecycle deals with unknowns in the future, it is never perfect and there is always risk. However, there are certain heuristics -- rules of thumb -- that can be used to help mitigate and minimize risk. The following are an assortment of heuristics that, while not always accurate, do help minimize risk.

WordPress Theme and Theme Framework Heuristics

Most themes are not maintained for long. The average half-life of a theme (the amount of time by which the probability of it being abandoned is 50%) is most likely immediately after the first version is released. Many try to minimize this risk by paying for a theme, but the same is true of paid themes. Theme frameworks have a much longer lifecycle, as they are made for designers and developers who will pay maintenance fees in order to get some stability and continuity. Regular subscription fees are a motivator for theme frameworks to incrementally improve and maintain compatibility with the every changing panoply of plugins as well as WordPress core (which has major releases three times per year). However, yearly maintenance fees do not remove all risk, and the lack of yearly maintenance fees are not a sign of impending abandonment. Ultimately, one should consider any theme framework from the perspective of the following question: > If this framework is abandoned tomorrow, will it meet my needs and is it worth whatever maintenance I need to do myself, for the next two years or more? Since a framework will eventually be replaced (i.e., it has a lifespan, and is not immortal), risk management consists of a clear-eyed assessment of the functionality vs. maintenance costs (in time and money) as well as opportunity cost for going with a different system. Ultimately, one should build one's own theme and child themes. The risk of course is building something that does not meet present or future needs, and/or is too time-consuming to maintain. Several years working with other themes and theme frameworks for a given website or set of websites are the ideal approach to understanding the design space. Indeed, working with an incomplete or aging theme framework can be extremely informative in terms of producing a set of requirements for a theme and child themes that will provide excellent value for years to come. Some of the following may help flesh out the requirements from a functionality perspective: - No javascript or gracefully degrades without javascript - Support for screen reader CSS - Responsive design with target viewport dimensions - Plays nicely with all current plugins, especially those with important functionality, e.g., - WooCommerce - ALO EasyMail Newsletter - Can potentially replace one or more plugins where that makes the most sense, e.g., - Custom search and 404 pages - Remove author pages - Custom templates that display lists of all posts organized by category - Single CSS file

WordPress Plugin Heuristics

Plugins are a boon and a bane in WordPress. One needs many of them (some for a single tweak here or there to WordPress Core), they constantly age and require updates, are abandoned, conflict with one another and with new versions of WordPress Core. Here are a few heuristics that might help with risk management: - Older, massively popular plugins are in general a better bet (even if abandoned), because the large userbase will come up with fixes when problems arise. - There is one huge caveat to this, and that is monolithic plugins that continue to add features. This usually means ongoing problems and the introduction of new bugs. Yoast is the biggest poster child for a very popular plugin that breaks continually over the years. - Simpler plugins rather than more complex (best-of-breed vs. all-in-one) - Plugins that operate with shortcodes rather than wysiwyg drag-and-drop interfaces - Plugins whose configuration is stored properly in custom tables or extending custom posts and metadata - Examples include Redirection and ALO EasyMail Newsletter - Using custom posts, metadata and shortcodes makes the functionality more abstracted and does not require the front-end to use parameters such as ?variable=value - Plugins which, if removed, either degrade gracefully in terms of the content or data left behind, and/or are easy to work with using regex search-and-replace (e.g., unique shortcodes) - Plugins which do not have a pro (paid) version - Plugins which have a core part that is free and additional plugins that are paid are a better source of stability and risk minimization, as the core part needs to be maintained in order for the paid plugins to remain viable - Plugins with active development (even if sporadic) - That said, some of the most important plugins I rely on have not been updated for years (occasionally requiring I do a little hacking) - Plugins made by a supergenius who uses the plugin themselves (note the supergenius requirement, along with dogfooding) - Plugins around which an ecosystem has formed to extend and enhance - Plugins that use or can interact with the latest security standards and configurations - Plugins where support on WordPress.org is available (rather than requiring using an offsite system for help and support) - Ratio of 5 stars to 1 star reviews (should be around 10:1, whereas when it gets around 4:1 this signals poor quality) - Retention rate (Active installs / All time downloads) - Note that over time this ratio gets smaller naturally, so for very old plugins this doesn't work, but for 1-3 year old plugins it is a good indicator In some cases a set of plugins need to be replaced because of a need (or opportunity) for speed and/or security and/or functionality. For example, Postman SMTP allows for OAuth2, a new security standard. But this has knock on effects in that some Newsletter plugins don't support this, so it would require migrating to a new newsletter plugin. So a final heuristic is keeping up with good coding practices (without simply embracing every new (not necessarily good) idea.