• Hi Mikko,

    Up to Version 4.1.4 tablepress_table post types could be excluded from index in the settings, but now tablepress_table is no longer listed.
    With the recent update I see tablepress_table content as search results. In my case the displayed excerpt is full of URLS from the table which looks very odd and is not relevant.

    Relevanssi finds now the tablepress_table itself not posts with expanded shortcodes (which would be OK).

    How can I exclude tablepress_table from index?

    Thank you.

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Mikko Saari

    (@msaari)

    Actually, quite the contrary, version 4.1.4 removed the possibility to index the tablepress_table post type, because I thought nobody wants it included anyway…

    However, if you had the tablepress_table post type included in the index, 4.1.4 makes it impossible to not index it. However, if that’s the problem, saving the indexing settings should remove the tablepress_table from the list of post types to index.

    Thread Starter mission500

    (@mission500)

    No, unfortunately this doesn’t work.
    * saving the settings -> tablepress_table post types still found in search results
    * downgrade back to 4.1.4, tablepress_table post types are shown as not included in the index, and are now also not found in search results (OK)
    * upgrade to 4.2.0 -> tablepress_table post types found in search results again

    So, I keep 4.1.4 for the time being.

    Thread Starter mission500

    (@mission500)

    One more thing, even when I do include tablepress_table post type in the index (v 4.1.4 indexing setings) it won’t be found as search results.
    Is there another way to include/exclude them?

    Plugin Author Mikko Saari

    (@msaari)

    Is it possible you have a filter on relevanssi_do_not_index that would make Relevanssi index the Tablepress posts? That’s the only explanation I can come up with: Relevanssi blocks the indexing as it should, but then a filter function lets the Tablepress posts in. However, if that’s the case, the problem would persist with 4.1.4…

    Otherwise, I just see no way how those posts are getting in the index in the first place – they just shouldn’t, period (and on my test site which has the latest Relevanssi and Tablepress, they don’t).

    Can you check what get_option( 'relevanssi_index_post_types' ); returns on your site? Is the tablepress_table post type included or not? What does this print out?

    global $wp_filter; var_dump( $wp_filter[ 'relevanssi_do_not_index' ] );

    There are ways to exclude the posts, but I would recommend getting to the root of this matter to make sure the posts don’t get indexed in the first place.

    The only thing that changed in 4.2.0 is that tablepress_table was added to the list of forbidden post types, which means it’s not listed in the post type indexing options. That’s exactly the only thing that has changed, and I can’t see how it could have an effect like this…

    Thread Starter mission500

    (@mission500)

    Hi Mikko,
    sorry for the delayed reply.
    get_option( ‘relevanssi_index_post_types’ ); doesn’t list the tablepress post type, just posts and pages and bogus which seems to be for internal use.

    Now I could dig a little deeper, and the described issue seems to relate to an indexing problem. When I manually re-build the index the process gets stuck (already after a few documents), but it would be entirely completed with no documents left after pressing ‘index unindexed posts’.
    As apparently the automatic indexing process got stuck, indexed old table press content didn’t get deleted. For some reason the tablepress content didn’t show in search results with version 4.1.4 and before but does show in version 4.2.0
    After manually re-building the index (in two steps) the tablepress content no longer show in search results. So that issue is gone, but after some tests I’m still clueless what makes the indexing stuck. It’s most likely not related to a specific post, but seems to have something to do with Siteorigin pages. Even those are covered in the first run of indexing and it stops later in the sequence. But in case I delete all Siteorigin pages, the manual indexing is completed in one run directly.
    How can I ensure that changes of documents would be added through the automatic indexing process? Or do I now need to regularly trigger the manual re-building (in two steps)?

    Plugin Author Mikko Saari

    (@msaari)

    Relevanssi indexes changes to the posts automatically and since that indexing only handles that one post, other posts won’t affect it in any way.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘How to avoid tablepress_table content found by Relevanssi’ is closed to new replies.