Forum Replies Created

Viewing 15 replies - 1 through 15 (of 16 total)
  • @hjensen244 we’ve already discussed / solved this in the FB thread, but I’m just reposting the solution here for the benefit of anyone else encountering the issue…

    “A javascript event handler has been added to the site (presumably by the popup plugin) to prevent clicks on the popup section, e.g.:

    jQuery(document).ready(function( $ ) {
    $(document).on('click', '.popup', function(event){
    event.preventDefault();
    });
    });

    This is preventing the buttons from being clickable. In the browser console I can fix this by removing the event handler with:

    jQuery(document).off('click', '.popup');

    So, I think you should be able to fix the issue by adding this into “Divi > Theme Options > Integrations > Add code to the body”:

    jQuery(document).ready(function($) {
    setTimeout(function() {
    $(document).off('click', '.popup');
    }, 0);
    });

    I’m not exactly sure why clicks were being prevented on the popups. I can’t see any negative consequences to removing the handler – everything seems to work correctly without it. But be sure to test that the popups are working to your liking after adding the fix.”

    Plugin Contributor Dan Mossop

    (@danmossop)

    I’m glad I could help, @millermedianow, and thanks for the add! It’s a really cool plugin – hope I can contribute to it some more in the future. Keep at it!

    Plugin Contributor Dan Mossop

    (@danmossop)

    @dragipostolovski If I recall correctly, Protect the Children was marking the protect_children meta key as protected (using the is_protected_meta filter). In Gutenberg, at least, when the meta key is protected operations on it (e.g. edit_post_meta) are disallowed by default. To allow them, you need to provide a callback function in the auth_callback arg, which returns true when the operation is allowed. Protect the Children wasn’t doing this itself, hence my code which does so. It uses the check for the edit_posts capability which, as you say, will succeed when you’re logged in as admin.

    The code doesn’t seem to be necessary in classic (where I’m guessing auth_callback isn’t used – though I haven’t verified this). And it wouldn’t be necessary if the key was not protected, since auth_callback would default to always return true.

    Hope that helps / makes sense.

    • This reply was modified 4 years, 3 months ago by Dan Mossop.
    Plugin Contributor Dan Mossop

    (@danmossop)

    I was able to solve this with Gutenberg still enabled by setting an auth_callback function for the protect_children key like so:

    add_filter('register_meta_args', 'wpo_protect_the_children_enable_show_in_rest', 10, 4);
    
    function wpo_protect_the_children_enable_show_in_rest($args, $defaults, $object_type, $meta_key) {
        if ($meta_key === 'protect_children' && is_array($args)) {
            $args['auth_callback'] = 'wpo_current_user_can_edit_posts';
        }
        return $args;
    }
    
    function wpo_current_user_can_edit_posts() {
        return current_user_can('edit_posts');
    }

    Happy to help, @whitepointernet

    To add to your recommendation to developers, I’ve found two ways to disable the jQuery deferral programmatically in Divi:

    1) Require jQuery as a dependency of your script when you enqueue it – in that case Divi should disable jQuery deferral itself.

    2) Use the following filter:

    add_filter('et_builder_enable_jquery_body', '__return_false');

    If you need to check for the presence of your button in the content to determine whether or not to disable deferral, you can get the page content as the second parameter to the callback, like so:

    add_filter('et_builder_enable_jquery_body', 'wpo_maybe_disable_jquery_deferral', 10, 2); 
    
    function wpo_maybe_disable_jquery_deferral($enabled, $content='') {
        return false !== strpos( $content, 'something-that-matches-your-button' ) ? false : $enabled;
    }
    Thread Starter Dan Mossop

    (@danmossop)

    @card-one-concepts I’m sorry I haven’t been able to respond sooner. I’ve released an update that I think should solve the problems you’ve been having, and have sent you an email with more details. Thanks.

    Plugin Author Dan Mossop

    (@danmossop)

    Hi Shanafourde,

    I’m glad you managed to solve the first problem, but I’m sorry that you had to. The way the main store and department pages are implemented is something I want to address in the next release. I think that they can be handled a lot more elegantly than they are in the current version.

    You’re right, at the moment the plugin tries to create a Store page on activation, and will not do so if such a page already exists. I’ll update the help files to explain this.

    With the department page, the #DEPT# in the title is a placeholder which should automatically be replaced with the name of the department when viewing a particular department’s page – you shouldn’t need to do anything. Note that to see this, you need to go to an actual department page (linked from the main store page), rather than doing “View Page” from the WordPress dashboard.

    The idea is to avoid having to create pages for every department. Again, this is a pretty messy solution that I want to fix in the next release. In the meantime, I’ll update the help files about this too.

    If you’ve gone to an actual department page and still see the placeholder, let me know (and if possible, drop me a link to the store, and I’ll look into it.

    Thanks and all the best,
    Dan

    Plugin Author Dan Mossop

    (@danmossop)

    Plugin Author Dan Mossop

    (@danmossop)

    Hi shanafourde,

    Sorry about that. The warning is harmless (in this case). It occurred because the link starts with https://, which causes your browser to check my site’s SSL certificate. Long story short, I need to pay for my own certificate, rather than using my web host’s default one.

    Anyway, I’ve updated the link on wordpress.com so you won’t get the warning now – it uses plain http:// instead.

    Thanks for bringing it to my attention, and all the best.
    Dan

    Thread Starter Dan Mossop

    (@danmossop)

    I’ve fixed the problem in my own case by setting the rewrite slug on my post to be ‘/’. This means that my custom posts don’t have a slug at all, and now show up at ‘/old-slug’ the same as a regular post. Since the permalink doesn’t change when I switch post types everything works correctly.

    My issue is resolved, so feel free to mark the thread as resolved. But I’ll leave it open in case you want to add any comments for people who need to keep the slug base.

    Thanks,
    Dan

    P.S. I’ve written up some notes on removing the custom post slug for anyone trying to do the same thing.

    Plugin Author Dan Mossop

    (@danmossop)

    Fishpat,

    That’s great news! I’m glad you got it working. Let me know if there is anything else I can help you with.

    All the best with FishingPatagonia.com 🙂

    Cheers,
    Dan

    Plugin Author Dan Mossop

    (@danmossop)

    Hi Concepduo, I’m marking this as resolved, but please don’t hesitate to let me know if there are any further issues.

    Dan

    Plugin Author Dan Mossop

    (@danmossop)

    Hmm…

    Two things. First, check that you don’t have any spaces before or after the API key (the next version will remove them automatically, but the current version doesn’t).

    If that still doesn’t work, you can check your API key with World Weather Online at: http://developer.worldweatheronline.com/io-docs

    From the drop-down box, select “Free Weather API”, then put in your API key. Next, click on the “Get Local Weather” (first option) to expand it. Leave all the values as they are and click “try it”. This submits a request for weather data using your key. It will then show you the result just below. If you see results like “403 Forbidden” and “Developer Inactive”, this indicates that there is a problem with the API key. In that case you may need to register again to get a new API key.

    Sorry, it’s a bit of a hassle with the whole API key thing. I’m looking to move to a key-less setup in the near(ish) future which should avoid all this.

    Dan

    Plugin Author Dan Mossop

    (@danmossop)

    I’ve released the update for the weather widget.

    Here’s what to do:

    1. Log into WordPress and go to Plugins
    2. You should see that an update for the weather widget is available (I think WordPress checks for updates once per hour, so it may not show up immediately)
    3. Install the update, then reload fishingpatagonia.com.
    4. Now go to (or reload) the Widgets page and look at the settings for the weather widget
    5. Fingers crossed, there will be a big red error message at the top of the weather widget’s settings box.
    6. Let me know what the error is (if there is one) and I’ll advise you further.

    By the way, I also updated the widget to use an backup method of requesting the weather data (via curl), so if your server was blocking the original method (via file_get_contents) it may start working now.

    Anyway, let me know how you get on.

    Dan

    Plugin Author Dan Mossop

    (@danmossop)

    Hi fishpat,

    Sorry to hear you’re having problems.

    Basically, there are a few reasons that this could be happening:

    • The API key isn’t working
    • The city value isn’t recognized
    • Your server isn’t allowing the widget to request the weather data
    • The weather server isn’t responding for some reason
    • There’s a bug in my widget
    • Some other mysterious error

    I’m working on an update to the weather widget right now to add error messages – hopefully that will let us see where the problem lies. I’m hoping to have the update ready in an hour or so.

    Quick question: in the widget settings, what value are you using for the city?

    I’ll post an update when the widget update is ready.

    Cheers,
    Dan

Viewing 15 replies - 1 through 15 (of 16 total)