New blog: ProcessWire modules directory

[ryan]

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/

 

[Ivan Gretsky]

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?

[teppo]

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.

[Ivan Gretsky]

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.

[Mikie]

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.

[Mikie]

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.

[ryan]

@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. 

[AndZyk]

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

 

[Mikie]

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. 

[nbcommunication]

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

[ryan]

@nbcommunication I'll have to investigate further, maybe it's possible to support down the road. For the moment, compatibility is based on what you specify in the "requires" section of your getModuleInfo() method, or ModuleName.info.json file or ModuleName.info.php file. But since you are wanting to communicate that the module is not compatible with a previous version of itself, I don't think there's an automated way to do that at present. For the short term at least, if you can't update the module to provide a backwards compatible option, then it might be worth maintaining as two separate modules. Or if you only want to maintain the new one, then maybe give the new one a new name and delete the old one, or update the old version README to instruct the user further. That would at least prevent anyone from automatically upgrading the module and finding it doesn't work. 

[adrian]

@ryan - I think it would be a little cleaner if the edit button didn't show for modules that you don't have permission to edit. At the moment it's weird to suggest that I can edit someone else's module, but when I click the button, I get: " Your account does not have permission to edit ....."

[adrian]

@ryan - I am noticing that if I click the Update button, it updates the version number (and other info from Github), but it doesn't change the "Updated" date which I think it pretty important. Thanks for taking a look.

Also, any chance of changing the dates from yyyy/mm/dd to yyyy-mm-dd so it's a little cleaner / more standard. I think as devs we are more used to the dashes when looking at this order of y, m, and d. I think it makes it clearer which is the month vs the day.

[adrian]

On 11/29/2020 at 1:45 PM, adrian said:

I am noticing that if I click the Update button, it updates the version number (and other info from Github), but it doesn't change the "Updated" date which I think it pretty important.

@ryan - any chance you can take a look at this please - I do think it's pretty important that the "Updated" data is accurate. Thanks!

[ryan]

@adrian Thanks, I have fixed it so it'll update the "updated" date when either the version number, or anything in the module info changes. 

[matjazp]

@ryan When there are more authors of the module, only one author name is shown, and it's shown twice, for example https://processwire.com/modules/auto-smush/ Roland Toth (tpr) is the coauthor.

[adrian]

@matjazp - not sure why, but it doesn't seem to be all modules, eg: https://processwire.com/modules/cookie-management-banner/

[matjazp]

I don't know where author names are pulled off...

[adrian]

Just now, matjazp said:

I don't know where author names are pulled off...

https://github.com/matjazpotocnik/AutoSmush/blob/3b9028c92bb4b380b542a479fd62a235f583968f/AutoSmush.module#L31

[adrian]

I wonder if it would be parsed correctly if you replaced those entities in your name with UTF-8 characters?

[matjazp]

Nope. Now the first author is matjazp (https://processwire.com/modules/author/matjazp/) and the second author is also matjazp (https://processwire.com/modules/author/matjaz-potocnik/). Check the first link, I didn't know I'm the author of so many modules :-) 

Edit: I even changed authors to "tpr, matjazp" to be the same as here in the forum. 

[adrian]

9 minutes ago, matjazp said:

I didn't know I'm the author of so many modules ?

Oh wow, you have been busy ?

Definitely weird that you are tagged as the sole author of some modules that aren't yours at all, eg. Admin on Steroids (https://processwire.com/modules/admin-on-steroids/). There is definitely something amiss here @ryan

[ryan]

@matjazp @adrian Looks like we've got a glitch there. Not sure what's up yet, but it seems to be in the old modules directory data and may have been there awhile. Matjazp had 2 accounts somehow and tpr/rolandtoth had none. I added rolandtoth as an author and updated the modules pointing to his GitHub account. I deleted the 2nd matjazp account (matjaz-potocnik) and reassigned those modules to the matjazp account. Let me know if I didn't get any of this right. So far it looks like there is the only case of the glitch, I couldn't find any others like it, though please let me know if you do.

By the way, module author names were pulled from the info entered when the module is submitted or edited (on the old modules directory site). They are not pulled from the module info on GitHub. On the new site, module author names are created with the account, and assigned to existing modules sharing the same confirmed email address. That's how it knows which modules are yours after you create your account. Some people might have used multiple emails over time, as I think both Teppo and I did, so in those cases I've been assigning some modules manually. 

Currently for new modules it just supports one "author", since it is now tied to a dedicated account. (Just like with a GitHub account). So when there are multiple authors on a new submitted module then the README is where you'd want to highlight that. It would also be fine to have an organization or company as the author of course, but it would still just be 1 account. 

[adrian]

19 minutes ago, ryan said:

By the way, module author names were pulled from the info entered when the module is submitted or edited (on the old modules directory site). They are not pulled from the module info on GitHub.

Yes of course - sorry, my bad.

The old system did end up creating a bunch of extra users, often without the module author realizing it. Glad that won't be an issue going forward.

[adrian]

@ryan - After logging in, you end up at: https://processwire.com/modules/login/login but on this page, the module search input is missing so you need to navigate to: https://processwire.com/modules to be able to access it. I think this is a bug. Thanks.