Default site bundle

[GwendolenLynch]

Please treat this as RFC status until we've all had a chance to chime in.

Problem

• Despite documentation, people are having issues creating bundles

People without much exposure to Composer & PHP generally want to add small additions to the site, when this "looks" too hard, they often make feature requests for things that don't belong in core.

Concept

My proposed, PoC, solution here is the addition of a "site bundle" that people can use to build on, quickly!

e.g.

How do I add something to Twig to upper case the 'b' in Bolt when I forget

Easy, just add a registerTwigFilters method to your Site Bundle. See https://docs.bolt.cm/extensions/basics/twig for details

For those of us that want to customise, and RTFM, we can just delete/rename/modify or just 🐨 until our hearts are content.

Caveat

What to do about archive distributions?

Probably best to make .bolt.yml into .bolt.yml.dist

[bobdenotter]

As discussed on #development, I'm 👍, if we add this to app/nut init.

[CarsonF]

Looks good to me. Other than. .bolt.yml. Since that file is generated anyways, maybe we can add logic there to check if the SiteExtension class exists and add it to the extensions section.

I don't see the need for it to be in nut init.

[GwendolenLynch]

I don't see the need for it to be in nut init.

That one is due to the nature of archive installs, basically that the archive distribution should rename the PHP file to a .dist as archives are not choosy when overwriting, so if you've installed via archive and then updated your bundle's extension loader … it'd kinda be unfriendly to overwrite it … albeit fun 😉

[GwendolenLynch]

maybe we can add logic there to check if the SiteExtension class exists and add it to the extensions section.

Sounds like an idea … for Thursday's task list

[CarsonF]

That one is due to the nature of archive installs, basically that the archive distribution should rename the PHP file to a .dist as archives are not choosy when overwriting, so if you've installed via archive and then updated your bundle's extension loader … it'd kinda be unfriendly to overwrite it … albeit fun 😉

Archive installs run the script handler when they are being created so it will still have that logic.

Either way this boilerplate for new installs, not upgrades.

Sounds like an idea … for Thursday's task list

👍

[GwendolenLynch]

Archive installs run the script handler when they are being created so it will still have that logic.

Either way this boilerplate for new installs, not upgrades.

OK, I am missing the obvious here … potentially.

A new install is a distribution install, there is no differentiation due to the fact it can be either new or an upgrade, it just replaces files. So if you install an archive and it includes /src/Foo.php that will be overwritten when you unpack the next archive, be that upgrade or re-install … if you've updated /src/Foo.php then your changes are lost … or am I missing something?

[CarsonF]

No you're right. It just replaces files, so .dist files are needed.

But as far as nut init goes, if they can run that, then why can't they run composer? (S)FTP installs have no CLI access, right?

[GwendolenLynch]

But as far as nut init goes, if they can run that, then why can't they run composer? (S)FTP installs have no CLI access, right?

Depends. It is about barrier to entry though.

Generally, installs are staged somewhere first. In that case, running Nut is easy … downloading and using Composer ¯_(ツ)_/¯

… this whole concept gives people something to work off of that is already autoloadable, etc, to get up and running.

[bobdenotter]

As discussed: Let's get this in, as it's a big improvement as it stands.