fix_cache_key.php suddenly broken?

[zcnb]

OMG - I just discovered that I might have mistakenly blamed this incident on the web host.

After the "problem" has been "fixed" by the "web host", I decided to give the store duplication process another run, to verify that everything works smoothly and that I can perform that within less than 5 minutes.

I repeat the process and... the same problem occurs: fix_cache_key.php yields a blank page.

At this point I begin to understand that there may be something specific in my procedure that triggers this strange behavior... So I:

1. Login to the admin console of the DUPLICATE store
2. Take that DUPLICATE store out of DOWN_FOR_MAINTENANCE mode remember, the database was duplicated while the original store was in DOWN_FOR_MAINTENANCE, otherwise duplication could have unpredictable results).
3. Run fix_cache_key.php

All works fine!

Conclusion: fix_cache_key.php should be run while logged in as admin and store is not DOWN_FOR_MAINTENANCE.

DrByte, is my observation/conclusion correct?

[yellow1912]

Maybe in your case. I always run it without turning store down, always work for me.
Again, having the ioncube problem is really weird, gotta be something with the way your host is configured.

(Why dont you check the fix_cache_key yourself, and you will see that this file contain all simple php with no need for ioncube which is mostly used to decode encrypted code?)

[Website Rob]

Conclusion: fix_cache_key.php should be run while logged in as admin and store is not DOWN_FOR_MAINTENANCE.

DrByte, is my observation/conclusion correct?

Don't know what DrByte will say but I say that is the wrong conclusion.

fix_cache_key should only be run if...

you cannot login to your Admin and change this setting:

Configuration > Sessions > Session Directory

That's basically all the 'fix_cache_key.php' does anyway.

If you cannot login to your Admin and change the above setting, only then I would run it / use it.

[DrByte]

Conclusion: fix_cache_key.php should be run while logged in as admin and store is not DOWN_FOR_MAINTENANCE.

DrByte, is my observation/conclusion correct?

No. There should be no direct correlation.

The problem you reported initially regarding ioncube is (if you think your host is not to blame) more likely related to something else you've got on your site.

ie: do you have some sort of addon installed that runs encoded scripts which would thus require ioncube? Mag icSE O is one such. There are others (and all of them violate GPL by the way).

[zcnb]

Than you all for your feedback. The insights I received from you help me better plan for using fix_cache_key.php properly.

I just got the reply from from my web host's tech and he says that this problem has nothing to do with the php.ini file. The techs (several of them in succession) "fixed some of the php scripts and the mySQL databases" to get this back working.

At least it's good to know that I wasn't too quick to put the web host tech support to work.

As for your question, DrByte, I don't know of such add-ons. If I discover anything new I will post it here.

[zcnb]

1. Login to the admin console of the DUPLICATE store
2. Take that DUPLICATE store out of DOWN_FOR_MAINTENANCE mode (remember, the database was duplicated while the original store was in DOWN_FOR_MAINTENANCE, otherwise duplication could have unpredictable results).
3. Run fix_cache_key.php

OK - I have just confirmed (for the Nth time) that the above sequence is mandatory for my store.

I accept what DrByte said about this not being a requirement but apparently there is some uniqueness to my environment or duplication procedure.

Perhaps this has to do with the fact that I don't create a new dbuser for the newly duplicated database but rather re-assign the existing dbuser to the newly duplicated database?

At the moment I have no definite explanations.