Forum Replies Created

Viewing 30 posts - 1 through 30 (of 150 total)
  • Author
    Posts
  • in reply to: Issue with Booking Calendar after Enfold 5.2 update #1369617

    Hi Yigit,

    Thanks, I will try that and contact the plugin author about it.
    However, regarding this: it seems the issue has resolved “all by itself” after my last tryout, at least it doesn’t happen at the moment. By the way, I also discovered I wrongly informed you earlier about PHP, it’s not 8.1.1 but 8.1.11 (I typed too quickly) :-)

    On mforams2
    – downgraded Enfold to 5.1.2 (ftp copy)
    – disabled CSS & JS merge & compress
    – updated Enfold to 5.2, saved theme options
    – saved permalinks again
    – re-enabled Performance CSS & JS merge & compress, saved theme options

    Much to my own surprise, no more issues. One of those things that has me scratching my head…
    Anyway, both mforams2 and mforams8 now run Enfold 5.2 and Booking Calendar seems to work fine in both languages.
    Perhaps the permalinks saving again did the trick, I don’t know. You can check it for yourself if you want on the two stagings.

    So thanks for your time and effort, I guess this can be closed for now. I will keep an eye on it and in case the problem resurfaces I will open a new one.

    Thanks and have a good day!
    Rob

    in reply to: Issue with Booking Calendar after Enfold 5.2 update #1369602

    Hi Yigit,

    Thanks for taking a loook. However, I don’t understand why the plugin author of Booking Calendar should be involved :-)
    Nor do I understand why deactiviating plugins would help.

    On MforAms8 (Enfold 5.1.2) everything works perfectly in both languages.for the Booking Calendar
    On MforAms2 (upgraded to Enfold 5.2) the default language (EN) Booking Calendar does not load anymore, but it does on the translated page (NL).

    Neither the Booking Calendar nor the Falang translation plugin were touched before the Enfold update, ergo it is something in the Enfold 5.2 update which caused this, I think.

    I would appreciate if you could look for any possible culprit code in the latest Enfold update. I will try my luck with the authors of Booking Calendar and Falang, but I fail to see how they could have caused something which in Enfold 5.1.2 worked just fine.

    Kind regards,
    Rob

    • This reply was modified 2 years, 1 month ago by rob2701. Reason: fixed typo
    in reply to: Portfolio author and portfolio navigation #1348677

    Hi Rikard,

    All solved, can be closed, thanks.

    For anyone else looking to add the author field to portfolio items, here is Ismael’s change:

    // ***** Add filter for author field to portfolio items *****/
    add_filter('avf_portfolio_cpt_args', 'avf_portfolio_add_cpt_args', 1);
    function avf_portfolio_add_cpt_args($args) {
    	$args['supports'][] = 'author';
    	return $args;
    }

    Rob

    • This reply was modified 2 years, 7 months ago by rob2701.
    in reply to: Portfolio author and portfolio navigation #1348668

    Hi Ismael,

    That works perfectly now with your changes, thank you for your time and work! Much appreciated.

    Have a good day,

    Rob

    in reply to: Portfolio author and portfolio navigation #1348479

    Hi Ismael,

    Thanks for your reaction, but I don’t know if that is the issue here. My portfolio items are done with ALB editor, just a single full width column and a masonry gallery below it. The navigation is fine with portfolio items, but disappears when the author code is added. Blog post navigation remains fine, with or without the author field code.

    Dev site access in private so you can see for yourself.

    Kind regards,
    Rob

    • This reply was modified 2 years, 7 months ago by rob2701.
    in reply to: Uploaded fonts not applying after 4.8.9.1 #1339998

    Hi Yigit,

    No worries, things like this remind us of the need for trying updates on dev sites first :-)

    Thanks to the team for the quick reaction and the fixes, much appreciated, as usual.
    I can confirm that the fix solves the problems I noted very well (after saving the theme options again, ofcourse). All good after the replacements.

    Best regards and have a good day!
    Rob

    in reply to: Uploaded fonts not applying after 4.8.9.1 #1339911

    Hi Ismael,

    Again, I disagree: they do not show correctly for me :-)
    You see the difference between the screenprint I provided from the live website with 4.8.9 and the dev website with 4.8.9.1, I hope.

    The result is the same on Linux Mint with various browsers and on iOS with Safari and Firefox.
    Cookies are not relevant here, these are fonts uploeaded to the server. But the cookie acceptance makes no difference.
    The fonts zipped are stripped weights and only Latin characters.

    Fact is: these same fonts zips behave differently with 4.8.9.1 enfold, quicksand-mfora does not show on the headers, and opensans-mfora is fatter (600 instead of 500). No other changes were made, just Enfold updated.

    So instead of going back and forth on this, I have made another dev copy (running on php8 this time), which is not yet updated to 4.8.9.1.
    Then please udate enfold there yourself and notice the difference in aspect.

    Thank you for your time. I wouldn’t insist so much normally, but there really is a difference between 4.8.9 and 4.8.9.1 behaviour here :-)

    Rob

    in reply to: Uploaded fonts not applying after 4.8.9.1 #1339798

    Hi Ismael,

    Nope, the fonts are not applying, neither Quicksand for the Headings nor OpenSans for other text. :-)
    At least not on my Firefox, Opera, Edge, Chrome etc.
    Weird that it does show on your screenprint.

    They are correctly defined in the them options: general styling > fonts tab
    I include the live website link in private so you can see how it looked on 4.8.9
    And links to Google drive for the screenshots (live firefox, dev firefox, dev opera).

    Rob

    Added remark:
    Quicksand has weight 500 only, OpenSans should be 400 (or 700 for bold).
    OpenSans is now fatter and QuickSand does not apply at all with 4.8.9.1

    • This reply was modified 2 years, 9 months ago by rob2701.
    in reply to: Access page in Advanced Layout Editor directly? #1331737

    Hi Yigit,

    No worries, I already suspected the request could have a lot of hidden issues because of all the variables involved :-)
    Thanks for everyone’s time though, maybe someday it will be possible. Can be closed for now, thanks.

    Kind regards,
    Rob

    Hi Guenni,

    Thanks for your help. Yes, that part of the API filter was the problem, as you suspected. Indeed this works fine, like you said:

    function disable_google_map_api($load_google_map_api) {
            $load_google_map_api = false;
            return $load_google_map_api;
    }
    add_filter('avf_load_google_map_api', 'disable_google_map_api', 10, 1);

    Good catch by you, I had not even noticed the filter name change. :-)
    I was baffled because it seemed strange that the filter had been deprecated within a month and without mention in the changelog. Thanks for your sharp eye and help!

    Have a good day,
    Rob

    P.S.
    Solved, can be closed.

    in reply to: Access page in Advanced Layout Editor directly? #1330940

    Hi Nikko,

    Thank you for all the efforts and the time you spent on this, much appreciated. Unfortunately, the behavior is the same:
    even with the code to always open the ALB editor as default, it is still the last used editor & view, all the time. No matter how much we try and test.

    By the way, it is the same on a clean new Enfold site with just a demo imported. Last used editor&view is remembered and opened, that is the standard behaviour, the added code does nothing to change that.

    Testing:
    1. add code to open item in ALB, regardless of previous opening mode
    2. open an item, go to classic & text view, save
    3. try to open item through link.
    4. result: last used/saved view is always used again…

    I do realise I may have opened up a can of worms here, as choosing/setting the default/preferred editor has become much more complicated after WP threw Gutenberg into the mix and all the places this can be set (Settings, user profile, theme). More variables = more problems. ;-)
    Regardless, I would like to repeat my original request and hope the related feature request can be be tackled at some point.

    I do realise everyone has a lot on their plates, but I would just like to know if it’s possible and if so, can it please be added to a future version?

    So in short:
    1. Is there a way to open an item in ALB editor directly through PHP? And/or link?
    2. Feature request: ability to set prefererred editor in Enfold options, would be great if specifically for pages/posts/portfolios/custom

    Thanks for your time & have a good day,
    Rob

    • This reply was modified 2 years, 12 months ago by rob2701. Reason: adding testing steps
    in reply to: Hide Advanced Layout Builder button for blog posts only #1330804

    Hi Rikard,

    Thanks a lot, that works perfectly, just like I wanted. Solved.

    Have a good day,
    Rob

    in reply to: Access page in Advanced Layout Editor directly? #1330558

    Hi Nikko,

    This IS a staging site, a direct copy of the live one :-)
    You can do anything you want there, it’s well backed up. As long as you make sure you re-enable the Password Protected plugin when you’re done (dev site should not be exposed to the public)

    Let me elaborate a bit and save you some time. To see what I mean you can open a page, go to Classic Text View, save it. Next time you open it through a link to edit, it will open in the last used mode, so classic text view.
    I already described that quite clearly earlier.
    Also, it is the same on a standard new site with just the Enfold Shop Demo imported. The LAST USED view is opened when you edit a page again.

    What I need is for the Advanced Layout Editor to open by default / be set as default, that’s all.

    Enfold (as far as I know) does not provide the option to set the preferred editor for pages (and posts if necessary), like some other page builders do. I hereby would make that a real feature request, it would sit nicely in the General Settings, where now you can choose between Block and Classic only.

    I have this set in the child theme functions.php, and that works well enough, but ONLY for NEW pages.

    // ***** TEST #3 trigger ALB editor always on load, regardless of previous saving *****/
    // >>>>> THIS WORKS WELL, BUT ONLY FOR _NEW_ PAGES (HOW TO ADAPT FOR EXISTING?) <<<<<
    // make avia default on new posts
    // use #postdivrich_wrap for editor only, #post-body for (pretty much) everything
    // see https://kriesi.at/support/topic/always-open-advanced-layout-builder/#post-452117
    add_action('admin_head-post-new.php', 'trigger_alb_on_load');
    function trigger_alb_on_load(){
    	echo '<style>#postdivrich_wrap { display: none; }</style>';
    	?>
    	<script>		
    		(function($){
    			$(window).on('load', function () {
    				$("#avia-builder-button").trigger('click');
    				$("#postdivrich_wrap").css('display', 'inherit');
    			});
    		})(jQuery);
    	</script>
    	<?php
    	}
    add_action('admin_head-post-new.php', 'trigger_alb_on_load');

    Kind regards,
    Rob

    See: https://kriesi.at/support/topic/always-open-advanced-layout-builder/#post-452117

    • This reply was modified 3 years ago by rob2701. Reason: Added clarification test imported demo site

    Hi Yigit,

    Thanks for looking into this and finding out the reason. Glad there’s not something wrong.
    Another mystery solved! :)

    Have a good day
    Rob

    in reply to: Two questions about the 2017 demo when imported #1330329

    Hi Yiigit,

    No worries, mine was only a very very very minute contribution compared to the efforts by the support team and devs :-)
    Thanks for a great theme!

    You can close this thread, thanks.

    Rob

    in reply to: Access page in Advanced Layout Editor directly? #1330262

    Hi Nikko,

    WP 5.8.2 and Enfold 4.8.7.1. Yes that works, IF the ALE was active when you started that link.
    But if before the default editor in text view was opened on an item, that is what will open with that link.
    So I need to know the correct way to access the ALE programmatically for it to open straight in ALE only.

    Added clarification:
    The access to ALE via link was just to illustrate the process, I would like to know if it’s possbile to open a page in ALE directly through PHP.

    Access link in private.

    Thanks for the help,
    Rob

    Added info:

    I found this post asking almost the same:
    https://kriesi.at/support/topic/bulk-enable-advanced-layout-builder-on-pages/
    So I added this coe from Mike to functions.php in the child theme (with updated deprecated function of course):

    // ***** TEST trigger ALB editor always on load, regardless of previous saving *****/
    function trigger_alb_on_load(){
    	?>
    	<script>
    	(function($){
    		$(window).on('load', function () {
    			$("#avia-builder-button").trigger('click');
    		});
    	})(jQuery);
    	</script>
    	<?php
    	}
    add_action('admin_head-post-new.php', 'trigger_alb_on_load');

    Bur unfortunately it doesn’t make a difference, it still respects/opens with the editor/view in which the page was last saved.

    • This reply was modified 3 years ago by rob2701.
    in reply to: Way to access Enfold ALB page code progammatically? #1329905

    Hi Ismael,

    Thanks for the info, that was exacly what I was looking for. Great! Solved :-)

    Have a good day,
    Rob

    in reply to: Two questions about the 2017 demo when imported #1329904

    Hi Ismael,

    Thanks for looking into this. No worries about the “slipped my mind”, you guys have a lot of different things on your plate and that’s totally understandable, happens to me as well :-)

    Your css solution works fine, like I mentioned. It becomes necessary mostly when users have their desktop browser window set smaller than max (most notably just before changing to tablet size). The extra social bookmarks or menu items don’t affect it as much.

    The Enfold shop demo needs a small fix as well: “How it all begann – our idea of the perfect clothing store” has two nn’s.

    Thanks for your help and time!
    Rob

    in reply to: Override parent theme file in child theme question #1329633

    Can be closed of course :-)

    in reply to: Override parent theme file in child theme question #1329627

    Hi Ismael,

    Thanks for the prompt info. Pity, means we will have to make do with changing the core parent file directly to test. And redo when there is a theme update.

    Kind regards and have a good day!
    Rob

    in reply to: Two questions about the 2017 demo when imported #1329343

    Hi Ismael,

    Your CSS solution for the submenu item works indeed, with left:0;
    I was too hasty concluding that it wasn’t a good solution, sorry. With that added indeed the submenu remains neatly aligned with the main Portfolio menu link on all viewport sizes before tablet. So my conclusion about the cart/socialbookmarks area included in the calculation was also way off :-)

    With your added CSS, even with cart, 3 social bookmarks and the Falang language switcher, the submenu alignment is fine, neatly below the Portfolio menu link.
    I have left the token active so you can see it on the dev site in action.

    Even though this works, I can’t help but feel that this is a bit of a band-aid, in the sense that anyone with a 2 or 3 column submenu would have to manually apply that to that specific submenu ID.

    Would it be possible to include some logic regarding submenu columns below 4 to have this added automatically? Just a thought.

    Thanks for the help and have a good day,

    Rob

    • This reply was modified 3 years ago by rob2701. Reason: fixed typos
    in reply to: Two questions about the 2017 demo when imported #1329206

    Hi,

    Thanks for taking a look at this. I have temporarily removed the Falang language switcher from the menu, and that doesn’t make that much difference regarding this issue as you can see.

    The issue (with and without Woo activated) is best seen just before the viewport changes to tablet size. The submenu items for Portfolio start somewhere between the main Portfolio and Blog menu links without Woo. With WooCommerce activated the submenu for Portfolio opens between the e and the s of the Pages menu link :-)

    When there are 4 columns in the submenu (like for Pages) things are fine, when here are 2 columns in the Mega submenu it may make access to the submenu difficult, that’s why I ask about this (it’s not just about the demo, it is about this kind of submenu config in general).

    I don’t think adjusting the offset through css is a proper solution, as it would need to be specifically done per viewport for a specific setup and kind of defeats the purpose of the JS calculations?
    Added remark:
    I think the issue is that the calculations are done INCLUDING the cart and the social icons for the menu (maybe better with just the menu links themselves for calculation?) .

    Please check and let me know what you think. I have left WC activated, feel free to change as you see fit. Enfold file merging and compression has been diabled to make checking easier.

    Best regards,
    Rob

    P.S. Can you also have someone fix the “Blak Pages” submenu link in the demo to import? It looks a bit silly :-)

    • This reply was modified 3 years ago by rob2701. Reason: added remark about cart & social icons
    in reply to: Two questions about the 2017 demo when imported #1329181

    Hi Ismael,

    Thanks for the info, that actually helps me to understand better.

    I have discovered that the discrepancy happens when WooCommerce is activated.
    You can find a link to the demo dev site installation in private. Almost nothing changed from standard.
    All plugins disabled (except 2 needed ones for access), submenu Portfolio turns to normal, like in the online demo).
    You can activate only Woo and see what happens to the Portfolio submenu positioning.

    Thanks for your help!

    Rob

    Hi,

    In the meantime we found out why this happened: when the Portfolio Items and the Portfolio Categories are checked in the Translate Options of the Falang plugin (marking them as translateable items). then the issue described above happens. When they go unchecked in the plugin, everything works as it should also with the postname permalinks. Which is why I sometimes had the issue and sometimes not (depending on checkmarks set within the plugin config).

    Faboba (the developer) is already working on a fix to solve this. Once done and checked I will report the results here.

    Thanks for your time and help and for pointing me in the right direction!

    Rob

    Added remark:
    The extensions which were released for Falang are not different versions, they are just enhancements for various theme platforms, to make the translations from within each theme platform’s interface. They are enhancements, not different versions of the main plugin.Just to clarify.

    • This reply was modified 3 years ago by rob2701. Reason: added remark about Falang extensions

    Hi,

    I think I found the reason for the strange behaviour with the submenu links: they start to happen when I add the Falang language switcher to the main menu — and while active the permalink-set-to-postname issue cannot be resolved, no matter how many times you save the permalink settings. Yet with permalinks set to plain everything works fine with the language switcher in place. I will take that up with the developer to see what the reason might be for that.

    But it is still strange that it would only affect the Portfolio submenu items, while all the rest (all other submenus included) continue to work as advertised :-) Anyone have a good explanation for that so I can add that in my mail to the plugin developer?

    If you could keep this open for now, I will report here when the issue has been solved. Thanks again,

    Rob

    Thanks for the tip Mike, I will keep an eye on that too.
    Have a good day,
    Rob

    Hi Mike,

    Thanks for taking a look at this. I will do as you suggested, even though I did it a few times before :-)
    I’m still stumped as to why this happens, I tested 3 more times on local installations, following the same procedure every time, and sometimes the issue happens and sometimes it doesn’t…even on a clean install without plugins.

    Switching between permalink structures sometimes seemed to trigger it, sometimes it was adding something to the menu. Other times doing the same things everything continued to work. Like I said: I’m stumped.
    Of course I always cleared the cache, had Enfold compression disabled, opened in a private window etc.

    I will test some more, and come back here if I find something relevant to mention.

    Thanks for the help so far!
    Rob

    • This reply was modified 3 years ago by rob2701. Reason: added remark in private
    in reply to: 3rd flex column styling issue on tablet sizes #1328568

    Hi Ismael,

    Never mind, it’s a bit counterproductive to look for why what was changed when :-)
    To fix the info page, I will just add the css I mentioned in the initial request. And to fix the 3 col flex on the homepage I will comment out the top-margin 30px which I thought targeted only id-620 but didn’t. Thanks for pointing that out and thanks once again for your help.

    Resolved,

    Have a good evening,
    Rob

    in reply to: 3rd flex column styling issue on tablet sizes #1328545

    Something changed in the last few theme updates, because the Quick CSS worked perfectly before :-)
    I didn’t notice myself, client alerted me.

    The real question is: if I specifically target page id-620 (info page), how would that affect page id-608 (Homepage)? Because it does…
    Remark added later:
    my mistake, the CSS did not target the div:nth-child(5) for page id-620, that was just for the width. Sorry, I misread my own CSS :-)

    What remains is that suddenly I need the changed CSS added to make the change to 2 columns work well on the info page (https://kriesi.at/support/topic/3rd-flex-column-styling-issue-on-tablet-sizes/#post-1328461).
    So what was changed in the parent theme to cause that?

    Thanks for looking into this (again),

    Rob

    • This reply was modified 3 years ago by rob2701. Reason: mistake in link to post
    in reply to: 3rd flex column styling issue on tablet sizes #1328536

    Hi Ismael,

    Thanks for the answer, but that only applies to child 5,6,9 and 10 on the INFO page. In fact when you comment it out, the same issue is there when the 5 columns change to 2 on that media size. :-)

    @media only screen and (max-width: 989px) and (min-width: 768px) {
        #top.page-id-620 #av-layout-grid-1 div .av_one_fourth {
            width: 48%;
        }
      div.flex_column_div:nth-child(5),
      div.flex_column_div:nth-child(6),
      div.flex_column_div:nth-child(9),
      div.flex_column_div:nth-child(10) {
    /*     margin-top: 30px; */
      }
    }

    Also it seems your answer and my added issue comment above happened at the same time, so you probably did not get a chance to read that. The columns also misbehave on the INFO page (5 columns turning to 2).
    On the home page the issue is with 3 flex columns, so they don’t even have a child 5,6,9 and 10.

    Rob

    P.S.
    this is just a staging server, so feel free to try things out.
    Also, the homepage is id 608, the info page is id 620…

    • This reply was modified 3 years ago by rob2701.
Viewing 30 posts - 1 through 30 (of 150 total)