You are not logged in.
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.
I'd recommend upgrading to 4.4.10 — if the error persists let me know what line number it comes from in 4.4.10 and I'll see if we can fix the bug!
Debug off is definitely the right solution for turning off front end errors in production but it's not ideal in development as you might miss bugs with it off.
What version of BigTree are you currently on? You shouldn't get any visible errors with the default E_ERROR | E_WARNING level. There are definitely abundant notices in the admin in BigTree 4 but we're looking to rectify that in BigTree 5.
What type of environment is it failing on? You mention it works in production on Linux — are you running a development machine on Windows?
The search method on a module class accepts the search term as the first parameter (in your case it looks like $search_item contains that data). You don't need to pass in a full SQL query.
$products=$productsMod->search($search_item);Does your web server show anything in the error logs? Do you see anything when you view source?
Hi Tushar,
Can you send me an example of a row from the btx_form_builder_entries table that doesn't play nicely with the strtr version of replaceRelativeRoots? You can email me it directly.
Thanks!
You're likely fine with leaving in the override for BigTreeModule since that class is strictly used for front end logic display which shouldn't change at all.