Module development in ProcessWire - development environment?

[Gadgetto]

Hello,

it would be interesting to hear how other developers setup their development environment for developing modules in ProcessWire.

For me, the question arises because I come from the MODX world. Under MODX it makes sense to develop plugins outside the MODX core. This means that for each newly developed module, a project folder is created outside the MODX core (wherever the developer wants). The complete development takes place there.  By means of certain directives, the module under development is linked to the MODX core. For MODX this looks as if the plugin is located directly in the /core/components folder.

Beside others, this has the advantage that the plugin can easily be tested in several different MODX versions without creating multiple copies in parallel.

How do you develop your modules in ProcessWire? Directly in the /site/modules directory? 

Is there a best practise?

Greetings,
Martin

[kongondo]

4 hours ago, Gadgetto said:

Under MODX it makes sense to develop plugins outside the MODX core.

The notion of core in MODX might be different from the one in ProcessWire (maybe?). Btw, I don't know if you've seen this post on MODX to ProcessWire welcome brief? It might be of interest ?.

One of the philosophies of ProcessWire, one that makes it very extensible is the fact that everything, all its building blocks is a module. Yes, even the admin (backend) is a collection of modules. Modules are just  PHP classes. You have your classes  (i.e. modules, or the site's custom classes) and these live here: /site/modules/. ProcessWire has its own core classes: the ones designated as modules live here: /wire/modules/. The are other classes, in fact, the main classes of ProcessWire, aka the core, and these live here: /wire/core/. In order for ProcessWire to know about and register your classes, they have to live where ProcessWire expects them to, i.e. /site/modules/.  Now, this does not mean that all your classes have to be modules. No; you can have custom classes (i.e. my_class.php) living in /site/modules/my_module/my_class.php or /site/templates/includes/my_class.php (@note: includes here is just arbitrary) which you access from within your registered classes (modules) or from within your template files. Any attempt to access such classes directly will be blocked by ProcessWire for security reasons.  This just means you can have helper classes or other libraries you need for your modules which ProcessWire does not need to be aware about (in respect to registering them). The foregoing means that...

4 hours ago, Gadgetto said:

This means that for each newly developed module, a project folder is created outside the MODX core (wherever the developer wants). The complete development takes place there.  By means of certain directives, the module under development is linked to the MODX core

..is not necessary in ProcessWire. your /site/ is already outside the core. It survives upgrades and ProcessWire never touches it. It just communicates with it (bidirectional communication). All ProcessWire core variables (e.g. $wire, $config, $fields, $page, $pages, etc) are available everywhere for your use, both in the backend and the frontend. I hasten to add that ProcessWire will not automatically install your modules for you. If it finds a new module, it will just let you know that it has found a new module. If it finds duplicates of the module, i.e. either duplicated under /site/modules/ or under both /site/modules/ and /wire/modules/ , it will alert you to the fact and will ask you to choose which one you are going to use. This means that you can duplicate a core module found in /wire/modules/ under /site/modules/, edit it to suit your requirements and ProcessWire will happily continue serving the copy under /site/modules/ and yes, it will survive upgrades. This is not always a good idea though, as the mother module could get some upgrades which you would be missing on and/or require.

So, in ProcessWire, we develop our modules under /site/modules/. Most people who develop modules use a versioning system, invariably git, and host their modules on GitHub, BitBucket, GitLab, etc. Secondly, many people make use of git's branches and work in the dev branch. All development and testing is done under that branch. When ready for production, they merge into master branch. For modules submitted to the ProcessWire modules directory, if the project (code) is hosted in GitHub, ProcessWire (the site) reads the master branch of the project to access the README and the download link.

4 hours ago, Gadgetto said:

Beside others, this has the advantage that the plugin can easily be tested in several different MODX versions without creating multiple copies in parallel.

In the past, I have used symlinks to link my module to different ProcessWire versions. For a quick and dirty check, I have occasionally had two wires, e.g. wire and wire27 which I rename to suit my needs RE ProcessWire version. Many of us here develop using the latest ProcessWire dev. I cant' speak for everyone, but I think many then use (if they need to) a ProcessWire 2.7 just for final tests. I doubt many of  go back and forth between versions (i.e. between 2.7 and 3).

4 hours ago, Gadgetto said:

Is there a best practise?

No ?. As long as you name your module classes as per ProcessWire requirements work with what suits your needs. The above is just the basics. We have people here who work in teams and have slightly different approaches, but the basics are the same.

Edited December 17, 2018 by kongondo
correction about custom folder under /site/templates/

[Gadgetto]

@kongondo wow, I didn’t expect a full tutorial in answer to my question! Great! This community is one of the best I’ve ever seen!

[horst]

I'm on win7 and use different PW and different PHP versions in parallel, by switching symlinks.

I create individual site folders for each project, regardless if it is a client site or a module. Then I copy shell scripts of the desired PW versions into the webroot folder of the project, and by executing one, it creates me a wire folder, symlinked to the desired PW version.

This way, I can switch between different PW versions with one or two clicks.

To test with different PHP versions is possible with executing shellscripts of my allday editor NoteTabPro. It shutdown the running apache service, symlinks the apache main directory with one that suports the desired PHP version and starts the service again.

[adrian]

You can also switch PW versions instantly with Tracy. By default it works with versions which are archived by Ryan's PW Upgrades module, but there should be nothing stopping you from recreating those archived version manually by creating .wire-x.x.x folders with the contents of that version's wire folder.

[Gadgetto]

The TracyDebugger method seems to be the easiest one! Thank you for the hint!