You are not logged in.
Those are thumbnails of the large crop so it won’t ask you to make crops for them, it will automatically create smaller versions that meet the maximum height/width specified from the primary crop.
You could handle it two ways. The first way is just not call BigTreeCMS::handle404 in your issue.php file when you encounter a 404 and instead include your custom 404 page and manually throw a 404 header. You won’t get BigTree’s included logging and redirect behavior with that though. The alternative is to extend the BigTreeCMS class and the handle404 method and have it accept a parameter for a custom path for the 404 file to draw.
Sorry, meant to respond to this earlier. I honestly don't have much advice for upgrading for PHP 5.5 at this point — I'm not sure I even remember the last version of BigTree that supported PHP 5.5! If you're moving to PHP 8 though you will need to be running BigTree 4.5 as that is the first version to support PHP 8.
It's hard to say what the issue is — you're running a very old version of PHP and a very old version of BigTree, both of which have been unsupported for years. You could try manually creating a password hash using PHP's password_hash function and updating the database directly. If that doesn't work it's likely something related to how old your hosting setup is causing login to just fail.
You'll need to add an "#[\AllowDynamicProperties]" attribute to the top of the class to get the deprecated warning to go away. Adding it makes the extension require PHP 8 so it's a bit of a double-edged sword which is why I haven't added it directly yet.
Sorry I meant 2.7.2 — the Form Builder release version that I tagged in the git commit above. It should have auto-released to the BigTree extensions repo.
https://github.com/Fastspot/bigtree-for … 4dc42c01dd
4.7.2 release should fix this issue
It looks like that crash happens if you try to create a form without any fields in PHP 8.2+ — I'll push up a fix for that soon.
Yep! It'll probably be a month or so before that ships though.
You can go to GitHub and hit the 4.5-devel branch here:
https://github.com/bigtreecms/BigTree-C … /4.5-devel
Use the "Code" dropdown and you can download a zip of the repository where you should be able to grab the core directory.
I just pushed up a fix for this to the 4.5-devel branch. It was related to multi-site relative root tokens not translating cleanly against older staticroot content.
Haven't ran into this personally but I'll see if I can replicate it — I don't see any changes in 4.5.3 that would appear to affect using files from the file manager. Have you isolated it to that version bump exactly?
Sorry for not replying earlier -- it's been a crazy month. Hopefully will have this fix in soon as well as the other issues you've reported.
This is upgraded to 1.0.1 now which fixes some warnings and uses full PHP tags.
I'll try to get that updated in the next day or two!
Very strange! Are your local and remote using different versions of PHP?
Sorry for the delayed response here, Google decided that forum notifications were spam again. I'll try to take a look at why it's not working properly on 4.4!
Did you run composer update on the server? You might not have the composer package for the Google Analytics API or your composer.json file might not be the latest one from BigTree 4.5.7.
I try to keep the base methods on BigTreeModule agnostic to what the underlying table might be but I can see the use case. We'd need some way for caching the table structure against the extended class and then the search method could know whether it supports archived/unarchived.
Weird, I'm not able to replicate this. Is there a certain template that it always occurs on? I did push up a fix to 4.5-devel for BigTreeCMS::urlify so that it doesn't crash on a null value though.
Sorry for the delayed response here, for some reason BigTree's forum emails were being sent to spam. I'll try to get a fix out for this ASAP!
Thanks Doon! Nothing deadly, just lots of downed trees.
Adding https:// to the static_root won't help the existing assets (you will want to update them in the database directly — that is the right course of action!) but I believe it should prevent future uploads from getting // by default but I could be wrong. It's been a long time since I last ran into the issue!
Hi Doon!
Sorry for the delayed reply — we had a 3 day power outage up here after storms blew through on Monday. Glad you caught the issue — I think either an earlier version of BigTree was using protocol agnostic file paths or your static_root in the config was using them. If it's the latter you'll want to update that to be https://.
Hi Doon! Sorry for the late reply, I believe this is fixed in 4.5-devel (you'll have to re-save a page with corrupt title data) — there's quite a lot waiting in there for a 4.5.2 release, I should kick that out soon (maybe this weekend).
I'll try to take a look into this issue this weekend!