Searching is ignoring the hide_rows parameter.

Hi,

thanks for your question, and sorry for the trouble.

You are right, the hide_rows or show_rows Shortcode parameters are not taken into account when using the WordPress search. The reason for this is that these are only evaluated after the search in the actual tables.
If you want to prevent that such hidden rows are found by the search, you would need to hide them on the “Edit” screen of the table – which is the same as via the hide_rows Shortcode parameter, except that they are not searched then.

Regards,
Tobias

Hello,

Appreciate your reply. My main reason for using the hide_rows is to share specific parts of the table on different pages, rather than dealing with multiple tables.
The “hide” function on the edit screen will make the selected rows hidden no matter what parameters used in the short code!? Am I correct?
Unless there is a fix for the search issue, I’ll have to split the table into parts, and this will make it much more difficult than dealing with a single file to manage.
Thanks again for the great plug-in, really good piece of work.

Hi,

no, the hide function on the “Edit” screen would only hide the rows if there’s no show_rows parameter in the Shortcode to again show them ??
So, basically, you’d just need to “flip” everything (hide all rows instead of showing them on the “Edit” screen) and using show_rows (for the correct rows) to make those visible again.
That way, the hidden rows of the table would not be found by the WordPress search. (Note that hidden rows, no matter in which way there were hidden, will still never be shown. Just the search results might appear “incomplete” to the searching visitor.)

Regards,
Tobias

Hello,

First, I must thank you for the consistent answer. I know that you’re answering these posts on your free time, so appreciate it.

I tried to hide the whole table by checking all the columns and then hide and upon save, it gives the error for the Ajax failure “Saving failed: AJAX call failed: error – . Try again while holding down the “Shift” key.” As instructed I tried the shift key, but that lead to a

“Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.”

The table is about 1420 rows, and I even tried to hide few rows with unique values to test the wordpress search, and it came with the two previous errors as well.

I guess I’ll be forced to split the file?
I believe that splitting the tables will save me all that mess, but it’ll be more work to update in the future.

Thanks again.

Hi,

I’m afraid that this “Saving failed” is a separate issue that is unrelated to the original problem.
My guess is that this is caused by the server configuration. In particular, there’s likely a security check that’s failing, e.g. in the firewall software or some server software extension like “mod_security”. Such rules, for example, check for “abnormal” patterns in transmitted data. It might also be the size of the table that raises a warning here. Usually, this can be fixed by making certain checks by that software less strict.
Unfortunately, this can not be done in TablePress or WordPress but has to be done on the server level. The first step should be to find out more about the internal server error that appeared here. Usually, you can find that information in the server error log file (you might need to ask your webhost support team for that). Then, they should also be able to make the necessary configuration changes on the server.

Regards,
Tobias

Thanks for the help, I’ve contacted the web host with the mentioned data.

Hi,

great! Please let me know what they find!

Best wishes,
Tobias