Curtiss Grymala

Unfortunately, the only way I can think of to really accomplish that is to strip the HTML from the excerpt/content (using the strip_html attribute within the shortcode).

Sorry for taking so long to respond.

It is not easily doable with the current version of the plugin, but I am working on a new version of the plugin that should allow you to filter the post list according to taxonomy.

Your add_filter() call isn’t telling WordPress to send more than 1 parameter to your function. It should look like:

add_filter( 'post-content-shortcodes-content', 'wrap_post_content', 10, 2 );

The 10 sets the priority at which the filter should be run (10 is the default), and the 2 tells WordPress that it should send 2 parameters to your callback function.

Without that 2 in the apply_filters() call, WordPress is only sending the $html parameter.

You do have the plugin network-activated, right? Can you by any chance provide a link to the site(s) where you’re experiencing the issues? Thanks.

I believe, if you set the strip_html attribute to 1 ([post-list show_excerpt=1 read_more=1 strip_html=1]), that might accomplish this. However, without stripping the HTML from the excerpt, it’s really difficult to accomplish this, unfortunately.

Just as a follow-up, it looks like these changes would also be useful within the following functions in content-audit-report.php, as well.

• content_audit_column_setup()
• content_audit_columns()
• content_audit_front_end_display()
• content_audit_front_end_css()

If it’s helpful, I’m happy to put together an SVN patch or a Git pull request (if you have this plugin in a Git repo anywhere) for these changes. Thanks.

Sorry for taking so long to get back to you.

Thank you for the in-depth and well-reasoned response. I understand the issues you mentioned, and look forward to digging through things now that you’ve rewritten the plugin. Thanks, again.

Thanks. I will work on implementing these changes over the next few days. I appreciate the report.

In the settings, make sure that the repo name doesn’t include the .git at the end. That caused me the same problems you seem to have experienced.

In other words, make sure the repo name is set to cirosirignano/mychefathome rather than cirosirignano/mychefathome.git

If you are using an accordion-style widget, yes. If you’re using a tabbed widget, no.

With the accordion-style widget, you simply need to check “Allow entire accordion to be collapsed” and “Start with the entire accordion collapsed (only applicable if the above option is checked)” in the widget settings.

You can see an example of this functionality in the sidebar at https://plugins.ten-321.com/.

If you’re not seeing this functionality actually work, please provide a link to your site, and I’ll take a look to see if I can figure out what’s going on. Thanks.

Do you have a link to the page where these issues are occurring? Thanks.

Ultimately, after a lot of testing, it seems like it has something to do with me trying to instantiate an object as soon as my plugin is loaded, rather than hooking into an action to instantiate the object.

I even tried having the __construct() method in my plugin’s class return void before doing anything at all (so, basically, all I was doing was instantiating a stdClass with a few properties, but no methods, and no hooks), and it still caused the same issue. I have no idea what ultimately caused the problem, though.

Regarding the dialog itself, it was the dialog box you normally see when someone else is editing a page. However, instead of having text in it that indicated that (it had all of the appropriate spans, etc. inside of it, but they were all empty), it just had the button that returned me to the list of posts (in this case, the list of Accessibility Reports).

Here’s the plugin that caused the conflict, if you think you might see anything that would have caused the issue. Like I said, even if I made the class completely empty except for the variables, it still caused the problem.

https://github.com/UMWEDU/online-tools/commit/021deb88ca9bc3b0f91d80a4e6d1cbe9a3b8413c

Looks like there is a plugin conflict. I’m working on hunting down the root cause, but it doesn’t look like it’s actually an issue with your plugin. Thanks for the help.

This plugin calls the version of jQueryUI that’s registered within WordPress. It then attempts to figure out which version that is, and pull in the appropriate version of the jQueryUI theme to go with that. It hasn’t referenced v1.8 of jQueryUI since before v0.5 of the plugin.

If you’re seeing v1.8.16 of jQueryUI being used (whether that’s the stylesheet or the JS itself), it’s because something else on your site is registering/enqueuing them.

I can’t be certain whether the old version of jQueryUI is coming from another plugin you have on your site, or if it’s something that your theme is doing, but, assuming you’re running WP 4.3 and you’re running v0.5.3 of the Collapsible Widget plugin, I can assure you that the plugin itself isn’t the problem.

Thanks. Sorry about all of the inconveniences.