Weekly update – 17 December 2021

[ryan]

This week ProcessWire has gone on a diet. I've been working on reducing the size of the core by moving all (except site-blank) installation profiles out of the core and into their own repositories. This cuts the size of the core in half, going from 15.5 MB down to 7.5 MB, which is quite a slim down! 

This means the site-regular, site-default, site-beginner, site-languages, and site-classic now live in their own dedicated repos on ProcessWire’s GitHub. The site-blank one remains, but I've updated it a bit to make the template files more useful for beginners while still keeping it a blank profile. I may do a little more with it and rename it to be site-basic or something, and then have an even more trimmed down site-blank in its own repo as well. I'm not yet sure about that, so will do a little more with it next week also. I also went through each of these site profiles and cleaned up a few things, corrected old and outdated links, and updated a lot of text in readme files and such. 

I think a lot of the more experienced users would also prefer not having extra profiles included in the core as well. This update came at the request of the community a few months back (I think it was Robin S. that requested it, but not positive). It's not like any of the current site profiles have a lot of bling or marketing value, as they really are more just technical examples and starting points. So I think it's kind of a win/win to trim down the core in this way. Though maybe one day we'll have a site profile that looks good and has good marketing value. But until then I think we gain more by keeping the core size nice and trim. 

The downside is that there's a little more for new users to figure out (downloading a profile), so in the next week or so I'm planning to update the installer to hopefully lessen that issue and maybe even build in the ability for the installer to download and install site profiles from the modules directory. That comes with its own security considerations, so I'm not yet sure we'll go that far just yet, but it's one of a few options I'm looking at. Thanks for reading and have a great weekend! 

[wbmnfktr]

29 minutes ago, ryan said:

This week ProcessWire has gone on a diet. I've been working on reducing the size of the core by moving all (except site-blank) installation profiles out of the core and into their own repositories. This cuts the size of the core in half, going from 15.5 MB down to 7.5 MB, which is quite a slim down! 

Can't really explain why* this is such a great addition and change (at least for me) but that's just perfect!

* I could but noone would believe me that there are areas in Germany with super slow internet connections.

29 minutes ago, ryan said:

The site-blank one remains, but I've updated it a bit to make the template files more useful for beginners while still keeping it a blank profile.

I'm super curious what happened to the new site-blank profile as it's almost always my starting point.
Maybe we can even offer localized versions for Germany, Austria, Switzerland (page name settings like ä=ae, ö=oe, ü=ue, language packs pre-installed, and such).

29 minutes ago, ryan said:

Though maybe one day we'll have a site profile that looks good and has good marketing value. But until then I think we gain more by keeping the core size nice and trim.

Let me ask this straight away... do you have something in mind, like the Kubrick demo setup for WordPress back in 2005?
But for ProcessWire? A blog, with categories, pages, simple forms, tags, whatever.
Maybe we as community could work together to build something like that.
As well as in terms of design and even in basic content and best practice examples.
Super minimal without any modules. Everything with just PW-Core functionality.

I'd be on board for this adventure.

29 minutes ago, ryan said:

The downside is that there's a little more for new users to figure out (downloading a profile), so in the next week or so I'm planning to update the installer to hopefully lessen that issue and maybe even build in the ability for the installer to download and install site profiles from the modules directory.

What about offering multiple ZIPs as download options right away. Therefore maybe less hassle during installation - due to slow internet connections for example. On-demand download during a installation might be (at least for me sometimes in my hometown here) quite difficult and another source for "errors" the forum has to explain and clarify.

• starter.zip
• blank.zip
• core.zip
• and so on... 

All of the above are just thoughts... driven by great additions from @ryan.

[Jan Romero]

58 minutes ago, wbmnfktr said:

Maybe we can even offer localized versions for Germany, Austria, Switzerland (page name settings like ä=ae, ö=oe, ü=ue, language packs pre-installed, and such).

Oooh, the page name settings could be a select in the installer if there are enough useful and distinct ones. That would be dope. Definitely a super common need in Germany.

 

@ryan shameless plug, since you’re going to be working on the installer, I opened a small PR inspired by a recent thread for your consideration ?

[Ivan Gretsky]

@ryan, I've got a 'shameless plug' too)) But of a bigger size)))

I've been desiring the CLI PW installer for a while. Maybe now is the right time for this dream to come true? Christmas is coming, you're working on the installer script... ? 

With it we could easily automate the installation with different site profiles.

[Arklogic]

@ryan it came to my mind it would be very useful to create or use already built profiles for frameworks like Foundation or Bootstrap. It could speed up project starts not also for experienced users but also for beginners. Not to mention preconfigured profiles with using Twig or other template engines…

[bernhard]

13 hours ago, wbmnfktr said:

Maybe we can even offer localized versions for Germany, Austria, Switzerland (page name settings like ä=ae, ö=oe, ü=ue, language packs pre-installed, and such).

12 hours ago, Jan Romero said:

Oooh, the page name settings could be a select in the installer if there are enough useful and distinct ones. That would be dope. Definitely a super common need in Germany.

Just wanted to mention that this is a one-liner using RockMigrations:

<?php
$rm = $modules->get('RockMigrations');
$rm->setPagenameReplacements("de");

// or the even newer setDefaults:
$rm->setDefaults([
  'pagenameReplacements' => 'de', // de is default
  // 1 is default and means consistant click behaviour on inputfields
  // see https://github.com/processwire/processwire/pull/169
  'toggleBehavior' => 1,
]);

I'm really not a fan of site profiles, so removing them from the installer is a welcome change for me ? IMHO if we put energy in that direction it would be a lot better to think about better automation than about adding more site profiles... 

This is already possible using RockMigrations (sorry, self-promotion again):

<?php
// site/ready.php
// Demo "Site-Profile" using RockMigrations
$rm = $modules->get('RockMigrations');
$rm->installModule('FieldtypeRepeater');
$rm->installModule('HannaCodeDialog', 'https://github.com/Toutouwai/HannaCodeDialog/archive/master.zip');
$rm->installModule('ImportPagesCSV', 'https://github.com/ryancramerdesign/ImportPagesCSV/zipball/master');
$rm->installModule('InputfieldPageAutocomplete');
$rm->installModule('LazyCron');

// you can also set module config easily
$rm->installModule('TracyDebugger','https://github.com/adrianbj/TracyDebugger/archive/refs/heads/master.zip', [
  'guestForceDevelopmentLocal' => 1,
  'forceEditorLinksToTracy' => 1,
  'editor' => 'vscode://file/%file:%line',
]);

// multilang: translate default language to german
$rm->setTranslationsToLanguage("https://github.com/jmartsch/pw-lang-de/archive/refs/heads/main.zip");
$rm->addLanguage("en", "Englisch"); // add english as second language

I'd love to see RockMigrations (or something similar) in the core one day. It makes developing modules so much easier, more fun and also faster. And of course it helps you in all your CI/CD workflows making your setup more professional, more robust and reusable! It can be used to automate anything you want. Just like shown in the "site-profile" example above. You'll not only have much more freedom about your setup, you'll also get the latest version of all your modules...

PS: Maybe something similar could also be done using composer, but as soon as you want to set module settings and/or create fields/templates etc. composer is out ? 

PPS: My old project PW Kickstart from 2018 could also be used for some inspiration...

[teppo]

 

1 hour ago, bernhard said:

I'd love to see RockMigrations (or something similar) in the core one day. It makes developing modules so much easier, more fun and also faster. And of course it helps you in all your CI/CD workflows making your setup more professional, more robust and reusable! 

Whether it's via RM or some other method, having proper support for handling migrations in the core would be huge ?

One thing I miss from WordPress is the ability to define data structures programmatically. It's nice to be able to store such definitions in Git, share them among developers, modify or roll them back with ease, and then deploy to any number of environments automatically. The contexts are of course different: custom fields and custom post types have no real table structure(s) per se, so certain things are very easy, while others are very hard (or inefficient). Pros and cons ?

1 hour ago, bernhard said:

PS: Maybe something similar could also be done using composer, but as soon as you want to set module settings and/or create fields/templates etc. composer is out ? 

From my point of view RM and Composer both have their use cases, and neither can replace the other. Where RM and Composer overlap is mostly just installing modules and perhaps managing core updates. While one can run all sorts of stuff with scripts or installer modules in Composer, it's not really intended as a tool for creating, implementing, or rolling back migrations.

[pwired]

Quote

This cuts the size of the core in half, going from 15.5 MB down to 7.5 MB, which is quite a slim down!  
This means the site-regular, site-default, site-beginner, site-languages, and site-classic now live in their own dedicated repos on ProcessWire’s GitHub.

How many processwire users find this NOT useful ? Some user base polling or voting would be on its place.

For so many years having these profiles out of the box added to beginners friendly and jump start with processwire.

[AndZyk]

There was a poll in 2017: https://weekly.pw/polls/#which-site-profiles-should-be-bundled-with-processwire

Personally I only use the blank site profile. But for beginners one starter site profile would be necessary. I don't think there is a need for multiple site profiles, but that is just my opinion.

Other CMS offer two separate downloads (one blank and one starter download). This could also be an option.

[teppo]

1 hour ago, AndZyk said:

There was a poll in 2017: https://weekly.pw/polls/#which-site-profiles-should-be-bundled-with-processwire

Personally I only use the blank site profile. But for beginners one starter site profile would be necessary. I don't think there is a need for multiple site profiles, but that is just my opinion.

Other CMS offer two separate downloads (one blank and one starter download). This could also be an option.

Thanks — it's been a few years, but I would expect results to be somewhat in line now. Though we can always run a new poll if that makes sense ?

In my experience...

• experienced users are likely to use the blank profile or have a site profile (or a prebuilt starter site) of their own, while
• new users would find a simple starter site profile — one that looks like a real site but is still unopinionated — valuable.

Quote

An online installer for selecting additional site profiles (22.7%, 41)

Regardless of whether we end up bundling a new "simple" site profile, I think this would be a good idea. Assuming that it can be done in a way that makes it reliable, flexible, and most importantly secure. As Ryan pointed out, installing site profiles from the directory has some interesting security implications: if they can be installed during the normal install flow, any issue with them will directly reflect to ProcessWire itself ?

[LostKobrakai]

On 12/17/2021 at 11:43 PM, ryan said:

… so I'm planning to update the installer to hopefully lessen that issue and maybe even build in the ability for the installer to download and install site profiles from the modules directory. That comes with its own security considerations, so I'm not yet sure we'll go that far just yet, but it's one of a few options I'm looking at.

The core could maintain a list of checksums for its own site profiles, which would restore security to prev. state even with downloads involved. For third party profiles there could be a warning about the tradeoffs involved.

[dotnetic]

On 12/18/2021 at 2:15 PM, bernhard said:

PS: Maybe something similar could also be done using composer, but as soon as you want to set module settings and/or create fields/templates etc. composer is out ? 

 

I think all modules should be installable via composer as it makes everything more maintainable.

There is an composer installer for ProcessWire modules, so you just have to add a composer.json file to your module and the module will be installed in the right directory. Here is a good explanation

One advantage of installing modules via compoeser is, that you can version control your composer.json file or have different modules based on your environment:

[wbmnfktr]

1 hour ago, dotnetic said:

all modules should be installable via composer

As this doesn't interfere with non-composer users... sure. Can make life easier.

Another 2 cents:
All modules (maybe only those with some kind of frontend/GUI) should have specific permissions to allow them to be part in roles in more advanced setups.

[dotnetic]

Here is another advantage of using composer: I am using an automated deployment process for my clients websites via github actions. Right now I have to put all modules in the modules directory under git control and commit every module update to git. This makes every module update another commit in the git log and the git repository very large.

With composer.json I would just update one file and my github action (or buddy, or Vercel or whatever deployment tool you use) would install these dependencies.