Jump to content

Public Module/Theme Collection


Nico Knoll
 Share

Recommended Posts

Hi,

I don't know if this is the right place for this wish but I think so. Well, my wish is to have a point on this site (maybe at the current position) where you can download modules and themes and upload your own and their upgrades. So it would be easier for Ryan, because he wouldn't have to collect each module, the community would have a better overview about as much as all of the modules for PW and maybe later Ryan could implement an auto update function for plugins which are in this collection.

So for each plugin there could be an entry in the collection (with a download link, screenshots, a description,...) and an entry in his forum for problems or general questions of users who are using this module.

Greets,

Nico

Link to comment
Share on other sites

  • 2 weeks later...

I had a recent chat with Ryan regarding encouraging everyone to use Git with some common naming conventions and file structures for add-ons so we could leverage Git and in particular the submodules commands to create a nice framework for supporting PW module/theme/snippet upgrades and rollback/tracking etc. To get some Idea of how this might work (in my mind's eye) see this useful article on the Symphony CMS site http://symphony-cms.com/learn/articles/view/getting-git-for-symphony-development/ - especially the section on adding extensions to Symphony as submodules; what do you think guys?

Link to comment
Share on other sites

It seems like a great way to do it. Admittedly, i'm not quite at the level with Git where I understood everything that was going on in that tutorial (and you just motivated me to put in an order to Amazon for a book on Git). But this seems not far off from what I'm already doing to keep my PW installations up-to-date, as well as 3rd party modules. I've not used Git submodules before, so that's something new to me. Currently I'm keeping my 3rd party modules as individual repositories. Since I'm running multiple PW sites on one server, I'm using symlinks to link in any modules I want with a site (1 repo per module, shared among multiple sites). It seems really simple, so not clear what advantage submodules would have over this. Though there may be some significant differences in the file layout structure of Symphony and PW that necessitiate the approach they are using. But like I said, you motivated me to buy a book so I can put some real time towards getting more in depth with Git. :) I have a feeling I'm missing something obvious.

Ultimately I'd like for people to be able to add and update modules from the admin without having to go through version control or even their file system. It'd be great if they could just plug in a URL to the module and then have PW take care of installation and notifying them when it needs an update. That's a ways off, but I'm just thinking that it's got to be as easy as possible. To me, the people using Git to manage their site are more the hard core users and open source developers that really know their way around, and that's just one segment of our audience.

I think that almost all the PW modules are available on Git at present. Usually we'll post to the forum for test versions, and then post to Git once things are pretty well set and ready for distribution. This is what I'd recommend for all modules. Perhaps this should be a pre-requisite to be listed in the module directory on the new site.

Link to comment
Share on other sites

That's some good sound in my ears. Can't wait to see something like this in PW :D This will for sure simplify module management. But I still don't really understand git well enough to be a help with it decide what would be best. I just know how to simply manage a repository...

@ryna Also nice to hear symlinks can be used to have one rep of modules for multiple PW's on the same server. Are you linking the whole module folder? Would this be possible with templates aswell I guess or the core?

Link to comment
Share on other sites

But this seems not far off from what I'm already doing to keep my PW installations up-to-date, as well as 3rd party modules. I've not used Git submodules before, so that's something new to me. Currently I'm keeping my 3rd party modules as individual repositories. Since I'm running multiple PW sites on one server, I'm using symlinks to link in any modules I want with a site (1 repo per module, shared among multiple sites). It seems really simple, so not clear what advantage submodules would have over this.

I ended up with exactly same method - I tested and did had submodules working, but I really didn't find any benefit from those over symlinks. So that is probably just because pw works well with symlinks.

Link to comment
Share on other sites

Soma, as I understand it, Ryan has neutral directory modules with each module, and in each installation, he symlinks modules he want into the installation.

Probably just like this. My setup is like this:

/www/processwire/modules/AdminBar

/www/processwire/modules/Discussions

/www/processwire/modules/ProcessRedirects

etc... these are all git clones so I can update them with just git pull.

And when I need module in one of our sites, I just say in my /site/modules folder this: ln -s /www/processwire/modules/AdminBar and voila.

I also keep two different versions of wire folders which are symlinked. I have named those P21stable and P21head. All of our sites use stable version, but I regularly test with dev versions that they also run head. And if I need something from head, then I will update stable to latest head. Of course it might be that I need more versions (and of course P22, P23 etc..), but so far this has worked fine!

Link to comment
Share on other sites

I ended up with exactly same method - I tested and did had submodules working, but I really didn't find any benefit from those over symlinks. So that is probably just because pw works well with symlinks.

hadn't thought of that and a good point.

Ryan, I agree it's not ideal long-term esp. for hosts that don't have access to command line/Git etc. plus users who don't want to learn all that but agree it makes sense short term until there's a built-in system in PW. My main point was that we're almost there with Git in any case - so some sort of official endorsement in the docs on the PW site might just help make sure all add-on components find there way to Git rather than downloads from other sites, forum attachments and so on. I'm just thinking some sort of unified approach here might be very useful given the way modules/themes are starting to really take off. I've no particular preference with submodules or sym links (and I use submodules with different remote repositories so I think either approach can be made to work without especially changing the way things are set up now)...

Link to comment
Share on other sites

I agree, we'll want to officially endorse GitHub as the place to distribute your modules. The modules documentation is primarily contained in these forums at present. So what really needs to happen is for there to be a real modules documentation in the site (the ball is in my court on this), and that will be the place where we can say people should use Git for distribution. In terms of timing, I'm thinking we'll get this all going together, with the new modules directory on the new site.

Link to comment
Share on other sites

Thanks Ryan, I think using Git can still be the basis for the eventual 'package control' I think... for example Sublime Text uses this method for installing and updating add-ons (and the users are insulated from the fact that this is what's happening)

Link to comment
Share on other sites

I was going to say that some sort of insulation would be good as you said Martin.

Not everyone will understand Git, but I think they might be far more likely to be able to get to grips with Pw so some simple way of installing modules would be the way to get around this.

In fact, thinking out loud (and I'm sure some of this has already been discussed elsewhere on the forums), could the first version of the modules directory simply contain module info, author info, screenshot (if neccessary) and the link to the direct download link on GitHub (if their terms allow this) else a link to the download page for the package on GitHub.

A later stage would be a fancy module installer I guess, but something like the above would suffice for now I think.

I'm also assuming something slightly more complex could be done assuming you can pull the number of downloads from GitHub using their API?

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...