Forum Replies Created
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 3 days, 11 hours 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.April 7, 2015 at 9:25 am in reply to: Page sometimes temporarily stuck when using the new page transition #424529
I have no caching plugin installed, whatsoever. Though the hosting provider is probably using a caching feature (Flywheel). Could that be interfering?
I’ve tried 2 sites and both show the same page transition issue on any type of device using Safari:
– goo.gl/82wbXl (currently disabled the page transition and only the preloader still active, which works without issues)
– goo.gl/UfWnlT (click on the logo top left and then try to go back)
As the page transition for the first site is disabled, the preloader works fine. So it’s probably the transition code having issues with other code? Though like I said, the second site does not run ANY plugins at all (not 1!), so if it is interfering, it’s likely with something in the theme itself. That second site is a clean test site where I have only installed the Enfold theme.
Perhaps it is good to know I’m using a Magic Mouse from Apple and swipe the mouse with my finger to navigate through next or previous pages instead of pressing those buttons in the browser or using keyboard buttons.
I haven’t fixed the caching issue yet because with the recent few theme updates it kept getting removed and forgot to add it in again.
Sorry about that, I must have removed an image while waiting for feedback. I have added a second image to it again.
Yet I see no reason why this would not be visible anymore. I use no plugins, it’s the same on my official site and I have even checked on the Enfold demo site and it’s gone there, too.March 30, 2015 at 3:28 pm in reply to: Page sometimes temporarily stuck when using the new page transition #420509
There is only one more issue that remains, and I see it on multiple website with multiple devices (iPad, iPhone, Mac) in Safari. When I hit the “back” button of the browser, most of the time the preloader does not load the page and it needs a page refresh to load the page properly.