Cliff

Thanks @ckadenge,

I ended up testing it out on a staging server with the Storefront theme and all plugins deactivated. It turns out that the culprit was a plugin called Semrush SEO Writing Assistant. I’ve posted the issue on that plugin’s support forum, and will leave it deactivated until there’s a fix.

That said, I do think it would be a nice feature to allow admins to be able to select whether or not they want Tour Kit tooltips to be active on their site or not.

Thanks again for your help!

I’m not sure what’s going on in the et_pb_code, but you have good reason to remove it from the index. After using the relevanssi_page_builder_shortcodes filter to allow all et_pb_code content through, the indexing failed every time.

I’ll go back to the initial plan of using the et_pb_text module for any shortcode content that I need indexed.

Thanks again for your help with this!

Yes, the Divi Code module is et_pb_code. According to the Divi site, the Code module is intended for how I’m using it: “a blank canvas that allows you to add code to your page, such as plugin shortcodes or static HTML” (https://www.elegantthemes.com/documentation/divi/code/)

Functionally it seems very similar to the Gutenberg Custom HTML block. In both cases you can add HTML, shortcodes, and run some simple javascript/jQuery inside of <script> tags.

Does Relevanssi remove the Gutenberg Custom HTML block?

I’ll give the relevanssi_page_builder_shortcodes a try and see if that works.

Cancel this support request. It turns out that Relevanssi isn’t indexing content inside the Divi Code module, which is what I was using to place the Pods shortcodes. So the problem has nothing to do with Pods.

Here’s what the the content looks like at the point of relevanssi_post_content_after_shortcodes:

(I output this to the using the error_log function. I’m redacting some content to keep the project private.)

[22-Jun-2022 05:09:23] WARNING: child 4377 said into stderr: "NOTICE: PHP message:       <p>With a mission to foster.</p>"
[22-Jun-2022 05:09:23] WARNING: child 4377 said into stderr: "<p>Embracing the collaboration. </p>             <h2>Want to Learn more?</h2>      "

There are two Divi Code modules each with a Pods shortcodes between the last </p> and the <h2> which aren’t showing up. But this is where the plot thickens because there’s also a hardcoded <h4> in those code modules which isn’t part of the Pods shortcode and that’s also not showing up.

Here’s what the code inside the Divi Code module looks like:

<h4>
  Committee Chair
</h4>
<div class="people-list">
[pods name="person" where="rel_committee_chair_of.post_title = 'Some Committee'" template="List of People - Committee Chairs"][/pods]
</div>

Seeing that the <h4>Committee Chair</h4> text didn’t show up in the indexing, it looks like the problem is actually with the Divi Code module and not the processing of the Pods shortcodes.

In fact I confirmed this by putting the Pods shortcode inside a Divi Text module, and when I did that, Relevanssi indexed it correctly.

So whatever Divi is doing with their Code module is preventing Relevanssi from seeing content in there. For my purposes, my problem is essentially solved. I don’t need to use the Code module to insert shortcodes; I can just change all of the shortcodes to use a Text module instead. But this is probably something you will want to look into to see if there is a way for Relevanssi to index content inside of the Divi Code module.

Thanks for your help in sorting this out. I wouldn’t have figured it out without the clues from the relevanssi_post_content_after_shortcodes function.

Just an update on this. I suspect that the code probably works in general. It didn’t work for me, but that was my fault.

I’m using the plugin to display a grid of WP Recipe Maker recipes, and although the grid links to posts for the recipes, the grid itself is made up of content from the recipe post type, which doesn’t have a password protection option, so the new code never really had the opportunity to work.

My solution was to create a new keyword in the recipe plugin called “hidden” and apply that to the password protected recipes. Then I used the WPUPG filters to remove any recipe that had the hidden keyword. By doing that, everything worked like I needed it to.

Thanks again for your help!

Thanks Brecht! I’ll try that out later this week and let you know if it works.

The main thing that I’d suggest is to make sure that someone has successfully connected to Aspose API before they try to run their first export. Because of the other reviews, I was very close to uninstalling when that first attempt came back with a 500 server error.

Also, check and see if there is a problem in some server environments that causes the ZIP function to fail. I was using a standard Apache Litespeed server with PHP 7.4. The ZIP PHP extension was installed, but it still didn’t work. Again, I was able to work around this by exporting into a combined Word file, so it didn’t matter in the end, but it’s something you should look into.

Thanks for making a great plugin!

The plugin was just updated 0.10.2 a couple of days ago, but this fix still wasn’t included, so I’ve had to manually apply the fix again.

Can you please give an update on when the fix will be included in the plugin?

Thanks!

For me, the problem was that my client had requested that I use the most recent jQuery instead of what is included in the WordPress core. No special reason to override jQuery — they just wanted the newest. As soon as I reverted to the stock WordPress jQuery version, I was able to use the most recent versions of Divi without any of these problems and haven’t had any problems since.

The one that works for me is 3.19.5

I’m just chiming in here to say that I got the exact same Divi Visual Builder error, but in my case a different plugin was the culprit: WP Ultimate Post Grid Premium.

Divi has a rollback function in Divi > Theme Options > Updates and rolling back to the previous version fixed it for me, at least for now.

Seeing as the latest version is conflicting with more than one plugin, hopefully this is something that Divi can fix in a future release.

Okay, so I ended up disabling filtering by events so I could get my anchor links working again. For a future revision of the plugin you may want to consider an alternative to the window.location.hash to set event filtering. All the same, thanks for making this great plugin available for free!

Sure. The link to the site is memoireracines.org

I like the filter by events, so hopefully we don’t have to turn them off.

Anyway, the anchor links are at in the top menu and they work fine when you’re on the homepage. We wanted to keep as much of the content as possible on the homepage.

Scroll to the bottom and choose one of the secondary pages from the bottom menu. From a secondary page, the links at the top menu are links back to the homepage with an anchor to take you to that part of the page. For example: https://memoireracines.org/#billetterie

When you click that link, keep an eye on the address bar and you’ll see the #billetterie get replaced by #not-set:all and then the page doesn’t go to the anchor.

Okay, thanks for looking into it!