Forum Replies Created
-
AuthorPosts
-
September 9, 2019 at 6:25 pm in reply to: 4.6 Update doesn't recognize old Custom CSS Class #1136161
Just a bump.
In addition to our doubling issue referenced in https://kriesi.at/support/topic/4-6-update-doesnt-recognize-old-custom-css-class/page/2/#post-1134611 and https://kriesi.at/support/topic/4-6-update-doesnt-recognize-old-custom-css-class/page/2/#post-1134623, custom css classes are not being shown when applied to post sliders (and possibly other items).
I have attempted:
1. Modifying Line 219 of enfold/config-templatebuilder/avia-shortcodes/codeblock.php and removing “$meta[‘custom_class’]” to be as previous versions of Enfold were. This fixed the doubling of things reflected in the above post.2. Changed Child Theme Options in /wp-admin/ to show custom classes as mentioned in this thread.
3. Added custom enfold\config-templatebuilder\avia-template-builder\php\template-builder.class.php from https://github.com/KriesiMedia/enfold-library/blob/master/temp_fixes/Enfold_4_6/developer-fix/template-builder.class.php
Custom CSS classes are still not applying. For instance, our post slider will have a custom css class called “home-hero-block”, which lives in our child css, but it does not get applied whereas on previous versions of Enfold it does.
September 5, 2019 at 10:27 pm in reply to: 4.6 Update doesn't recognize old Custom CSS Class #1134623This appears to be the offending code to my above issue, notice the difference between Enfold versions:
./enfold/config-templatebuilder/avia-shortcodes/codeblock.php: $output .= '<section class="avia_codeblock_section '.$av_display_classes.' avia_code_block_' . avia_sc_codeblock::$codeblock_id . ' ' . $meta['custom_class'] . '" ' . $markup . $meta['custom_el_id'] . '>'; ./enfold-4.5.7/config-templatebuilder/avia-shortcodes/codeblock.php: $output .= '<section class="avia_codeblock_section '.$av_display_classes.' avia_code_block_' . avia_sc_codeblock::$codeblock_id . '" ' . $markup . '>'; ./enfold-4.5.6/config-templatebuilder/avia-shortcodes/codeblock.php: $output .= '<section class="avia_codeblock_section '.$av_display_classes.' avia_code_block_' . avia_sc_codeblock::$codeblock_id . '" ' . $markup . '>';
The addition of $meta[‘custom_class’] to line 219 causes the doubling.
This is only an FYI — please assist. I don’t want to edit this code since I don’t know the other implications.
- This reply was modified 5 years, 2 months ago by MBARI-WP.
September 5, 2019 at 9:01 pm in reply to: 4.6 Update doesn't recognize old Custom CSS Class #1134611Hello,
We have this issue as well.
On Enfold 4.5.7 custom css classes assigned to code blocks under ‘Developer’ tab work fine.
On Enfold 4.6.1 custom css classes assigned to code blocks under ‘Developer’ tab regardless of if seem to get doubled for some reason.Example 4.5.7
https://staging-www.mbari.org/dist/working-457.pngExample 4.6.1
https://staging-www.mbari.org/dist/notworking-461.pngWe are using a child theme.
This occurs regardless of the settings under child theme > layout builder for Custom CSS classes input field, ID attribute input field, Customize heading style.If I remove the custom CSS, no background appears:
Example, custom-css class removed from code block:
https://staging-www.mbari.org/dist/nocustomcss.pngAny help is appreciated.
An update, I was able to get Enfold 4.4.1 into production and for 10 minutes the site showed 502 errors. After 10 minutes, the site was responsive, but the admin page took 20 more minutes of refresh, waiting for 502, refresh, waiting for 502.
Finally, it appears to be stable. I still have the above questions, it rubs me the wrong way that the theme is so heavy that this was required.
- This reply was modified 6 years, 4 months ago by MBARI-WP.
Thanks Yigit. I’m going to install in our production environment tonight.
Could you please elaborate on the init loop? Is the underlying problem with upgrading a limitation with WPEngine having a timeout value that causes this init loop to fail? What does the init loop do and why does it only have to occur once? If its a script that initializes plugins or something, won’t it have to run every time the httpd/nginx daemon restarts?
Thanks
Additionally, will the modified element-manager.class.php make it into the official releases of enfold? I don’t want to run a fork of a file that has to be replaced manually every update and which will become outdated as the theme evolves.
Thanks.
Hello,
I’ve done the following and after 12 minutes our staging site finally stopped generating 502 errors.
-Uploaded new theme (enfold 4.4.1) dir as enfold-new
-Replaced config-templatebuilder\avia-template-builder\php\element-manager.class.php with the one provided on pastebin
-Cleared server cache files, browser cache
-Renamed enfold to enfold-old, renamed enfold-new to enfold
-Refreshed a few times — after 12 minutes the site is now displaying. It was not displaying in any browser or curl tests for these 12 minutes.Why the long wait? This has been my process up until 4.3. Enfold is now 4.4.1 and the theme always updated instantly up until 4.3 using the above process.
Explain to me why this takes so long now? If this is a one time wait that is acceptable, if I will have to have the 12 minute downtime every time I upgrade the theme going forward that will not be acceptable.
- This reply was modified 6 years, 4 months ago by MBARI-WP.
Has there been any update to this? I’m headed off on vacation until July 9th — hope I’ll have a shiny new behaving Enfold to install when I return.
Hi All,
I had reported in #967952 that I got 4.4.x running in staging by deleting cache files before upgrading on our staging site. I finally had some more time to throw at this and attempted to repeat the process to make sure I understood the steps, before I rolled 4.4.1 out to production.
I’m sad to say I cannot reproduce the successful upgrade of Enfold on staging anymore. With these inconsistent results, which are with or without cache deletion, I will not proceed to putting in production. I’m stuck on 4.2.6 until this is resolved or I migrate from WPEngine.
My gut feeling still tells me that this whole thing is a combination of unclean code of the theme (perhaps, css compression) running up against the execution time limitation imposed by WPEngine — Kriesi and WPEngine really need to work together to identify what the cause of this is.
Hi welswebmaster,
I’ve got 4.4 running on staging by uploading the new theme as enfold-new, deleting the cache files, and renaming the old theme to enfold-old and then renaming the 4.4 theme to enfold.
After refreshing, the site will 502 once or twice (around 2-5 minutes), and then render.
I had followed these steps dozens of times with 4.3 and it always resulted in 502 no matter how many times I refreshed or cleared the cache.
I have not yet tried to do it in production. As a side note, I’ve already got the OK to migrate off of WPEngine as I’ve been able to prove that the theme updates OK on an equal stack on a non-WPEngine host.
Ahh, Doug! Our department supervisor is actually https://bit.ly/2kcGQra, and I’m the primary working on this https://bit.ly/2s0YMc1. Doug may have not seen your email or it could have been caught in spam.
Interesting results with your kill script. Our support engineer said they couldn’t see the requests that were getting killed. I’m interested in the results of your upcoming tests.
Sorry for my ignorance but who is conlin?
Hi welswebmaster and kriesi,
I don’t have good news. It appears the new version of enfold and wpengine are somewhat incompatible. After working multiple times with support one tech has informed me:
Alex G10:49 am \The core files are in place. I didn’t see anything out of the ordinary within your configuration files. I confirmed that the 502s are triggered by the apache kill script. Unfortunately our logs don’t indicate the exact process on the page that is taking too long to execute. And we wouldn’t be able to remove the kill script since it is in place to protect the health of the server.
10:51 am Beyond that I can try increasing the PHP memory limit settings.
The PHP memory increase and setting php max_input_vars to 4000 (max wpengine allows) did nothing. So wpengines kill script (as welswebmaster mentioned above) does not like something about the new enfold, and barring doing some low-level query analysis and/or PHP debugging we can’t say what it is. I can’t devote the time to that, and will most likely have to switch from WPEngine to another provider/selfhost because of this.
They ended with this:
Alex G11:04 am Dang okay. Not sure what else we can do from our end at least. You would have to reach out to the theme developer to see what could be causing this.Hi welswebmaster,
We too are experiencing what appears to be the same behavior and we are also on wpengine. We have spent a lot of time on this as well and wpengine support cannot provide any logs outside of what we can see in the portal. What we have discovered that we can make the site render somewhat if we:
-Upload the new enfold theme as enfold-new
-Rename enfold to enfold-old
-Rename enfold-new to enfold
-Go into our enfold-child/ directory and rename style.css to style.css.badOnly renaming the child style.css seems to allow the site to render. This obviously breaks all visual styling. Would you be willing to try this on your staging environment and report back it?
If your install behaves the same as ours, then I’m leaning towards the built-in CSS compression being the issue. It is enabled by default. I’ve attempted to modify register-admin-options.php and setting what I think is the default to none by:
line 95 “std” => “avia”, changed to “std” => “none”,
line 112 “std” => “avia”, changed to “std” => “none”,
line 145 “std” => “auto”, changed to “std” => “load_all”,But that did not work.. I’m going to revisit this theory tomorrow when I have some time.
If the above rename test doesn’t behave the same as ours, I apologize and won’t hijack your thread any further :),
Regards,
I’m interested in the outcome of this so I’m subscribing to this thread.
We’re in testing stages of upgrading to Enfold 4.3 and immediately after uploading the new theme into our staging environment 502 errors occur. They don’t occur if I remove our child theme, but that breaks everything. All previous upgrades our theme update went through without breaking errors.
Here are two screenshots. There are three blog post elements on the page tagged with different tags (Molecular Ecology, Team, and Technology). When choosing the second page (circled) all three blog post elements switch to a second page, even though there is no second page to switch to for the other two.
First Image
Second Image
- This reply was modified 7 years, 11 months ago by MBARI-WP.
Hi Andy,
I have figured out that it is our child-theme functions.php causing issues with pagination for our instance. However, once removing our child functions.php, there is a second pagination issue that exists only when multiple blog post elements on the same page.
When multiple elements are involved, all 3 elements will switch to the second page when choosing to go to page 2 of a single element. Even if there are not two pages worth of content for the other elements.
To confirm this isn’t a configuration issue with our main website, I did the following:
I setup a test WordPress installation with Enfold and no other plugins or customizations. I created fake content and configured multiple blog post elements on a single page. All 3 blog post elements are switching to page 2 when choosing to go to page two of a single element.
I put a link to the test page in the private content. We can deal with the first bug in the child functions.php, but we do not know what to do about the second bug we discovered.
Joe Gomez
Systems Administrator
MBARIHi Rikard,
Nancy is on vacation so I am taking this over in the mean time.
We did hide some theme elements from the Advanced Layout Editor via CSS in a child functions.php because we have a lot of staff editing pages and wanted to force them to only a few options for consistency sake.
Example:
// This hides elements from the avia shortcode builder
add_action( ‘admin_print_styles’, ‘enfold_customization_admin’ );
function enfold_customization_admin() {
echo ‘<style type = “text/css”>’;
echo ‘a[href=”#avia_sc_animated_numbers”] { display: none; }’;
echo ‘a[href=”#avia_sc_countdown”] { display: none; }’;
echo ‘</style>’;
}I reviewed your test page and it looks like having a single blog post element will let pagination work but on pages with multiple blog post elements pagination will not work. We use multiple blog post elements in many places to bring things like team members and related posts in. Are you guys going to work on that as a bug?
Joe Gomez
Systems Administrator
MBARIExcellent, thank you. See the private info for credentials.
Hi again, Rikard,
We do not open up our site widely as a security precaution. My understanding is that dynamic IP addresses don’t usually change that often, so if you can give us an IP address, we will open up our site to that IP address and it should be fine for the brief duration of troubleshooting.
Does that sound feasible?
Thank you,
NancyHello Rikard,
I will have to look into this further next week because this is a holiday week in the U.S. I will see what we can do on Monday.
Thank you,
NancyHi Elliott,
No, I don’t have two tags, I only have the one tag “science”. However, the “new science” page is tagged with “science” because in other parts of the site I’d want it included among all science content. So when I add a blog post on the “new science” page, and pull in with a custom taxonomy of post tags “science”, that page itself shows up in the blog posts. I hope that makes it clearer.
Unfortunately, our site is behind a firewall while we are in development. I thought this might be a common challenge for developers so there might be a solution available. If you need to get to our site, I’ll have to re-contact you in a couple of weeks when our site is public.
Thanks,
NancyRickard,
Yes, we can continue with the workaround for the time being. Thank you!
Nancy
Hello Rickard,
Sorry, but that isn’t going to work. We would need the actually IP range for the person who is going to log in.
For now, I figured out a workaround, although it seems convoluted. I looked at the page source in the browser, copied the entire “<div class=”avia_textblock article-text”>” with all its contents. Went back into the editor, created a new text block, went into the “text” view and pasted the code I had copied.
Then I was allowed to save, open, edit, save, etc. as expected.
I can live with this for now. I appreciate your offer to help, but until our site is not restricted by IP address, I will probably not be able to give a moderator access unless the moderator can give me an IP address.Thanks again,
NancyWe are setting up a temporary account for you, but we also need the public IP Address range of whoever will be working on the support issue so that we can tell WPEngine to allow it through the nginx IP restrictions. (Our site is restricted by IP address for privacy during development.)
Nancy
Thanks for the reply, but I am on on Enfold 3.3.2 (and WordPress 4.3.1). I deactivated all plugins. No change. When I open the text box to edit the existing content, none of it shows and I only see “Click here to add your own text” as if no content exists.
Nancy
Thanks, my email is in the private portion … thanks!!!
Kevin
Just bumping this issue. Not having a clean 3.0.2 is really holding us back from upgrading (especially now that 3.3 is out).
Thanks,
Kevin
-
AuthorPosts