Jump to content
ryan

New blog: ProcessWire modules directory

Recommended Posts

There’s a new modules directory on the ProcessWire site now up and running. In this post we’ll cover a few details about what’s changed and what’s new. While last week's post introduced the modules directory, this post (part 2) focuses on newly added features for module authors (just pushed live today)—

https://processwire.com/blog/posts/new-processwire-modules-directory/

 

  • Like 15

Share this post


Link to post
Share on other sites

Great news!

The thing that bugs me though is making github account mandatory. Feels kind of like proprietary vendor lock in. Shouldn't there be an option to use gitlab/bitbucket/own git or a custom download url on an own site?

Share this post


Link to post
Share on other sites
1 hour ago, Ivan Gretsky said:

Shouldn't there be an option to use gitlab/bitbucket/own git or a custom download url on an own site?

While I kind of share your opinion on the vendor lock-in thing, I don't think this is going to be a big deal — as Ryan pointed out the vast majority already use GitHub, even though some popular modules are currently on GitLab. Looking at this from Ryan's point of view it's likely less work to develop (and maintain) features when you're using a single API rather than multiple... and if that helps Ryan keep things up and running, I think it's a good approach.

Also personally every time I want to report an issue or send a pull request (or merge request in GitLab) it's a bit of a nuisance if the module is not hosted on GitHub. What I'm trying to say here is that since GitHub is the most popular option by far, as well as the platform we're using for core development, hosting third party modules there makes collaboration easier 🙂

Regarding "own git" or "custom download URL" it's good to keep in mind that a lot of the data can be pulled automatically via GitHub API, and this would defeat that purpose. Custom download URL would also be potential risks in terms of security — public git repository, and preferably one with a GUI, is a must-have for this exact reason.

  • Like 2

Share this post


Link to post
Share on other sites

I wouldn't ask to maintain multiple APIs. Just feel that making a link to Microsoft's github repo a required field is a bad decision. Like making github auth the default method for site authentication, not allowing email. What would happen to https://processwire.com/modules/pad-loper/ and alike, that cannot provide a github link?

I would suggest making github a single option for automation, leaving plain textarea for description and url for project link a general option. That would probably suit everyone, making possible both code hosting platforms of choice and paid modules listing.

  • Like 3

Share this post


Link to post
Share on other sites

Heya, love to see module site in the refreshed look!

Am I something here... where is the module class name and version compatibility info listed in each module?

There is the user modules list on the left hand side which seems to output class name, but it quite hard to copy from and not noticeable at first.

Share this post


Link to post
Share on other sites
7 minutes ago, Mikie said:

Am I something here... where is the module class name and version compatibility info listed in each module?

Just noticed the class name up the top in the blue banner as a sort of title. 

I still think the class name needs to be spelled out in the module info panel on the right. If you are new pw developer and see the instructions in "Add Module from Directory" section of the admin then you will visit a module page and look for the class name.

Share this post


Link to post
Share on other sites

@Ivan Gretsky GitHub is a requirement for modules that are automated with regard to automatically pulling version and readme, etc. If someone needs a case where the module can't be managed at GitHub (like a commercial module or other specific case) then I would just ask them to contact me so I can add it manually. 

I feel it's safest for our users by having downloadable modules provided by GitHub. They have security measures in place that give me a lot more peace of mind than a link to a random ZIP file off on some site none of us know. Without GitHub as a middle man, I think there's a much higher probability of getting something questionable in a ZIP file, whether it's because of a hacked site or any number of other reasons. GitHub also provides great security options for protecting individual accounts, which I think further increases the safety for consumers of ProcessWire modules. 

The other side of it is that GitHub provides an API that we can read data from in order to ensure our module information is up-to-date and that users don't have to manage that information in more than one place. That API also includes a function to safely convert GitHub-flavored markdown to HTML, which is very useful for the modules directory. Presumably it would be possible to also implement this for other providers (GitLab was mentioned), so if there's significant demand for it then it would be worthwhile. But it took me a long time to implement the GitHub integration as it is, and at present I likely couldn't afford the time investment to implement another different API right now. Down the road I'm open to adding support for more Git providers. For now though I had to work within the bandwidth I could afford to devote to this project. 

@Mikie

The module class name is used throughout, but it's true it doesn't literally say "class name:" anywhere. I think you are right it would help with clarity if it does that somewhere, so I'll plan to add it. As for version compatibility, I'm going through all of the PW 2.x modules and deleting any that aren't 3.x compatible and don't look like they will be. This will take me a little while, but basically the intention with the directory is that you can assume it's 3.x compatible. For more fine grained detail on version compatibility, it's going to read the module info array. It doesn't report that info at present, but this project isn't fully finished yet so it will be reporting more from the module info array in the coming weeks. 

  • Like 3

Share this post


Link to post
Share on other sites

First of all thank you for the new modules directory. I haven't dig into it for now, but it is nice to see that this also now has been updated. 👍

One thing that could be helpful for the directory: It is not very helpful, that the background-color of selected text is almost identical with the brand primary color. That way you almost cannot see selected text on a primary section, like the header section with the module class name. Maybe you should consider styling the background-color of the selected text with the secondary color (purple). 😉

Regards, Andreas

 

Share this post


Link to post
Share on other sites
On 11/23/2020 at 3:51 AM, ryan said:

The module class name is used throughout, but it's true it doesn't literally say "class name:" anywhere. I think you are right it would help with clarity if it does that somewhere, so I'll plan to add it. As for version compatibility, I'm going through all of the PW 2.x modules and deleting any that aren't 3.x compatible and don't look like they will be. This will take me a little while, but basically the intention with the directory is that you can assume it's 3.x compatible. For more fine grained detail on version compatibility, it's going to read the module info array. It doesn't report that info at present, but this project isn't fully finished yet so it will be reporting more from the module info array in the coming weeks. 

Awesome cheers Ryan. 

Share this post


Link to post
Share on other sites

Hi @ryan,

The new modules directory is looking great and what I've used so far has worked great 🙂

I've a request for you to consider. Would it be possible to mark major version changes as not backwards compatible?

The use case: We have a module PageimageSrcset, that contains a number of features that I thought would be useful at the time of writing, but I myself have never/rarely used (e.g. generating the sizes attribute value from an array of UIkit classes). In a future version I'd like to remove these features, and have the module be more in line with its purpose. I have enquired on the board, but not had any response to say that any of the features are being used. 

The solution as I see it, would be to release a new 2.0.0 version (currently 1.1.0) which removes these features, and any users with 1.1.0 installed would either not be able to upgrade directly (would require manual upload), or would be given an additional warning that the version introduces breaking changes and to check GitHub/support board before upgrading.

Is this possible?

Cheers,

Chris

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...