Add-on listing for

Continuing the discussion from Ideas for Google Summer Of Code 2017:

Thanks for your interest, @pavithirakc

Currently the page has a link to "all Plone add-ons" and to "all Plone 5 add-ons"; these are queries run on, where eggs are released to (this is where you get the name of the egg you put into buildout.cfg).

About 3.5 years ago, the Plone community started a project called to try to evaluate objectively the "best" add-ons for Plone. The project died because it ended up being too much work. That is why has a (lame) list of recommended add-ons... it was a first cut created by a small group of people, and it's no longer up to date.

Alexander Loechel started so we could use it on and it would be great if it could get finished. It would serve as the basis for identifying "good" add-ons.

Alternatively, rather than doing pure coding, you could come up with a more streamlined system or process for identifying good add-ons, something that is better than what we tried with and yet that doesn't depend on thumbs up/down ratings as they used to on (people would not bother to log in to register their thumbs up or down on a particular add-on).

I don't know if it would fare the same fate as "two thumbs", ie too much effort to login and vote, but I have an alternative idea with the following benefits

  • you don't have to find all the add ons you like and click like for each one
  • doesn't rely on download stats from pypi which are somewhat meaningless.
  • doesn't require you run buildout on your production instances
  • gives some more useful stats like which plugins are used together, which plugins are compatible with each other or with a given plone version.
  • could have a gamification motivating feature of listing who manages the most plone sites. With two thumbs your effort wasn't personally identifiable which could have reduce its uptake.
  • doesn't rely on subjective opinion.

The idea is that would invite you to create a small zmi python script with same pasted code. This code does an audit of the installed plugins and creates a POST form which sends the data to You would then have some options of blocking the site url from appearing on and some of the plugins (in case they are sensitive). You would have to run this once per site you manage but only once after you first create it, or do any major upgrade.
Then of course can use these stats to sort plugins by "most installs" as well has have badges which indicate the plone version is used on and what other plugins this is commonly used with.

1 Like

Ah yes the phone home idea... I'm in favour as long as an admin can disable it (opt out or at least an installer question that asks them to enable it to help us).

That would provide good data.

However, the work on the add on listing needs to proceed so we can at least display Plone add ons on

@tkimnguyen read it. it's not the same phonehome you are thinking of. The phonehome plone addon idea doesn't really work because it's actually more work and more risk to install a new addon in an existing production site than is worth to give ploneorg that data. Plus everyone is concerned like you are that you won't have control of the data transmitted.
The process I outlined avoids both of those problems.

Unless we do come up with a way to keep plone plugins on up to date and relevant (ie suggesting the most popular?), is it worth it? Won't it just degrade into a mess like before? or is the plan to just show what pypi shows?

Hi @tkimnguyen @djay. Thanks for the response. I went through the above discussion and related discussions at , add-on listing , Paragon vs ploneawesome .

Here is what I have understood about the idea so far, Please correct me if I am wrong.

  1. The purpose of ploneorg.addonlisting is to create add-on listings for in a visually engaging manner. Allow highlighting of curated add-ons(editor's choice) , simpler/cleaner descriptions of add-ons with relevant tags,version compatibility, and automated retrieval of data from, sort by rating/recommendation.
    Initial version of this at
    2)In order to get data about the installations of the addons, compatible versions and other such data, a zmi script can be invoked by the admin. It would send POST data to the
    3)Some examples for inspiration that were referred in the above mentioned discussions were,

I have a few doubts, though.

  1. Where can I learn more about zmi python scripting in Plone?
    2)When and how would the admin be invited/ reminded to invoke the script?
    3)To quote from the discussion at add-on listing,

would the script help in getting these extra statistics/data as well?

I have started to read through the code for ploneorg.addonlisting at . Any suggestions on what to do next?

1 Like

@pavithirakc Just to be clear the ploneorg.addonlisting and phonehome (via zmi script) ideas are different. I'm not the mentor for this project so you don't have to listen to my input.

addonlisting intends to take download stats and compatibility info from pypi. Pypi download stats depend on things like how often versions are released and how often people run buildout I suspect. Compatibility information on pypi is only up to date for people who remember to update the classifiers. But people could be reminded more often if its more visible.

good question. Possibly whenever they view addons they can be reminded to add the sites they own. Possibly there could be a mail campaign once a year to rerun to ensure the data is fresh. Otherwise decommisioned sites would still be in the data.

I think phonehome stats do give us an indication of it its quality in that it tells us that is good enough to be used in X number of sites. Neither pypi or phonehome tells us about tests or being translated. Pypi does give an indication of maintaince however via last release date and frequency of releases which would be useful to include. But then certain kinds of plugins don't require frequent updates.

Nice analysis, @pavithirakc

It's up to you what's next.

You could complete ploneorg.addonlisting so that we can get it onto - I think that would be a nice feather in your cap, to be able to point to something you helped write that the main Plone community site is using in production. However, on its own it may not be a very demanding project; it will require attention to detail and some design work, if I recall correctly (@Alexander_Loechel can provide more direction).

If you can come up with a solution to the stats problem, that would be nice for the community as well. But again, is that a GSoC-worthy project? It's less about coding than it is about human problem solving, if we go with the "human action is required, even periodically" approach.

Or you could plan on trying to use some "no human intervention required" approach, which probably shouldn't rely on pypi statistics, but should rely on some sort of (optional?) reporting (periodic or maybe one-time) from each Plone deployment.

To answer your questions:

  1. ZMI Python scripting means going into a Plone site's Management Interface, e.g. http://localhost:8080/Plone/manage_main and adding a "Script (Python)". These use Restricted Python so imports and other possibly harmful things are not allowed; however they probably can do what @djay suggests.

  2. That's something you'd have to propose :slight_smile:

  3. Yes

That's a nice thought: add a viewlet to the Add-ons control panel. It could show some interesting stats on the installed add-ons based on what has already been gathered centrally; it could also include a button to "Help Plone by sending anonymous non-sensitive information about the add-ons on this site".

IMO I'd like this feature to be part of Plone core. Or in the unified installer, and a decision on whether to make it an opt-out or an explicit yes/no.

Hi @tkimnguyen. Other ideas that were of interest to me(but not listed in the final list of GSOC ideas) were an e-commerce add-on for Plone ( enhancements), integration of Plone with Discourse forums and an enhanced theming editor that lets you drag & drop elements around, a la Do you think any of them would be GSOC-worthy? If so, would they be given equal priority as the other ideas already listed. Also, would it be difficult to get mentors for these ideas?

@pavithirakc as I am the current author and maintainer of that ploneorg.addonlisting package / project, you could also work with me on improving it and het it ready.

I'm not sure how much work needs; @jensens and @agitator would know more.

Plone & Discourse integration would be nice - we might even end up using such a thing on

Drag & drop in the theming editor would be pretty awesome, and of these three ideas, would definitely be GSoC material in my opinion.

Given that I added those ideas to the list, unless someone else wanted to step in I could be a mentor for them. For the shopping cart, though, @jensens or another Blue Dynamics Alliance member should be the mentor.

I don't think the ideas listed at are the only acceptable official ones, but I'm not closely familiar with the rules. @cewing would know.

Hi @Alexander_Loechel. Plone add-on listing is definitely one of the ideas that I am interested in. I am planning to apply for GSOC this year and would like to work on a coding-intensive idea proposal that would need 3 months of development time. @tkimnguyen had mentioned that completing ploneorg.addonlisting in itself may not be a demanding project that would get accepted in GSOC. What do you think about it? Is it possible for the idea to be expanded to result in a plan of action for 3 months? Or do you suggest that I go ahead with the other ideas that were of interest to me?

Hi @pavithirakc

Plone Add-on listing might not be a project for intensive 3 Month alone, but it is just one of several Addons that need some love that help the Plone community in Total:

  • plone/ploneorg.addonlisting <-- listing Plone addons

  • plone/ploneorg.releasesecurityinfo <-- listing Plone releases and security hotfixes

  • plone/ <-- current Plone hotfix listing --> should go into releasesecurityinfo

  • plone/plone.vulnerabilitychecks.core <-- which is a module with this phone home element

  • plone/plone.vulnerabilitychecks.* <-- Check modules for knowen security vulnerabilities in Plone installations.

So all of those together could be a nice project for GSoC. So if you are interessted, I would be glad to mentor you


Thanks for the response @Alexander_Loechel. I would like to work on the above mentioned GSOC idea. I am currently going through Plone docs on add-on development. Please let me know about what I could do next.

@pavithirakc the Docs are a good starting point.

Follwoing sections should be very useful for this topic:

also maybe read some of the source code of those packages we want to work on.


@pavithirakc, @tkimnguyen

One of the ideas on the ideas list is "Your Own Idea", which I've always read as "feel free to propose any project that interests you". The idea here is that working on code you are invested in is the best way to ensure success. If you have ideas that are not on the list, we welcome your proposals.

I would temper that by saying that you should investigate if any of the mentors listed (or any community members who are not listed) would be interested in mentoring your idea. We do have a pretty good idea of what will and will not work for Plone.

1 Like

What about combining the vulnerabilities checks and the stats.


Because to check for vulnerabilities you need to compare the packages and version you have installed with the packages versions in a central vulnerabilities database. So we would have at least good stats about the usage of Plone out there. We should not save to much data on here, because we don't want to create a database which can be used to find out how has vulnerable packages. But if we don't save the ip's and url, but just stats about packages and versions it should be fine.

But on the other side the control panel in Plone could now tell the admin if some Plone version needs an upgrade. It could also extended to add-ons, which i would recommend.

With this in place, we could also have the needed stats for a add-on listing on and also good s stats about, the Plone installations out there.

I don't see any problem here, but maybe i miss some thing.
Feedback welcome, any thought about that?

1 Like

@MrTango nothing wrong with the idea in theory but even with motivation knowing if your site is vulnerable or not, it would still take a lot of time to get installed on a reasonable % of sites. To even get it installed on most new sites it would likely have to be in the core. This plugin already exists for example -
Also, most maintained sites have support staff who already are aware of security patching. Those that aren't, aren't likely confident enough to install this plugin.
So I think it would take sometime to get meaningful data. Hence why I suggested the temporary shortcut of a manual process anyone with admin access could do without having to touch buildout. But I guess it could also give a warning about vulnerability status too.

I think this should go into core as long as people can opt out. If we take care not to transmit or store sensitive information about the site.

1 Like

having a listing is better than not having it.
Maybe just make something simple while we wait....

Title, description, link, 'state' ( alpha, beta, can be used on mission critical cites, 'can not'... )