WordPress.org

Ready to get started?Download WordPress

Forums

[Feature request] activated plugin : more information upon activation (4 posts)

  1. Daiv Mowbray
    Member
    Posted 1 year ago #

    I've been thinking about this for a while now.
    When I install and activate a plugin I am left wondering the following:

    • how much ram does this thing use?
    • how many option settings have been added to my database?
    • How many if any tables have been added to my database?
    • does this plugin have a deactivation function?
    • will deactivation remove tables and options?
    • what files or folders have been added to the server? (outside of the plugin folder)
    • which java script files have been registered for enqueuing?
    • which css files have been registered for enqueuing?
    • is this plugin doing a check in with some other domain?

    Yes I know there are plugins to read the ram usage. And a plugin to scan and clean the options table, yes I do check my data base for new tables and yes I do test on a local server with out-going connects locked down. In fact I often read through the code of a plugin to check for it's quality.

    I don't think the average WP admin can always go through all the required steps to check the quality of a plugin before using it.

    I believe that this type of granular information could be provided to the site admin upon plugin activation, and remain available (updated) in a fold down under each activated plugin.

    I believe that this type of information (and perhaps more) is valuable for any and every WordPress installation using plugins.
    This could be very helpful towards improving site performance, site security, lowering server load, and improving the general WordPress community.

    Some of this can be provided by the plugin author in the readme.txt header. Not as a requirement, but as a recommendation.

    If anyone knows of a plugin which can do all or most of this please let me know,
    Thanx,

  2. catacaustic
    Member
    Posted 1 year ago #

    While I can see the point of a fair bit of this, I personally believe that it's not useful or worthwhile to have that sort of information.

    Firstly, there's no guarantee that a plugin will use a certain amount of RAM. What happens if the plugin is used to crunch some data? There's a huge difference between RAM/CPU usage for doing that with 10 or 20 records rather then 2,000,000 records. This can also be affected by server settings, caching and other factors that are outside of the authors control or knowledge.

    Showing database tables is also pretty useless. If people are like you (and any other good admin) they will monitor their DB when they are installing and they'll know what's happening anyway. Anyone that doesn't know how to do this, or doesn't want to do this, is going to get either frustrated or confused from all of the extra info that they just don't understand.

    What most of it comes down to for me is that I want ot keep things as simple as possilbe, because most of my clients don't understand what's going on behind the scenes, and just don't want to. Giving stats like this also leads to panic... "Oh, but this plugin does almost the same thing, but uses 1MB less RAM so lets use that and the server will stop crashing...".

    On top of all that, what's to stop a plugin author giving incorrect information? How would you know that when a plugin is classified as using 2MB, it won't really be using 64MB? Most plugin authors are good, but there's always going to be some that will do whatever it takes to boost their plugins popularity.

    My last point is this: If a plugin does need a lot of RAM, it does ad din a lot of extra DB tables, and it does a lot of stuff that will cause a lot of server load, but it does EXACTLY what you want it to do, would that stop you from installing it? The stats are a good idea, but in the end it's the functionality that matters to clients, not the metrics.

  3. Daiv Mowbray
    Member
    Posted 1 year ago #

    Hi,
    Ram consumption would be read from actual on the fly usage.
    When you activate a plugin the WP system ram footprint increase.

    If the plugin is a widget to show a thumbnail for example, and it uses 12 mega of ram on activation, there's a problem.

    Since there is a move to filter out low performing plugins from the repository, I put the above forward as a possible path to achieve that end.

    As for your clients, well, if they are freely installing and activating any plugin they like, then more info would be helpful to them.

    As for the decisions one makes regarding the usage of plugin x or y, well that is based on what you want to happen. For example, I have removed and stopped using plugins due to bad coding and higher than needed ram consumption. In most projects I've been involved with, most of the plugins are "wants" rather than "needs".

    My above suggestion is based on what I think may help to make an informed decision between plugin x and y, or if a custom solution will be needed.

  4. catacaustic
    Member
    Posted 1 year ago #

    Ram consumption would be read from actual on the fly usage.

    How would you calculate that? PHP can get total RAM used, but it can't differentiate between WP system and plugin usage. It's also hard to calcuate that when you're installing a plugin as it hasn't had any usage yet, unless you mean on the developers testing system and that doesn't have much correlation to real-life usage most times. Reading RAM usage at activation also doesn't have any correlation to how a plugin is used on your public site as admin functions and public functions are normally vastly different.

    As for your clients, well, if they are freely installing and activating any plugin they like, then more info would be helpful to them.

    The clients that I deal with get scared when you mention "log into your admin area". They have got no idea of what RAM usage is, what DB tables are and if they had to look at that sort of information, they'd run away screaming. They are not normally the ones that install plugins, but they have that option after the site is handed over to them.

    Don't get me wrong, I think that there's a lot of good ideas in your suggestion. In my real-world usage of it dealing with our clients this sort of level of information isn't needed, is confusing and will lead to way to many questions form people that don't understand when you tell them the answers. If yu're dealing with decent developers then sure, these things can make a difference, but if you're a developer of that level you can easily find these things out for yourself, and you would not blindly trust what someone else is telling you. You would also b eevaluating different plugins to see what they do based on your own criteria, which will change form project ot project. You also have to remember that some server platforms run differently, and the performance metrics that are measured on one platform may not be the same on another platform.

    There may be aplace for a plugin that can give you this sort of information if it's required and that would most likely be a usefull thing to have on some sites that are worried about performance. I jsut think that as an overall fully-emcompasing requirement, it just needs more information then is realistic for most users.

Topic Closed

This topic has been closed to new replies.

About this Topic