Label for 3rd Party Modules

[wbmnfktr]

In case none of you have a nice little hook for adding a label to non-pw/non-core/non-ryan modules at hand, I'd like to suggest and discuss such a feature to mark modules by explicitly with either ProcessWire / @ryan or 3rd Party Module.

Both for core and additional modules by Ryan in first place. The same for 3rd party/community modules.

Reasons

#1: Clients look into the modules section, see a huge list of modules, yet they were assured NO 3rd party modules were used. ?

Doesn't feel right for the client, even though it might be totally fine. Hard to explain to someone that does only understands what he/she sees.

There might be more very good reasons but this was my quite big annoying F**K UP last week.

Any thoughts, ideas, or hooks?

[szabesz]

9 hours ago, wbmnfktr said:

Any thoughts, ideas, or hooks?

Perhaps, next time you need to present the list of modules used do not show the /module/ page under the admin, instead, show /setup/upgrades/ (Upgrades module).

The Upgrades module has a LINKS column with links to either support, details or/and directory. Based on that, maybe with some clever deducting logic, rows of modules in this list can be labelled (by coloring, adding additional column, tooltip) according to their "author type". Provided the list is hookable...

 

[flydev]

Another option could be copy/paste the core ProcessModule inside site/module (it could be patched on ProcessWire version upgrade, if needed, automatically).

 

Maybe @Robin S will have a clearer idea.

 

 

[teppo]

On 4/11/2023 at 1:31 AM, wbmnfktr said:

#1: Clients look into the modules section, see a huge list of modules, yet they were assured NO 3rd party modules were used. ?

I know I'm cutting corners here, but in my opinion that distinction already exists: "site" and "core". This should be easy enough for a client to grasp, though of course you may need to explain it (at least) once first ?

ProcessWire is by design a modular system, even at the core level, and hiding that would mean that you are hiding a defining architectural design decision and — arguably — advantage over some other systems. If you need to go to such specifics (I haven't, and in fact I have never granted client access to modules at all, though that's of course more about business model; if the client hosts and maintains the site, they will need full access) I would argue that it's better to explain how and why this is actually a good thing, not an issue ?

Meanwhile (again in my opinion) "site" modules are third party modules, regardless of who developed them, though of course it's not a huge stretch to argue that those built by Ryan are 1st party. If you want to signal that Ryan's modules are from the project architect/lead, I guess that could make sense. Still sounds like an oddly specific requirement from the client, though, and I would again explain why some "official Pro-modules" are used ?‍♂️

[wbmnfktr]

Ok... so to give you a small update on this and the reason why I thougt about this feature in first place.

In my case, this time, the "client"* really needed to be sure that all enabled/installed modules are somewhat/somehow Core/Ryan modules. It's not about Ryan himself, more of... 3rd party-issues.

My "client"* needs a solution for a closed environment. All software, even for websites - or in this case - something similar to an intranet, needs to be audited. A website setup will be worked out in the future (hopefully), so every partner/affiliate should be able to clone a repo from Github (based on a master repo with all modules, settings, defaults audited ... - a site profile, ready to use, to be clear here).

They trust ProcessWire and believe in Ryan and therefore only wanted to go with his modules in first place, while 3rd party modules are fine BUT... they needed to know about those prior to install them ANYWHERE, or when in testing-stage needed to know if those are "3rd Party" to get them into an audit.

As of now we are already a step further and the "client"* looked up more and more, maybe already most of the modules we could need, already by his own DEV team.

To make it clear. They looked for things in the modules like base64-encodings, external resources, external scripts, hidden Google Analytics (and similar) calls, and what-not. Their DEV team is awesome... yes, they digged through a lot and were happy so far - even 3rd Party/community modules. There were some issues they fixed already in some modules - can't say which, as I really don't know.

But I got an "OK! Let's go." this week. ?

* THE CLIENT:

The client - is a new company of an old friend of mine - I worked with for 10+ years and they have to audit any software they use for their clients. They used Dr***l, Ty**3, and some custom solutions in the last few years and weren't that happy. A dummy/MVP-setup of mine brought them to ProcessWire with "huge success" (their words).

But to be able to release it to more real clients of them, they need to be able to assure some things... which brings us back to my initial thought and question we are working on right now.

To make it even more transparent: it's within the financial/automobile/insurace niche - so they are super strict with their contractors and partners (my client/friend).

TL;DR:
ProcessWire in a niche-software-solution, ready to be cloned from Github but with audited modules without any [shady-ish] scripts or whatever.