Thinking about this more I think it may work better as a custom field type rather than being core to the Photo Gallery. You could specify crops in the Photo Gallery that aren't available in file manager images and we'd have to make new ones on submit. Then it loses the tie to the file manager folder so new things added there wouldn't update in your photo gallery field. In the use case of always pulling photos from a folder in the file manager, I think making a dropdown field type that lets you pick a folder from the file manager would be the way to go. Then on your front end template you could call BigTreeAdmin::getContentsOfResourceFolder to grab the stuff in the folder and draw it.

I'm tracking this issue in GitHub as well in case I can think of a way to do this effectively! https://github.com/bigtreecms/BigTree-CMS/issues/353

Yes, you can do that. What I would do is do a check in your routed template's default.php to see how many additional commands are present. Something like this:

if (count($bigtree["commands"]) == 2) {
   include "sub-item.php";
} else if (count($bigtree["commands"]) == 1) {
   include "item.php";
} else {
    // The landing page is here.
}

Then in sub-item.php you'll want to do a look-up on the top-level item based on the first route in $bigtree["commands"] and look up the sub item based on the second route and make sure that the sub-item is a child of the top-level item (and if it is not, throw a 404).

In item.php you'd just do what you're likely doing now which is just look-up the item by $bigtree["commands"][0].

It's possible your environments before defaulted to having output buffering turned on. Since /custom/inc/required/ is included in bootstrap and output buffering isn't turned on until after bootstrap is executed, any errant new line output from a /custom/inc/required/ file will likely cause sessions to fail to start. Are you using the new database session handler? It's possible that handler is less tolerant and won't silently fail.

I'm going to track this request but I'm not sure the best way to go about it so I'll probably be following up with you when I get a chance to delve in deeper and see if our ideas align!

This looks to be a bug! I'll be sure it gets addressed in the 4.3.2 release which should come out next week.

So if I'm getting  this right, it's best to have a main version and use that to add functions and roll out updates?

Definitely -- otherwise your manifest versions may get out of sync and you'll have a hard time having other installs see it as a new version.

It happens when creating an extension and then download it in Big Tree. It's a zip-package when doing that with only the manifest in it.

Very strange, PclZip should be just zipping up everything in your /extensions/extension-id/ directory. I might have to look into a different zip library if I can replicate this.

The one thing I've ran into in the past is sometimes when I update extensions from multiple installs the version ID gets off so when I push an update it's actually the same (or lower) version than was previously available, causing the extension updates not to show in other installs.

Do you mean from the extension repository? It should be pulling directly from GitHub which we don't have any control over.

Yes, that's the proper URL. I honestly haven't tested it in quite some time as I usually just edit the extension to change the release notes and that forces an update.