Michael Beckwith

@nlaahanen Are you able to recreate the issue on a staging site and test/confirm that disabling those gets the errors resolved? So far, it sounds like one of those is likely the source of the issues, but we just need to confirm.

Alternatively are either of them pending updates that could be applied to see if the update perhaps solves the errors as well?

Hmm, yeah, that looks more like general registration information, but not really in a way that we typically output anything as text. For example we don’t have “Post Types Fetched” as a string used in the plugin.

I was thinking more a debug.log file or similar in your wp-content folder, or an error log accessed via your hosting administrator panel for where you host the website.

Not sure what to tell you as the errors in the log above originate from those plugins, it just seems to be happening when trying to edit a content type registered with CPTUI. So something is happening with those more than anything CPTUI is doing.

Understanding that this may be a live site with traffic, but is it possible to disable the Elementor plugins? Or try editing the content types without either of those being used?

Any news or changes here @nlaahanen ?

Any news here @pafinoz ?

We don’t actively/intentionally log anything to a log file, especially in regards to one or many registered content types.

If you’re referring to your error log and it’s got a number of things like warnings/notices that are traced back to Custom Post Type UI and settings, could you paste a sampling of them so that we can see what needs to be done/handled to not clog that log up?

The only widget I see from the showcase that has radio buttons is the numericMenu widget.

Documentation for that one can be found at https://www.algolia.com/doc/api-reference/widgets/numeric-menu/js/

Regarding facets and filtering, that all depends on how you configure your indexes. For example with the attributesForFaceting setting https://www.algolia.com/doc/api-reference/api-parameters/attributesForFaceting/

You can configure those via code if you like, and we can provide examples of how to do that, or you could go to say https://dashboard.algolia.com/apps/MY-APP-ID-HERE/explorer/configuration/wp_searchable_posts/searchable-attributes and configure via Algolia’s dashboard.

@jorgebook1

You should have all of the widget types demo’d at https://www.algolia.com/doc/guides/building-search-ui/widgets/showcase/js/ available to you once you have saved your Search Page settings to use Instantsearch for its searching. However, we don’t have all of those widgets available in the template file that we use with Instantsearch. We keep that a bit minimally scaffolded for some potentially common widgets/facets that would be useful out of box.

You can see the default Instantsearch template at https://github.com/WebDevStudios/wp-search-with-algolia/blob/2.8.1/templates/instantsearch.php and all of Algolia’s documentation should apply here.

Until I’m told otherwise, I have to assume so, or at least we’re not intentionally ignoring/disregarding them. Closest I can think of for potentially integrating with reverse proxying would be the code in https://github.com/WebDevStudios/wp-search-with-algolia/tree/main/includes/factories where we’re doing some of the initial wiring up.

Admittedly I’m not that well versed with regards to reverse proxy thing and in response to that, how/where one could potentially change connection attempts within the plugin’s code here.

This is also why I pointed to the package from Algolia where they’re maintaining a lot of code that we make use of externally, but don’t control internally. The question at that point would be how to best pass in custom values that pass through to that library.

• This reply was modified 4 weeks, 1 day ago by Michael Beckwith.

Understood on that part.

Not managing to have issues, at least with my local install, with Classic Editor either:

So something is definitely going on, but it’s not appearing to be related to the settings that CPTUI is adding/using, but something else in the install.

From what I can see in that log, thank you for that, there’s been some fatal errors from:

• Elementor
• WooCommerce
• WPForms
• All In One SEO pack pro

So there’s definitely something going on overall, but it looks like it’s related to other plugins that just happen to be getting attempted to load on the single post type view in question.

Not something that we can change from our plugin, to be honest.

I can definitely get that filed over on Github, but I also know that we’re still trying to figure out the best way to upgrade users away from Autocomplete version 0.38.x without disturbing too much, as that’s a major upgrade and changes a lot of the automatic integration that we have with the current version.

There’s some code examples over at https://github.com/WebDevStudios/wp-search-with-algolia/issues/398

This example below just modifies the autocomplete.php template directly, which you can see more about at https://github.com/WebDevStudios/wp-search-with-algolia/wiki/Customize-the-Autocomplete-dropdown

source: algoliaHitsSource( client.initIndex( config[ 'index_name' ] ), {
	hitsPerPage: config[ 'max_suggestions' ],
	attributesToSnippet: [
		'content:10'
	],
	highlightPreTag: '__ais-highlight__',
	highlightPostTag: '__/ais-highlight__'
} ),
debounce: 2500,
templates: { ... }

Something like above would delay execution by 2500ms and this 1 line addition would be for around this spot https://github.com/WebDevStudios/wp-search-with-algolia/blob/2.8.1/templates/autocomplete.php#L109-L117 which I pasted some of above.

Not sure what to suggest beyond that. Getting things to as little variables as possible is the idea.

How many plugins are in play here?