Andrea

Yes, I have tried several times to perform indexing with the option “shortcode expansion” enabled, but after counting the articles we see the counter of the elapsed time that continues to increase, but the horizontal top bar remains empty.
On the other hand, if I disable the “shortcode expansion” option and start creating the index, I see the green top bar incrementing and after just 36 seconds the indexing of the site ends (there are only 76 articles).
The problem may be related to some other “shortcode”, rather than to tablePress.
I use shortcode from:
– TablePress.
– SDM (Simple Download Monitor).
– MetaSlider.
– Responsive Posts Carousel.

Regards,
Andrea.

Also I would have the same request, but my problem is not to not count the downloads from the bots, but not to allow the download at boot.
Therefore it seems interesting to activate the “download” button only after the reCatchpa control has been passed.
In short, I would like my download to be done exclusively by a real person, not from the bots. Otherwise they mirror my documents in the download and people download the file from them and not from me. Made myself clear?

Regards
Andrea

Good!
Now the settings are more precise! Good job!

Regards, Andrea.

I have the same problem too.
I have tables made with “TablePress” that I would like to index. They have some shortcodes in some pages.
If I disable the expanding shortcode field, they are not indexed and I do not get those tables in the search results, but I need to have them.
In the “Indexing Options” the type “tablepress_table” is set activated in the “Index” column, but the “Excluded from the search?” Column it is set to “yes”. I have read that that column does not matter in building the Relevanssi index, but how is it possible to change that column from “yes” to “no”?
How can I index my tables without getting a block of Relevanssi?

Regards, Andrea.

ok I’m waiting.

Regards, Andrea.

Ok, I’m looking forward to the next version.

Regards, Andrea.

Yes, I updated to 2.4.2 now you can use the post tags on the pages.
In any case I am convinced that a layout of the settings as I wrote in the previous post, would make the plugin more complete and easy to understand.
For example: now it would not be possible to use the posts category in the pages and have separate tags for the pages (WUD Page tags). Instead with the setting I wrote, you could disable “Unique page categories” and activate “Unique page tags”, to have that mode.
Moreover, now the “illogical” is still valid as regards the explanation of “Unique page categories / tags” which appears by clicking on “?”.
Think about it.

Regards and thanks, Andrea.

Waiting for the new release, I wanted to recommend a more logical and natural arrangement of this change referred to in this post, if I may.
Now to have the same tags in posts and pages, you need to set “Add Tags to pages” to OFF.
But this is not logical and goes to clash with the explanation of the field that appears by clicking on “?” on the plugin setup page. It says: “If not activated: Tags are only available for post (WordPress Standard)“. This would not be true! In fact in this case I get the tags both in the posts and in the pages.
Also with this new mode it is not possible to eliminate the use of tags in the pages (as it was possible to do previously).
Therefore, in my opinion, the best (and easiest to understand) solution is this: restore the operation of “Add Tags to pages” as it was previously, but separate the setting of “Unique page categories” and “Unique page tags” with two separate Activate switch.

Regards, Andrea

I am having the same issue!
It is not true that it is not possible to create sub-categories in the second language.
If I create a new sub-category, it is possible to do it in both languages. The problem manifests itself when I try to “change” the parent category of a sub-category.
I feel that if I change the parent category of the category (LANGUAGE 1), it changes. However, the parent category of the category (LANGUAGE 2) is still the old one. So when I open the category (LANGUAGE 2) for change the parent, it goes to overwrite LANGUAGE 1 which returns as it was before. It’s a loop that does not stop.
The only way is to create categories, sub-categories and parent categories immediately before cloning from the first language to the second language.
But this is not a good thing: sooner or later it will happen to have to change something.
How is it that the Polylang developers have not yet solved this flaw?

Andrea

Yes thanks. This can be a good solution compatible with any search plugin.

Regards, Andrea.

Because of the problem of “Search Everything” (see post) I replaced it with “Relevanssi” which has more settings in the control of the pages and post to be returned in the search.
In the settings of “Relevanssi” (Options – Search) it is possible to exclude some categories from the search results. Unfortunately, only the standard WordPress categories are available (post): the “WUD Page Categories” categories are not shown so you can not select them.
Why are they not displayed? Is it a problem with your plugin or is it “Relevanssi”?
Do you think that it would be possible to display the categories of your plugin as well?

Regards, Andrea.

• This reply was modified 6 years, 12 months ago by Andrea.

I did the tests you recommended: the culprit of this flaw is the “Search Everything” plugin!
The category filter defect also appeared in posts and in the media. When I deactivated that plugin (Search Everything) everything is back working, even the filter with the “WUD Page Categories”.
Excuse me if I have accused your plugin of this flaw. ??

Regards, Andrea.

So it is better to keep 2.3.9, do not upgrade to 2.4.0 and wait for the 2.4.1 to be published? Is this correct?

Andrea.

Well, I’m glad you found the flaw.
Danny, you do not have to apologize for this: your plugin is free and all we get from your plugin is a gift. We are the ones who have to thank you for your work, it is not you that you have to apologize if something does not work well.
Thanks, Andrea.

I did a little test: I installed “Simple Tags” together with your plugin to verify where the defect I wrote just before came from.
Well now the tag search works correctly: the page of the results lists both the pages and the posts.
So I think something is missing in the last change you made. I would like to just keep your plugin and delete Simple Tags.

Thanks, Andrea.