Forum Replies Created
Site still going down a lot and been down for almost an hour now. Please help me!!!
Posting the login details below. I would really appreciate it if you could urgently lend a hand in figuring out the culprit here. It’s a staging site, so no problem if anything goes wrong.
The live site is sooooo slow and unresponsive and crashing atm. It keeps getting worse! :'(
As I said yesterday, I had completely removed the Enfold folder on the FTP, then reuploaded it.
Just now, the site gives a 504 Gateway Time-out, nginx again. Management is really starting to be impatient with the whole situation. I’m running out of ideas here. Is anyone of you able to take a look at it please?
I’ve just exported the slow errors log again and you’ll see some of the results below.
Thanks for the feedback! I usually update files and then upload to overwrite the existing folder on the FTP. Now I have deleted the entire Enfold folder from the FTP and added it again like fresh, as you suggested.
Hopefully this does makes the difference, because the site has been going down so often during the last 2 weeks and I’ve tried lots of things, so I’m running out of ideas. :)
I’ll keep an eye on the status and check the logs tomorrow to see if the slow errors are taken care of.
I’m back. Was testing something on tablet and noticed a drop in performance and rather undesirable results for this blur effect. Is there a way to disable this for mobile devices?
Perfect, this is exactly what I was looking for! Thank you so much!
I’ll try it out on the live site.
EDIT: Tried it, works perfectly! Thanks again for your help.
- This reply was modified 10 months, 4 weeks ago by DavyE.
This is basically what I mean: https://jsfiddle.net/vduucu87/
Blurring the background image (from the Fullscreen Slider) when scrolling. The more you scroll, the more it blurs. It gets sharp again when returning to the top.June 17, 2016 at 11:43 am in reply to: custom.css local caching issue for returning visitors #649725
Sorry for the late answer. I’ll look into your suggested solution when I have some time, but for now I am using a very manual alternative that may be a solution for other people struggling with this:
Through FTP/SFTP connection, I rename the custom.css by, for example, adding the date in the name. Today is June 17, 2016, so the name would be something like “custom20160617.css”.
Then I open functions.php and go to the following line:
wp_register_style( 'avia-custom', $template_url."/css/custom.css", array(), '2', 'all' );
and I change the filename there as well:
wp_register_style( 'avia-custom', $template_url."/css/custom20160617.css", array(), '2', 'all' );
Then I upload both files and all visitor browsers are tricked into thinking the css file is a different file so will download the new version. If suddenly I make a change to the css file again, I change the name of the css file + the link in the functions.php and it’s all good.
Easy, and so far seems to work really well. At first I thought the functions.php file may be cached as well, meaning the change in referring to another css file might not be recognised by browsers, but so far it has work wherever I tested.
Same here, updated my theme and site went blank. Turning on debug mode gave this:
Fatal error: Cannot redeclare av_mailchimp_check() (previously declared in /www/wp-content/themes/enfold/config-templatebuilder/avia-shortcodes/av-helper-mailchimp.php:446) in /www/wp-content/themes/enfold/config-templatebuilder/avia-shortcodes/helper-mailchimp.php on line 446May 13, 2016 at 10:36 am in reply to: custom.css local caching issue for returning visitors #631968
Exactly, that’s what I mean. It’s inefficient to constantly have to make every single change (no matter how small) and copy it to every other language. Time consuming with multiple languages and risk of eventually having different versions between languages.
So the CSS file is still a better option, but back to my original question: Can it be somehow versioned to force browsers to download the most recent CSS changes? Or any other way to keep browser caches more up to date?May 12, 2016 at 2:28 pm in reply to: custom.css local caching issue for returning visitors #631400
When using WPML (yes), each language needs its own theme settings. Is the Quick CSS universal or per language?May 11, 2016 at 9:13 am in reply to: custom.css local caching issue for returning visitors #630531
The plugin I mentioned is this one: https://wordpress.org/plugins/versionthis/
I did not minify any scripts and am not using a child theme. I chose to use custom.css instead of the Quick CSS field of the theme settings because that way I don’t lose anything when I update the theme (back when I started using Enfold I think it reset this field with every update) and I only have to update one file for all languages, instead of per individual language (which was also the case when I first started using Enfold).
Does the Quick CSS field still reset with an Enfold update and is it still per individual language or the same for all?
As the CSS changes quite often, I cannot risk losing all of the CSS because the field has somehow reset. The custom.css file can be easily backup’ed or restored if necessary.May 9, 2016 at 9:26 am in reply to: custom.css local caching issue for returning visitors #629090
Thanks for your feedback.
No, I’m not using CDN or caching plugins. I’ve also tried disabling any caching in my hosting settings and even tried flushing that cache countless times when I did use it. Apparently, the caching of the custom.css is purely local and I cannot find a way to force the browsers to download a new version.
I’ve been looking at PHP codes to automatically version the CSS file whenever I save it so the browser is tricked into thinking it is a different file and therefore guarantee people always see the latest changes, but this usually seems to require some changes to the .htaccess file which my hosting provider no longer allows to be edited (I think).
So I’ve come across a simple plugin “Version This” on the WP Plugin Directory. It hasn’t been updated for a long time and doesn’t seem to have any reviews, but perhaps I should try it out nonetheless? Maybe this could be a solution to the problem?
And once again you have my eternal thanks! :)
This is perfect, thank you very much!!
As you can see from the answer of Rikard, this topic basically stranded. Until enough customers talk about this, I doubt anything will change about the way the Fullscreen Slider is set up.
Instead, I opted for throwing the Fullscreen Slider element out of the window entirely. I’m now using 100% height Content Sections with H1 and H2 text boxes and put the background image on Parallax or Fixed. This can be set up to completely function like a Fullscreen Slider with the only real exception that it does not offer extra slides. So if extra slides are necessary, you’ll either have to live with the fact that they have set it up contrary to SEO-guidelines, or mass up enough people to have Kriesi consider optimising it.
Apologies for the late reply. I will post the link in the Private Content box.
This is basically a problem for all Enfold users as it is how Enfold works.
- 1) The fullscreen slider element must be the first element on the page to work correctly throughout all browsers. As soon as anyone adds a caption title here, it will be an H2.
- 2) Logically, everyone will then add their H1 page title and any other content.
For SEO, the H1 must be the first text element of the page, then H2 and so on. Yet with the above setup, the H2 will always come before any H1, breaking that SEO rule.
I don’t see a workaround. Any ideas how to get it right?
Thanks in advance!November 30, 2015 at 10:18 am in reply to: Fullwidth button inside a widget is no longer fullwidth #544326November 26, 2015 at 4:48 pm in reply to: Fullwidth button inside a widget is no longer fullwidth #543266
True, but I still need to manually add it to every page in every language, which is a total of at least 200 pages. I often use the debug mode for such things, that makes it easier and faster. :)November 26, 2015 at 12:35 pm in reply to: Fullwidth button inside a widget is no longer fullwidth #543048
Thank you for the fast replay, Yigit.
That’s basically what I had tried before, but apparently it doesn’t work if the content section itself is also inside the widget. So I’ll have to edit each page individually to add the content section with an ID assigned, then drag the widget inside it.
But at least that’s a one time action, after that all changes to the widget will update everywhere. Thanks for the help!
Thank you for the feedback, Elliott.
This site in particular does not need any focus on SEO, but as you assume it wouldn’t be easy to implement I’ll just leave it the way it is.
Thanks a lot, Yigit, it works great now!
Only one thing:
I noticed the title tag was still there the first few seconds. In your code I see 3000, so I tried changing it to 1000 and it is better. Of course, there was probably a reason why you set it to 3000? Or is 1000 just as good?
Unfortunately this doesn’t seem to be working. Have added it to the bottom of functions.php, but the title tags still show the street name when hovering over the markers.