[wpsolr]

6 years, 6 months ago in reply to: Custom post status problem #19154

Did you select “Index all status” on your custom post in screen 2.2?

[wpsolr]

6 years, 6 months ago in reply to: Support for all WP query’s #19135

Please create several new topic for your questions.

[wpsolr]

6 years, 6 months ago in reply to: How to check #19134

WPSOLR is replacing archives, and only archives. If your search built its own search (search url is not like ?s=), then WPSOLR is not activated.

[wpsolr]

6 years, 6 months ago in reply to: Algolia’s sort of numeric facet by alphabetical order is wrong #19128

Here is the fix:
https://www.dropbox.com/s/wl8ugtak0uvud3p/wpsolr-pro-fix-algolia-numeric-alpha-sort.zip?dl=0

1) Please deactivate the WPSOLR plugin, and remove it. Upload the new version with the fix, and activate it.

2) Please change to type “Integer” for your “Chapter” field in your screen 2.2 and reindex everything, if the type was a string.

The fix is detecting fields indexed with a numeric type in screen 2.2 (“Integer” for “Chapter”) with a facet with alphabetical sort. It then reorders the facet content correctly.

[wpsolr]

6 years, 6 months ago in reply to: Algolia’s sort of numeric facet by alphabetical order is wrong #19124

I’m building a small fix in WPSOLR.

[wpsolr]

6 years, 6 months ago in reply to: Algolia’s sort of numeric facet by alphabetical order is wrong #19122

I could replicate the problem locally. The solution suggested seems to be making the sort in WPSOLR.

[wpsolr]

6 years, 6 months ago in reply to: Algolia’s sort of numeric facet by alphabetical order is wrong #19119

Is the alpha sort is working for numeric facet values only?

[wpsolr]

6 years, 6 months ago in reply to: WordPress database error on step 2.2 #19031

I did again the same steps with Yoast SEO and Yoast SEO Premium. No issues.

[wpsolr]

6 years, 6 months ago in reply to: WordPress database error on step 2.2 #19026

If you can, try to add debug code before the test to see what’s in WPSOLR_Service_Container::getOption()->get_db_current_version() and in $db_version.

[wpsolr]

6 years, 6 months ago in reply to: WordPress database error on step 2.2 #19022

It looks like in your case the line
“if ( WPSOLR_Service_Container::getOption()->get_db_current_version() !== $db_version )”
returns true, while it returns false for me.

If I force it to return true, then I get the same Query monitor as yours when refreshing.

[wpsolr]

6 years, 6 months ago in reply to: WordPress database error on step 2.2 #19020

I made the full same steps, but it worked:

1) delete from wp_options where option_name = ‘wdm_db’;
2) drop table wp_wpsolr_index_history;
3) Refresh screen 2.2 with a taxonomy selected
I can see a DESCRIBE error in Query monitor. Due to the dbDelta probably.
4) describe wp_wpsolr_index_history;
Table is here and correct.
5) Refresh screen 2.2 with a taxonomy selected
No error in Query monitor

[wpsolr]

6 years, 6 months ago in reply to: WordPress database error on step 2.2 #19018

Why is there a “DESCRIBE” query in Query monitor debug logs?

[wpsolr]

6 years, 6 months ago in reply to: WordPress database error on step 2.2 #18899

I get only errors on the second call to dbDelta which tries to alter the table.

Can you:
a) drop the table
b) reload the 2.2 page to make the first call to dbDelta
c) DESCRIBE the table, and also capture the Query Monitor errors

[wpsolr]

6 years, 6 months ago in reply to: WordPress database error on step 2.2 #18890

Can you also copy here the full content of the SQL monitor errors?

[wpsolr]

6 years, 6 months ago in reply to: WordPress database error on step 2.2 #18889

This is correct.

Please give me your current table structure in MySQL:
DESCRIBE wp_wpsolr_index_history;