Once upon a time there was a Magento web shop with big and complex catalog. Also this Magento shop used custom extension to support product-category relations based on rules rather than the usual array of checkboxes in product edit view and product grid in category edit view.
For this rule based relation to work, they also rewrote product-category indexer to take rules into account. Not surprisingly, this indexer took lots of time and memory to complete. I wanted to test it on local, and expected simple task:
- Get code
- Get database
- Launch indexer
After 15 minutes of indexing, it crashed and claimed it had run out of memory. I am a generous person, so went ahead and doubled memory limit and restarted the reindex. After another 15 minutes it crashed again! And it crashed at the same memory limit.
Still, I wanted to show my good will and checked that memory limits for both web server and command line were exactly what I had set AND larger than the reported memory usage. To make sure, I even added an ini_set() right at the start of indexer.php. That greedy reindex process now had no chance to die!
And yet, it did. I was getting confused now — why would indexer die before reaching my limits? Would there be some internal limits? Needed to check the indexer script line by line. In the beginning we have:
So there is this abstract.php, let’s see what does it do:
_applyPhpVariables??! Wonder what that is:
So we have a function that reads .htaccess file and applies whatever PHP runtime values are set there. There you have it — you may be using nginx and shrug .htaccess off as an relict from the past, you may be using command line and think you are the king at your localhost, but you can’t run away. Unless you delete .htaccess file, which you probably did not need anyway.
‘Magento peasants may think they have the power, but we have planned exactly for that.’
— Magento Core Team
Author: Jānis Caune, Senior Developer in SW.