Viewing 15 replies - 1 through 15 (of 29 total)
  • Plugin Author Johan van der Wijk

    (@vanderwijk)

    Hi Cassie,

    I have tested the plugin in both WordPress 3.7.1 and 3.8 beta 1 but I cannot replicate the issue. It is working fine for me.

    I saw in this topic that you made a modification to the plugin file which might be the cause of the issue. Could you please check if using the unmodified plugin helps?

    I’m seeing this as well on 3.7.1.

    I’m guessing it might be a plugin conflict of some sort, but have not yet been able to track it down.

    Thread Starter Cassie

    (@cassiedong)

    Hi Johan,

    Thanks for your reply. Thanks mpmchugh as well, glad to know it’s not just me. In that case it would be a conflict with one of the plugins or the theme. I might do some troubleshooting and see if I can track down which plugin it is.

    I’m thinking about implementing that modification, but haven’t done it just yet. I would like to see that feature being built into the plugin hence the comment (never a big fan of modifying the core).

    Thanks!

    Plugin Author Johan van der Wijk

    (@vanderwijk)

    Hi Cassie,

    Are you still experiencing this issue?

    I’m still seeing this issue. I suspect it’s a Javascript bug or conflict, as it’s not realizing the Content Block is selected.

    [ Here’s a screenshot. ]

    I’m experiencing the same issue! No modifications to the plugin itself.

    Plugin Author Johan van der Wijk

    (@vanderwijk)

    I am sorry that you are also experiencing this issue. Because I cannot replicate it myself (used IE11 and Firefox 26) there is not much I can do about it.

    It is most likely a javaScript issue but without any debug information I cannot be sure about this.

    Here are some suggestions for troubleshooting this issue:
    – Try a different web-browser
    – If the issue occurs in all browsers; install a debug tool such as the Web Developer toolbar for Mozilla Firefox to check if you get any javaScript errors
    – Try disabling all other plugins and switch back to the default Twenty Thirteen theme. Then check if the issue is solved and if so; enable the used theme and disabled plugins one-by-one each time checking the issue returns.

    If the above does not help it could also be that some kind of Internet Security software such as McAfee is blocking the javaScript.

    For me, it seems to be a conflict with “Advanced Custom Fields“.

    When I disabled ACF it in our test environment the overlay for placing Content Blocks worked again.

    Perhaps you can contact them and see about resolving, if you can’t yourself once you install it and test it with. I’ve notified the ACF authors as well.

    I know this was addressed in another thread, but even if you don’t amend your plugin to place them by slug, it’d be nice for the overlay to drop the Content Block’s name in the short code even as a label, so we can see what it is once it’s placed. It’s very confusing without some sort of name present, especially when you have multiples on the same page.

    Something like this perhaps: [content_block id=3329 title=’Form – Jobs’]

    Thanks,
    Michael

    Plugin Author Johan van der Wijk

    (@vanderwijk)

    Thank you for letting me know about this plugin conflict! I have installed ACF on my test install and have been able to reproduce the problem.

    Unfortunately I haven’t found the bug yet but I am hopeful that I will be able to solve this issue soon.

    Adding the title to the shortcode seems like a good compromise, thanks for the suggestion!

    Hi Johan –

    I’m having a similar issue, and I think it occurs when there are multiple WYSIWYG fields on the Edit screen. This is a pretty common situation when using any kind of advanced TinyMCE editor, or custom post type fields that use the WYSIWYG control.

    I think the issue occurs because every WYSIWYG instance causes a new dropdown to be created, but they all use the same DOM ID (“add-content-block-id”).

    So when the jQ hook looks to see which content block was selected, it only finds the first instance of “#add-content-block-id” (the Post Content field) and returns false.

    If possible, could you tweak that jQ to produce a <select> element with a class (instead of ID) and then use the $.each() function to support the Content Block insertion from one of many WYSIWYG blocks?

    That way, everything should play nicely when multiple editors are present.

    Keep up the great work!

    -Goz

    Plugin Author Johan van der Wijk

    (@vanderwijk)

    Hi all, I think I have fixed this now. Could you please download and install this beta version: https://downloads.www.ads-software.com/plugin/custom-post-widget.2.4.5.zip

    Please let me know if this has solved the issue so I can release it asap ??

    Hi Johan –

    I downloaded and tested your 2.4.5 version with multiple TinyMCEs present and it works GREAT!

    Fantastic response time and fix mate – looking fwd to it getting rolled to WP repo.

    Cheers!

    Plugin Author Johan van der Wijk

    (@vanderwijk)

    Thanks Sith, that is excellent news!

    It would be great if the original reporter of the issue, cassiedong and the others in this thread like mpmchugh and psteinweber could also check if their issue has been solved.

    Could you please test this new version I made for you and let me know the outcome?

    https://downloads.www.ads-software.com/plugin/custom-post-widget.2.4.5.zip

    Just saw this. I’ve installed and confirmed in our staging environment that the issue with ACF is resolved in the 2.4.5 version.

    Oh, also glad you like the idea of adding the title to the short code. Greatly looking forward to that, as it will make using the plugin a lot easier!

    Thanks!

    Plugin Author Johan van der Wijk

    (@vanderwijk)

    Ok, I have now released V2.4.5 to fix this issue.

    Let’s hope this change has not introduced any new conflicts with other plugins ??

Viewing 15 replies - 1 through 15 (of 29 total)
  • The topic ‘Can't use the button to insert Content Blocks’ is closed to new replies.