You are not logged in.
Hi Joe! I just noticed in your message that the error is in /templates/routed/btx-form-builder/ — that means it's a custom implementation of the form builder template and not the one that comes included in the extension (which would be in /extensions/com.fastspot.form-builder/templates/routed/btx-form-builder/).
I feel like I kind of remember fixing something similar to this in the main project a while back though — it might be counting errors in the $_SESSION variable when that isn't set yet?
Sorry for the delayed reply - I’ve been out of the states and without internet. I’ll take a look at this tonight or tomorrow and let you know my findings!
This should be fixed in the 4.4-devel branch! Here's the commit if you'd like to monkey-patch it:
https://github.com/bigtreecms/BigTree-C … e063516875
Thanks for the bug report!
Oh, I just misread you! Pending pages data does indeed seem to be failing. I'll look into that now!
I tested this in my local BigTree 4.4.7 instance and didn't run into any trouble saving apostrophes or double quotes into open graph title and description fields. The BigTreeAdmin::handleOpenGraph call is using the default SQL::insert method that auto escapes all the fields so it shouldn't be a SQL injection/encoding issue. I'd put a die(); on line 127 of /core/admin/modules/pages/update.php and
print_r(SQL::$Errors);right before that and see what it's doing.
Since it's complaining about /var/tmp I'm guessing the shared hosting is doing something weird with the temporary upload directory.
I think in larger sites that could get a bit unwieldy as there could be 50 administrator level users all with access to publish a page. Any thoughts on how to visualize that for editor level users?
There's no incompatibility issues with PHP 7.3 — it sounds like the version of PHP 7.3 you're using isn't loading the mysqli module (which is normally built in but int some environments is a separate install).
Hello,
I replied to that email but didn't hear back. Feel free to follow-up to security@bigtreecms.org with any additional details and we'll get the issues patched ASAP.
I responded via email to this already but I figured I'd post here in case anyone else had the same question!
$form (the array) is generated in the Form Builder template's _header.php file.
The way we usually do this is by making the callout target a page which actually hosts the regular form builder template with the desired form selected. Then we have the callout pull the page’s data, find what form it’s using, and then draw that form’s fields. We then have that callout’s action attribute target the /process/ route on the page and let the regular template handle processing, thank you, and error validation. It could be done via AJAX with a lot of effort and kept all inside the callout space but it’s a lot of effort for not much pay-off.
If you view the source code does it show anything? If it shows PHP tags then PHP isn't processing correctly. If they are entirely white it's some kind of server error and benbakelaar is right that you'd need to check the error logs to see what's going on.
You'd need to do some fairly complicated URL route checking in your default.php to have multiple depth levels like that. You'd want to first check the length of $bigtree["commands"] to see if it is 2. If so you'd check $bigtree["commands"][1] for the route of the photo. You'd then look up the category based on that route. Then you'd look up the parent category based on $bigtree["commands"][0] and make sure that the parent category matches the parent category of $bigtree["commands"][1]. If you support depths even deeper than that you'd just want to iterate down the array verify the parent is correct (and exists) and if not you'd call $cms->catch404(); to trigger the 404 page (to prevent random URLs from being indexed by Google).
After all the verification is done, you'd just draw your category page based on whatever the last command is.
Sorry for the delay on responding here -- the forum has been failing to email me properly.
I have this fixed in the development branch if you want to patch in place:
I believe default routing does not use htaccess at all (it is for servers that do not support it). Instead it routes all URLs through /site/index.php/ which is ugly but should be supported at most hosts.
The example site does not use straight CSS files but does dynamic compilation of the LESS files you can see inside of /site/css/. The /custom/settings.php file has an array of files that it compiles when it looks for /site/index.php/css/site.css.
I just did a test install of this and it does look like the demo site is broken in Default routing (but works in the other two modes that use htaccess). I'll see if we can get this fixed in 4.4.7.
Sorry about not replying! Sometimes the forum doesn't send me follow-up emails.
I believe you'll need to get it from $bigtree["commands"] so in your list parser function you'll need to run
global $bigtree;and then $bigtree["commands"][0] will be the ID of the module entry being edited.
I'm not seeing anything in the release notes for 4.2.19 or 4.2.20 that mentions changes to password handling. I'd be happy to see if I can debug on the remote server if you'd like to send me SFTP credentials.
I believe 4.2.24 may use password_hash for password hashing -- if you updated your password locally and have a newer version of PHP locally than you do remote it's possible that the password now in use has a newer hashing algorithm than your remote server has. I'm not sure why resetting your password on the remote server would fail, though.
Are you hitting install.php when trying to install? BigTree doesn’t auto redirect to the installer like WordPress does.
I'd try upgrading to 4.2.24 to see if that resolves the issue. The dropdown doesn't show Site Status, but you can get to it by ignoring the update prompt (it will show at the bottom of the blocks on the Developer landing page).
The fact that you're getting the error when just updating text sounds like there could be an issue with your server accepting $_POST data altogether. When post_max_size is hit, $_POST is usually completely empty which is why we throw that error about the uploads exceeding the size (as that's usually the cause). It's possible that your php.ini isn't being read properly and it's interpretting your post_max_size as something like 160 bytes instead of 160MiB.
Sorry! For some reason I never got the email ping that there was a response to this thread.
1. There is a files tab in admin, new to us. It looks fairly intuitive; however, the "File Browser" that we have and use for attaching images to tours, buildings etc is now empty. How do we reuse our S3 images?
I'm not sure what you mean by this. The default BigTree file browser (for when you hit "Browse..." buttons and in the WYSIWYG) hasn't changed at all other than to remove the button to upload files directly (it now takes you to the files tab). If it's empty there might be a custom override somewhere failing.
2. Google Analytics: we want to disable this in admin. How to do that?
There should be a disconnect button under Dashboard -> Analytics -> Configure.
3. Should custom/json-db/, vendor/, and cron-run.php be put in .gitignore?
Definitely not! /custom/json-db/ is your site's configuration (templates, settings, callouts, modules, extensions, etc) and the main purpose of the 4.4 upgrade! Having that in version control allows you to deploy new templates, callouts, etc without touching the database. cron-run.php doesn't really need to exist if you aren't running nightly cron jobs, but it doesn't hurt to have that in version control either.
4. There are various minor warnings in admin. An example:
I'm not sure where this error stems from -- line 1754 of 4.4.5 is a preg_replace statement and not strtr.
What does your Site Status report as the value for "Allow 4MB Uploads" in Developer -> Site Status?
I believe that error is thrown when your $_POST data exceed's PHP's post_max_size value.
I can't say I've ever seen an include showing up as a commented out statement before. If short tags aren't running properly I would check to see if converting the code to use full opening tags fixes it.
1. Yes, it will begin updating as soon as you hit the developer tab.
2. It doesn't actually modify cloud images, but it does create new thumbnails of them for the new Files tab list view. It works with both cloud based and locally stored files, so having them in S3 shouldn't be a problem.
You can choose to re-crop existing images (if the original file is large enough) by editing a file after adding the new crop. A button should show up allowing you to switch between re-cropping and using existing crops when saving.
Yes, if you update through Developer -> Extensions it should run a diff on the existing tables. The way extension packaging works is that it compares the previous database schema to the current one and creates SQL statements to make up the difference. Those SQL statements are run on update when updating through Developer.