This is the place to report bugs and get support. When posting in this forum, please always provide as much detail as possible.
Please do not report problems with a custom build or custom code in this forum. If you are producing your own build from the source code and have problems or questions, ask in the developer forum, do not report it as a bug.
When posting in this forum, please try to provide as many relevant details as possible. Particularly the following:
I know this is a recurring topic but searching in the forum I couldn't find the solution.
I have 3 sites hosted by the same provider (medium trust) for two of them the "search" does not work (and never did).
Single site: search works fine
Single site: search index empty
Site + child site: search index is empty
/Data and /App_Data Folders (and subfolders) have write permissions nonetheless <site>/index subfolder is empty
I deleted the <site>/index subfolder and It's re-created at next search when index is rebuilt (it is writable!)
Physical path have not changed after the initial setup.
Indexbluilder files are present in /Setup/ProviderConfig/indexbuilders as any other sites
I have deleted all rows from mp_IndexingQueue, then from mp_TaskQueue and then rebuilt the index.
After a while TaskManager says that Indexing job is complete but index folder is still empty and mp_IndexingQueue is full of records (with the correct IndexPath).
No errors are reported in System Log.
Any ideas ?
I was persuaded that this issue was not due to mojoPortal, therefore I kept tracking the problem with my provider (Aruba.it) and we realized that despite their "file and permission manager" web interface was reporting write permissions to the Index folder, something was preventing the system IIS user to update it.
Unfortunately I could not have direct visibility on the issue due to the limited access of the hosted environment.
I asked the provider to reset the permissions to the folder and finally I was able to rebuild the search index as expected.
Everything works fine now.
Glad to hear it, it would have been difficult and time consuming for me to try to reproduce the problem here.