You are not logged in.
You would need to check the audit trail to determine the ID of the page that was deleted and then copy that row out of the bigtree_pages table in a database backup back to the live database.
Hello,
I'd recommend updating all the way to the latest 4.4 release. If you're using a git repository for BigTree, you can just do a git pull on it and then visit the admin area to have it run the database updates. If you're not using a git-based setup for BigTree, you can visit the Developer tab and initiate an update. If that does not work due to filesystem permissions, you can download the latest release of BigTree and replace your /core/ and /vendor/ folders with those in the latest zip file.
Whichever way you choose to go, it's always recommended you backup your database before doing a major update.
The trouble with WebP support is that delivering WebP relies on user agent sniffing if you still want to support IE11 and older versions of macOS. Only the most recent macOS supports Safari w/ WebP, unfortunately. For that reason, it's not baked into BigTree at the moment as it's best left up to CDNs to process automatically and serve next-gen formats.
If you were interested in doing strictly WebP delivery anyway, I'd create an override of the BigTreeStorage class (making a copy in /custom/inc/bigtree/apis/storage.php). There's a "convertJPEG" method that is called on all image uploads that you can change to always convert images to WebP instead of JPEG. You'll just want to remove the config and image type checks and then use imagewebp (and switch the extension to .webp).
I haven't tested this, but here's a quick method body change:
// Try to figure out what this file is
list($iwidth,$iheight,$itype,$iattr) = @getimagesize($file);
if ($itype == IMAGETYPE_PNG || $itype == IMAGETYPE_JPEG) {
// See if this PNG has any alpha channels, if it does we're not doing a conversion.
$alpha = ($itype == IMAGETYPE_PNG) ? ord(@file_get_contents($file,null,null,25,1)) : null;
if ($alpha != 4 && $alpha != 6) {
// Convert the image to WebP
if ($itype == IMAGETYPE_PNG) {
$source = imagecreatefrompng($file);
} else if ($itype == IMAGETYPE_JPEG) {
$source = imagecreatefromjpeg($file);
}
imagewebp($source,$file,$bigtree["config"]["image_quality"]);
imagedestroy($source);
$extension = pathinfo($name, PATHINFO_EXTENSION);
$name = substr($name, 0, -1 * strlen($extension))."webp";
}
}
return $name;Hello,
Sorry for the delayed reply -- forum posts were heading to my spam folder for some reason.
The date format is stored in /custom/settings.php :
// Date settings
$bigtree["config"]["date_format"] = "m/d/Y"; // Format for default values for date pickers, see http://php.net/manual/en/function.date.phpHello,
Sorry for the delayed response. You can learn more about creating templates and callouts here:
https://www.bigtreecms.org/developers/d … templates/
I think there may have been an issue that was patched recently related to saving of Cloud Storage settings. I'd try updating to 4.4.14 and see if it works then.
I believe BigTree 4.4.13 released a fix for that issue. The root cause of it was that the URL where BigTree was downloading the certificate bundle from changed -- it was providing a 301 response but the cURL request wasn't following the redirect to the new URL. That led to all future cURL requests failing after the bundle was corrupted.
I would try truncating the bigtree_module_view_cache table -- it sounds like the cache is stale for some reason and isn't bringing in everything from the underlying data tables.
I'm guessing Google has deprecated the use of the very antiquated way we used to pull Analytics data without requiring OAuth / application creation on the client side. I just tested this out on a BigTree install and they're now hiding the option to continue behind clicking "Advanced" and then "Go to BigTree (unsafe)". It does look like if you proceed through those steps that the actual data connection still works though!
Sorry for the incredibly long delay responding to this -- I've been swamped!
The removal of IP logging from the table was actually a bug. For some reason one of the revisions dropped the hash and ip columns from the table. I just pushed up 2.5.4 which should re-add them to the btx_form_builder_entries table.
Yes, see the documentation here:
So sorry for the late reply here -- I was away for the holidays! The default active view is always the one at the empty route. Re-ordering the actions doesn't change what the default one is -- you'd need to manually adjust the routes so that one is empty and another is not.
Sorry for the delay in responding here -- hopefully we'll get out a 4.4.12 release with that fix in soon!
If you're seeing absolute URLs in the broken_url column it's likely due to people putting in likes like http://www.whatever.dom/http:/another.url -- they should be stored as just whatever comes after your www_root.
External links in redirect_url are valid -- e.g. redirecting a broken link to an S3 uploaded PDF is a common use case.
You can definitely wipe out anything that doesn't have a redirect_url if you don't care about the statistics of knowing what 404s have been hit the most. Newer versions of BigTree actually have a button to do that clearing for you -- not sure which version that was introduced in!
If the URL you're getting to from your search form isn't including the GET variables you're either using a POST form or there's some other issue with your form.
You should be able to reference $_GET and $_POST in your template files just as you would in any PHP script.
Do you have a custom admin class override?
I believe 4.4 requires PHP 5.6 or higher.
Does the bigtree_open_graph table exist in your database? If not, you may need to run the database updates. The latest 4.4.10 release should run them all for you if you hit the Developer tab as a developer level user.
If <head> is empty it sounds like you may have some kind of custom override inside your /custom/ folder that is causing issues.
If the CSS is only failing to load when editing a page it sounds more likely that one of your fields is throwing an error and stopping the page from rendering. When you view the source does it get all the way to the closing </html> tag on that page?
BigTree 4.3+ should have a "composer.json" file at the root that contains the packages to install. If the only thing you're seeing broken is the WYSIWYG editor in the back-end then it's likely that your TinyMCE javascript cache is stale.
Composer is a dependency manager for PHP:
https://getcomposer.org/
BigTree SHOULD include the correct /vendor/ folder at the root by default, but if for some reason it is not, you can run "composer update" from the root of your site after installing composer and it will update the dependencies for you.
Two things might be causing this:
- You may need to clear your cache to get the latest Javascript and CSS for the admin.
- You may need to do a composer update (BigTree 4.3+ use composer packages)
That said, you may want to upgrade directly to 4.4.10 as the 4.3 branch is no longer maintained.
Yes, BigTree has a Salesforce API connector but you'll need a developer to implement the connection between your BigTree data and Salesforce objects.