Items imported into Treepl using Templates do not always need to be found by Site Search.
By default, all imported Items are found by Site Search.
In Use Cases where Items should not be searchable it is necessary to edit every Item after it is imported and check the Disable From Site Search check box.
A number of partners have encountered this issue, some with large imports and others with many smaller imports. It is an issue that will affect all Partners who use Import Templates at some point.
This issue could be fixed by adding a column to the Import Template to show whether the Item should be found by Site Search. The values could be True (searchable) or False (disable from site search).
The Import Process could check the Disable From Site Search check box for that slide when the value was False.
Certainly an issue. I think though, the Backlog request should simply be for âDisable from Site Searchâ field to be included in ALL module import/exports as this effects them all - Pages, Banners, FAQs, Blogs, etcâŚ
I agree Adam - I have updated the Backlog Request. I had thought about that earlier today - In addition to the Slides in the Galleries I have Lookup Tables that are used by other Modules & these Items never need to be found. Just hadnât got around to editing. Thanks for the prompt.
We have already created a functionality to set all entire siteâs content to become visible for search engines (or hidden): http://prntscr.com/mjoyew (screen from staging environment of the current sprint).
This should help solving the issue.
Also the is a functionality that uses modueâs setting http://prntscr.com/mjozxv during import NEW items and create items from frontend processes in order to set that value to all newly created items.
Iâm not sure this screen shot resolves the issues I have raised, through treepl Support and via Backlog.
There is a bug in the index process used by Site Search within Treepl.
When a new item is created in a Custom Module, that item can be found by site search.
When that item is edited it is often removed from Site Search and can not be found.
I was advised by Treepl Support that there would be a button that would allow an entire site to be reindexed for Site Search within Treepl Site Search so that these items can be found.
Does the ENABLE ALL PAGES VISIBLE FOR SEARCH ENGINES button do that?
It looks more like it might be the same as editing every page and ticking the Show this page for search engines check box.
âDisable All Items From Site Searchâ check box
I donât see this screen anywhere so I presume it is new functionality.
Iâm not sure it resolves the issues I have raised, through treepl Support and via Backlog.
Please correct me if I am wrong.
Right now I can:
Edit a Gallery, check the Disable from Site Search check box and save.
Import a set of Slides using the Import Template
Find each of the new slides using Site Search
Checking the Disable from Site Search button has no affect on Slides imported after the box was checked. I have to edit every slide and check the Disable From Site Search button.
Note: Editing the Slides takes much longer than the import process.
It looks like an all or nothing approach. That suits me but there was another thread in Slack requesting items to be flagged searchable or not searchable in the import template during the import process.
Does it apply to Custom Modules only or will it also apply to Content Modules like Gallery/Sliders?
If it applies to Gallery/Sliders it will certainly save editing every slide - saving several minutes per Gallery.
BUT because it takes so long for treepl Admin to open the Gallery/Sliders page when there are many Galleries, it will still take at least 90 seconds in total per Gallery to:
find the Gallery,
edit the Gallery,
save the Gallery,
find the Gallery again,
open the Gallery
and finally import the slides.
45 seconds of that time is for Steps 1, 2 & 3 which were not required before.
That is avoided by manually creating the Galleries but importing Gallery Names is so much faster. And a column in the Import Template to Disable from Site Search would remove this issue from the start.
If it applies to Content modules as well as Custom Modules, will it require the Pro+ Plan or will it work with these other plans as well?
If somebody would write up the request for the backlog I will add it with the next âbatchâ of requests. I have lost track on what is needed and if the ârebuild indexâ resolves some of the problems
I had presumed that sufficient to get it to the backlog.
Treepl provided a way to disable from Site Search with Custom Modules but not with Galleries & Sliders in the last Sprint.
This now a critical issue for me because Galleries & Sliders do not scale. They get slower and slower as data is added
Importing 10 Slides into a Gallery can take in excess of 15 minutes simply because editing Slides & loading the Galleries & Sliders Admin page is so painfully slow.
Prior to last weekend it was taking around 9 minutes. After the weekend it is taking much longer. Treepl Support canât see a problem other than it is slow. Slow is the problem.
Note: I have more than 350 Galleries. I imported the empty Galleries when I first started migrating this Web Site. At that stage it was taking 20 seconds to load the Galleries & Sliders Admin Page. With no more Galleries added it is taking just on 40 seconds after last weekend. Again, Treepl Support canât see a problem other than it is slow. I was advised that Gallery pagination would be introduced in the next Sprint to reduce the load time.
And I have many more Galleries to import.
It is still necessary to edit each Slide to keep the Slide out of the Site Search index.
If the original post in Public Backlog is not sufficient to get the request into the Backlog, please let me know what else I need to do.
Hi Peter - Just to be clear, I wasnât trying to slow the proces in any way, since comments kept coming in and Vlad was commenting, I was waiting to add this to be sure that we had all the details in the request or there was a solution already on the way.
When I read the comments today I wasnât sure if some of it had been resolved with the ârebuild indexâ and thatâs why I asked if somebody would sum it up, so I could add it to the next batch.
So wasnât trying to slow the process down, I will add it to the next batch of requests
EDIT: So I have added the text from the original post, the one marked with green in your screendump, let me know if you need any further details added. I will update the public backlog with the latest request within the next couple of days
