-
AuthorPosts
-
October 15, 2018 at 5:55 pm #1021686
Using the new performance/speed option to “load only used elements” throws errors on almost all elements in the first run on the pages
““Special Heading
This element was disabled in your theme settings. You can activate it here:
Performance Settings”it gets solved by using the following tip out of this forum:
https://kriesi.at/support/topic/new-disable-template-builder-elements-function-not-working/#post-957900[…] Please set the builder to debug mode and then edit the pages with the issue. Below the advance layout builder, you should see the Enfold Shortcode Parser option. Set it to the third option (autorepair) and then update the page to regenerate the shortcode tree. […]
However, I have to re-edit any page manually as the problem shows up on all pages. Is there a “bulk” autorepair function? It is very painffull to check all pages manually and apply the fix manually to each page?
Any idea?
October 16, 2018 at 9:35 pm #1022403Hey datapool99,
Can you please update to the Enfold version we released yesterday and let us know if issue is fixed?
Best regards,
BasilisOctober 20, 2018 at 7:10 pm #1024390We have updated to latest version 4.5
The core problem is: After we manually solve the problem by the workaround (debug/autorepair), and now we update a page (doesnt matter which page) and press the “update” button after the edit. The error is back on ALL pages again. So we again see the “This element was disabled in your theme settings. You can activate it here:Performance Settings” on all pages. We have to manually process each single page now again with the workaround to repair.It comes again after each and every page update. This is not usable anymore.
Any idea?
Thanks & Regards,
LarsOctober 22, 2018 at 1:07 pm #1024837Hi,
Thank you for using Enfold and sorry for the problems.
We had this mesage with Cookie Consent Message bar enabled and Special Heading not used in a page/post content. But this is fixed in 4.5.
Did you clear server cache after updating to 4.5?
Normally updating from versions < 4.4 we scan all pages and post content for theme shortcodes and store this info in a post meta we use to disable elements that are not used.
An "auto repair" can be forced by changing the version of the element builder and reloading a backend page:
enfold\config-templatebuilder\avia-template-builder\php\element-manager.class.php line 19:
const VERSION = '1.0.1';
replace by (do not change the first 3 numbers as this might break our internal checking for versions)
const VERSION = '1.0.1.1';
Could you give us a link to your page and admin access to the backend so we can check your settings? You can post it in private content.
Do you use theme shortcodes in sidebar widgets or footer that are not used in pages/posts content ?
Best regards,
GünterOctober 22, 2018 at 4:25 pm #1024949This reply has been marked as private.October 23, 2018 at 1:12 pm #1025388Hi,
Thanks for the login credentials.
There seems to have been a problem in updating our postmeta values/option values for the shortcodes.
You can see this when you open a page for editing you find a button “show parser info” in “Enfold Shortcode Parser” metabox. Clicking this opens a new window with several tabs.
Shortcode Usage overview shows which shortcodes are used (Blog usage) and detailed shortcode usage shows the posts for each shortcode.
As you see in detailed shortcode usage, there is all 0.
I added a Testpage “Test page Enfold” with a 1/1 column and saved it. Click button “show parser info” and in the new window you see that this column is shown correctly in the overview. But writing this and rechecking (click button “show parser info” without doing anything on the testpage) a little later it was reset to 0.
I added a second column – updated the testpage and clicked “show parser info”. it was correctly showing 1 for each column – and after a few minutes I clicked “show parser info” – everything 0 again.
There must be something on your install that resets the entries we make to the options table for each shortcode. These all start with “av_alb_usage_”.
Selecting “Alway load all elements” will fix this problem.
To find out which plugin causes the problem (probably a caching plugin) you would have to deactivate all plugins first.
Then as described above modify the version number (1.0.1.1, 1.0.1.2, 1.0.1.3, ……),– reload a backend page (forces the update), open a page, click “show parser info” and check. Modify page by adding a shortcode and check again.
– activate one plugin after the other, increment the version number and check with the above procedure.Best regards,
GünterOctober 24, 2018 at 8:33 pm #1026097Dear Günter,
thanks for your detailed investigations. I did the painfull route to deactivate each plugin one by one and check…
The surprising result is that the effect/error is back when the bbpress plugin is activated again. I would have never looked in that direction. I have now kept the bbpress disabled, but as our page has a long form discussion panel, it is no real option to keep it off.
I dont know what caused the trouble with bbpress activated – we have the latest version of the plugin.
Do you have any idea why this is caused by bbpress plugin once activated?
Thanks & Regards,
LarsOctober 29, 2018 at 12:47 pm #1027490Hi Lars,
Sorry for the late reply and your feedback.
Strange – I have bbPress and WooCommerce running on my dev server and do not have the problem.
Did you try it with bbPress alone? I think it must be a combination of bbPress with another plugin – might be a caching plugin.
Can you check the php error log? You might need to set WP debug mode in wp-config.php (https://codex.wordpress.org/Debugging_in_WordPress).
Best regards,
GünterNovember 12, 2018 at 11:12 am #1032540no idea. Really strange. I need to turn down bbpress plugin before updating a page/post. Not good. No idea. I will check the debug logs next and post here…
November 12, 2018 at 11:26 am #1032545Nothing in the debug log which might be useful, just these two lines after adding a new post and seeing the same strange behavior afterwards:
[12-Nov-2018 09:23:54 UTC] PHP Notice: Accessing static property WPOCore_Settings::$options_page_hook as non static in /homepages/37/d520648177/htdocs/whentotrade/wordpress/wp-content/plugins/wpovernight-sidekick/includes/wpo-core-settings.php on line 262 [12-Nov-2018 09:23:54 UTC] PHP Notice: Accessing static property WPOCore_Settings::$options_page_hook as non static in /homepages/37/d520648177/htdocs/whentotrade/wordpress/wp-content/plugins/wpovernight-sidekick/wpovernight-sidekick.php on line 7
And after updating the pages to look correct, I see one additional line in the debug.log:
[12-Nov-2018 09:29:18 UTC] PHP Notice: Undefined offset: 0 in /homepages/37/d520648177/htdocs/whentotrade/wordpress/wp-content/themes/enfold/config-templatebuilder/avia-shortcodes/codeblock.php on line 250
What to check next?
- This reply was modified 6 years, 1 month ago by datapool99.
November 13, 2018 at 12:50 pm #1032979 -
AuthorPosts
- You must be logged in to reply to this topic.