Forum Replies Created

Viewing 30 posts - 1 through 30 (of 267 total)
  • Author
  • in reply to: Fullscreen slider blur on scroll #692597

    Supertastic and big thanks once more! :)

    in reply to: Fullscreen slider blur on scroll #692539

    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?

    in reply to: Fullscreen slider blur on scroll #692523

    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 2 months, 1 week ago by  DavyE.
    in reply to: Fullscreen slider blur on scroll #692304

    Sure, thanks. See the details below.

    in reply to: Fullscreen slider blur on scroll #692294

    Hello Andy,

    This is basically what I mean:

    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.

    in reply to: custom.css local caching issue for returning visitors #649725

    Hey Vinay,

    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.

    in reply to: 500 server error with 'av-helper-mailchimp.php' #644930

    Thanks goldengate415 for the suggestion. I’ll try that later today or tomorrow.

    in reply to: 500 server error with 'av-helper-mailchimp.php' #644921

    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 446

    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?

    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?

    in reply to: custom.css local caching issue for returning visitors #630531

    Hello Ismael,

    The plugin I mentioned is this one:

    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.

    Hi Vinay,

    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?

    in reply to: What I miss: ID names for submenus #625586

    And once again you have my eternal thanks! :)

    This is perfect, thank you very much!!

    in reply to: Show percentage on Progress Bars #609472

    Perfect, this is exactly what I was hoping for!

    Thank you so much, Ismael! :-D

    in reply to: SEO improvement fullscreen slider #598857

    Hello moderngravity,

    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.

    in reply to: SEO improvement fullscreen slider #561864

    Done. Thanks for elaborating.

    in reply to: SEO improvement fullscreen slider #561075

    Well, that is an odd answer.

    in reply to: SEO improvement fullscreen slider #559132

    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. 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. 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!

    in reply to: Fullwidth button inside a widget is no longer fullwidth #544326

    You can say that, yes. :)

    Thanks for your help!

    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. :)

    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!

    in reply to: Header to stay visible while changing pages? #492300

    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.

    in reply to: Google Maps disable Title tags on markers? #428813

    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?

    in reply to: Google Maps disable Title tags on markers? #428796
    This reply has been marked as private.
    in reply to: Google Maps disable Title tags on markers? #428760

    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.

    in reply to: Google Maps disable Title tags on markers? #428231

    Hi Yigit,

    Sure can:

    Thanks in advance!

    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:
    – (currently disabled the page transition and only the preloader still active, which works without issues)
    – (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.

    in reply to: Fullscreen slider dots removed? #422728

    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.

    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.

    in reply to: Fullscreen Slider caption not always appearing #420308

    Hello Andy,

    Thanks for your feedback. I’ll give it some time and see if it is indeed because of the cache. I just tried it does seem to look better.

    v3.1.2? My Safari on Mac says: Version 8.0 (10600.1.25.1)

Viewing 30 posts - 1 through 30 (of 267 total)