Umm the easy way would be to use wget to request the page on localhost. The harder way would be to isolate the code needed into an actual command line script, for which you will need a competent PHP programmer. For a fee I could do it, or I could try to help you for free on here. Out of curiosity how many products are you guys loading?
I sent a ticket to my hosting support and they fixed it for me:
OK, The Layered Navigation Indices are working and have been refreshed. This is what I did to accomplish this. I uploaded the php5-cgi binary to your cgi-bin directory and created a php.ini file with one line that allows execution time to run for 10 minutes. It took close to 8 minutes for the indices to refresh.
I sent a ticket to my hosting support and they fixed it for me:
OK, The Layered Navigation Indices are working and have been refreshed. This is what I did to accomplish this. I uploaded the php5-cgi binary to your cgi-bin directory and created a php.ini file with one line that allows execution time to run for 10 minutes. It took close to 8 minutes for the indices to refresh.
Hope this help.
This is probably because your server has php4 and you are using php5-cgi to go around this (correct me if I’m wrong).
I have php5 on my server so I don’t use php5-cgi.
I’m working with Dreamhost now to fix this. Dreamhost by default runs php via a cgi script. There used to be a way to choose in the webpanel but now DH forces cgi use. At least the best that I can tell.
Well this is what Dreamhost has e-mailed me back. It basically says that Magento is a memory hog and there is nothing I can really do about it:
Happy to assist you with that!
It actually looks like you’re going over the allowed memory usage. Aside
from site traffic, Uploading the larger file is likely pushing over the
limit.
Changing the max upload in htaccess actually won’t do anything as PHP is
running as cgi module as opposed to mod_php. Htaccess just can’t pass
php.ini variables. In order to increase the max_upload, you’d have to
follow the steps mentioned in this post.
Yes, I agree with above.
I’m using the clear_cache.php via cron job to refresh the indices but it is being killed by my server after few minutes.
When I asked my hosting company to see what is wrong they responded:
This script uses a lot of resources on the server, and is killed automatically. Please check whether the script is malfunctioning, or you can streamline it.
Unfortunately, this is a setting we cannot change as it keeps things under control, and controls the quality of service for many other users.
So, we are stuck with this problem until Varien finds a fix for this.
For a work around at the moment I’m creating subcatagories and more or less making my own navigation. I’m also switching from dream host to a VPS. When I said Magento was a memory hog I didn’t really mean it as a bad thing. The reason it uses so much memory is because it’s doing some pretty heaving lifting for us. I really enjoy how it creates the layered navigation based off of the attributes. It does this so much better then zen, or oscom.
I would be interested to know if there was anyway to have Magento break up process into small threads and then combine them when all tasks have been completed.
This is driving me nuts. I have 27,000 products and have spent months getting ready and am ready to go live and can’t rebuild any of those indexes. Have maxed everything out. If I disable the layered navigation will it rebuild the search indexes. I can’t even rebuild those.
Is there any way to find out what the index is getting hung up on? I’ve also tried using the clear_cache.php, and I get the message that my layered nav was successfully reindexed, but I see nothing. My catalogindex_eav table is also empty, what does this mean? I want to make sure that it’s not a problem with the products im importing.
My indexes show up… but the counts are all wrong… what table might be missing data to give me partial data in the layered indexing ?
Oddly, when you click that layered index, the products shown usually match the count (not always)… so my guess is this is a database issue with some data missing since I recently updated to 1.21
