Richard Aber

Howdy @joncampbell

When I add a test post into my local dev install, using an ampersand character in the title, I do not experience that behavior. It is stored in both my WP database and in my Algolia index as the & character. When I search for that post on the front end with instantsearch and autocomplete the character displays as an ampersand, not the HTML entity.

Do you know if it is stored as an HTML entity in your WP database?

Howdy @galexstef. As far as I am aware, this plugin does not currently offer any specific SKU support.

@lipaonline according to this FAQ item: “I have more records than I have posts, is that normal?”, yes, it is normal to have more records than posts, due to “post splitting.”
Quoting:

This is intentional and allows you to fully leverage the Algolia engine.
The plugin takes care of the splitting for you and makes sure that your articles are fully indexed independently from their size.

Specifically, the JS error is being thrown by decodeURIComponent(), on line 37, of riddle.tinymce.js, within the replaceEmbeddedToShortCode JS function.

The replaceEmbeddedToShortCode function doesn’t appear to be operating specifically on URI strings that were found/extracted within the content, but on the entire content of the visual editor. I can see this by pausing execution of the function in Chrome’s inspector, and see that the local scope of content being operated on is (for this example):
“<p>Test riddle.tinymce.js handling of % characters</p>”

My assumption, based on my reading of the JS docs for decodeURIComponent, is that when decodeURIComponent encounters a % character, it assumes the % character is the start of a an encoded URI component. However, a standalone % character in the contents of the visual editor should not be interpreted this way.

I can trigger this same error within any JS test console by simply executing :
decodeURIComponent( “<p>Test riddle.tinymce.js handling of % characters</p>” );
returns “Uncaught URIError: URI malformed”

Whereas, executing decodeURIComponent on a specific URI does not throw the error :
decodeURIComponent( “https://example.com/?s=this%20is%20encoded&#8221; );
returns “https://example.com/?s=this is encoded”

It would appear that the replaceEmbeddedToShortCode JS function needs to extract URIs from the content, and pass those specific URI strings to decodeURIComponent, not the entire contents of the visual editor, to avoid triggering a URIError when a standalone % character is present in the content.

This is not visible from the front end of the site, this only affects the admin side of the site when creating or editing a post.

We have ruled out any possible conflict with other plugins, by disabling all other plugins.

We have ruled out any possible conflict with theme code, by using the default TwentySeventeen theme.

We have spun up a new installation, with only WordPress version 4.8.1, TwentySeventeen theme version 1.3, and Riddle plugin version 3.1 active, and the issue still presents itself.

It would appear that something in the Riddle plugin’s JavaScript is parsing the contents of the visual editor, and choking when it encounters a percent character.

The issue also appears to affect the ability to save a draft or update the contents of the visual editor, as other/additional content changes are not always saved once the JS errors have been triggered.

Deleting the percent character appears to resolve the issue, however, this is not optimal, as some content literally requires a % character.

I can email your team, however, any public facing URL I would provide would not “show” the issue since it affects the post edit screen, not the publicly viewable front end of the site.

Hey there @ashleyhancock,

I just ran into the same issue with duplicate posts and the “WooCommerce Gravity Forms Product Add-Ons” plugin and ran across this thread while searching for information.

It appears that the issue is specific to the “WooCommerce Gravity Forms Product Add-Ons” plugin itself, and is not a “Gravity Forms + Custom Post Types” related issue.

Here’s the relevant FAQ from the “WooCommerce Gravity Forms Product Add-Ons” documentation “Why are duplicate entries created?”
https://docs.woocommerce.com/document/woocommerce-gravity-forms-product-addons/#section-8

I have not determined if there is a fix for this, but thought I’d pass the information along in case anyone else runs into this.

1. A plugin would need to be created for WordPress to access the data from the SmartCatalog IQ remote API, if one does not currently exist. The SmartCatalog IQ developer could likely help you with this.

Here is the Plugin Handbook guide to HTTP API :
https://developer.www.ads-software.com/plugins/http-api/
Of particular interest is the “GETting data from an API” section, which provides some basic usage examples.

2. The aforementioned “GETting data from an API” section of the HTTP API article in the Plugin Handbook provides examples of usage like :

$response = wp_remote_get( 'https://api.github.com/users/blobaugh' );
$body = wp_remote_retrieve_body( $response );

If the data in $response is in JSON format, you can simply use json_decode to work with the $response data from there.

You can find a number of tutorials on the web about how to use the HTTP API, including the wp_remote_get helper function. Here is a good series of articles on Tuts+ from noted developer Tom McFarlin, “A Look at the WordPress HTTP API,” which provides examples of both wp_remote_get and wp_remote_post :
https://code.tutsplus.com/series/a-look-at-the-wordpress-http-api–wp-33794

This post appears to be a duplicate of https://www.ads-software.com/support/topic/missing-tables-2

Hello woalmoore,

Have a look at the “supports” arguments for the register_post_type function.

It would appear that your WordPress site still thinks it lives at the old URL, because that’s what is stored in the database.

I can verify that this assumption is likely correct by viewing the markup source at your WordPress site.
I see that CSS, JS, and image assets are attempting to be loaded from the old domain.
I can also see that your WP login form’s action attribute is pointing to the old domain.

Your WordPress database will need to be updated to account for the domain change, replacing the old URL with the new URL.

Occurrences of :
https://bostonheraldnie.com/blog
will need to be replaced with :
https://blog.bostonheraldnie.com/blog

A straight up find and replace throughout a WordPress database has the potential to break serialized data.
So this will need to be done in a manner that is safe for PHP serialized data.
Two tools that could be used to perform this type of find/replace are SearchReplaceDB (a PHP script) and WP-CLI (a command line tool).
Which tool to choose depends on the type of server access available.

As always, back up your database, before performing any potentially destructive database operations.

If you have SFTP access to the server, and are comfortable performing database operations, you could upload SearchReplaceDB to your server and perform the search and replace through your browser. Refer to interconnect/it’s website for usage instructions.

If you have SSH access to the server, and are comfortable with command line tools, you could install WP-CLI to perform the search and replace from the command line. Please refer to WP-CLI’s website for installation instructions and search-replace command documentation.

If you have limited access to the server where the WordPress site resides, or are uncomfortable making potentially destructive database operations on your own, obtain assistance from a developer.

If you need to find a developer for assistance, you could try posting to jobs.wordpress.net. Additionally, there are quite likely WordPress developers in your own community who could provide assistance if needed.

Hello arturro43,

JavaScript isn’t really my area of knowledge.

You might have better luck creating a new support post specifically for your JavaScript question, since it’s off topic from the original question regarding HTTPS.

Hi winnard,

If I understood everything that you stated earlier correctly, then I believe this proof of concept would be something that you could use and adapt to your particular use case.

https://gist.github.com/richaber/8bd66b46e07ffef0635a

The front-page.php template echos get_post_gallery outside of the_content.

The function and filter in functions.php then removes that first gallery shortcode from the_content when the_content is being output in the front-page.php template.

This might not be exactly what you were looking for, but hopefully it gives you some ideas and helps you find what you’re looking for.

Okay, you want to avoid a plugin, and look at how to do it from scratch yourself.

We still have options, so let’s consider an alternative approach.

One potential solution is to check the content of a page/post for the WordPress Gallery Shortcode with the get_post_gallery function. If the shortcode exists in the content, we could output it wherever we want on the template (example for output is included in that same link).

We could then remove the first gallery shortcode from the content itself in a function hooked to the_content filter later.

Hello WilligTh,

The shortcode that you describe above, [ht_gallery], is not the standard, built-in, WordPress Gallery shortcode. That appears to be a shortcode specific to the “Heroic Gallery Manager” plugin. You may wish to look to that plugin’s page to see if they offer documentation about their shortcode implementation, or ask on that plugin’s own support page if you need assistance with it’s specific shortcode implementation and parameters.

Hello zkwc,

I encountered a very similar question earlier, and this may apply to you as well based on your description.

Facebook caches previews of URLs, so it could be that they accessed your URL once, cached what they found, and just haven’t cleared out the old cached preview since.

You can try to force clear an old cached Facebook preview with the Facebook Debugger tool at https://developers.facebook.com/tools/debug/

Enter the URL in question into the text field, then click the “Debug” button.
After the information has been retrieved, press the “Fetch new scrape information” button that now appears below the text field.

See if that clears it up for you.