Auto update of SESSION_WRITE_DIRECTORY not always working

[torvista]

While chasing my tail investigating an unrelated issue I noticed this constant was not being updated.

I had several development copies of my shop (in addition to the real one) installed on the same server including one in a subdirectory, and was exporting/importing the databases between them.

This code checks for the existence of the cache directory as defined by the db constant:

if (!file_exists(SESSION_WRITE_DIRECTORY) || !is_writable(SESSION_WRITE_DIRECTORY)) { 

since in my case, this directory did exist and was writeable (albeit elsewhere on the server), the constant never got updated to the correct path inside the directory structure of that particular instance of the shop.

[mc12345678]

While chasing my tail investigating an unrelated issue I noticed this constant was not being updated.

I had several development copies of my shop (in addition to the real one) installed on the same server including one in a subdirectory, and was exporting/importing the databases between them.

This code checks for the existence of the cache directory as defined by the db constant:

if (!file_exists(SESSION_WRITE_DIRECTORY) || !is_writable(SESSION_WRITE_DIRECTORY)) { 

since in my case, this directory did exist and was writeable (albeit elsewhere on the server), the constant never got updated to the correct path inside the directory structure of that particular instance of the shop.

Forgive me for not being able to look up the variable that is assigned in the configure.php file(s), but I'm assuming that it is of a different name, and that the suggestion is that the database provided path be compared with the path of the configure.php file(s) and if not equivalent to update, that comparison anded with the above or group...

[torvista]

Forgive me for not being able to look up the variable that is assigned in the configure.php file(s),

DIR_FS_SQL_CACHE

but I'm assuming that it is of a different name, and that the suggestion is that the database provided path be compared with the path of the configure.php file(s) and if not equivalent to update, that comparison anded with the above or group...

Well summarised! This is what the manually-run fix-cache_key.php did, prior to 1.53.

[mc12345678]

DIR_FS_SQL_CACHE

Well summarised! This is what the manually-run fix-cache_key.php did, prior to 1.53.

After (and really while) making the above suggestion was thinking about the overall scheme of things. There is a condition that wouldn't be met if the change is made as much as isn't met right now. Scenarios run like this. If nothing is changed, the key works fine for stores that are duplicated away from the production store's cache directory if the duplicate site (not really suggested in any of the FAQs for making a "backup" of a site) is located elsewhere in the host's path but uses the original database. If the change is made to what it was/suggested, then it would almost be paramount (I think) for two stores not to share the same database as "confusion" is likely to ensue. Don't know if an additional switch would be needed in the admin to control this "functionality", or if it would need to be something coded in a file as a result of the sharing/not sharing the database. Sorry, started going down a rabbit hole and now want to get out. :)

[torvista]

It just seems to me that any installation fileset should be self-contained.
If you have multiple shops on the same server, whether duplicates/backups or different shops entirely, this will not auto-update to the "correct" location in the relevant fileset if the folder in SESSION_WRITE_DIRECTORY already exists anywhere else, which seems incorrect to me.

I'll let the the great and the good argue the toss/go down the rabbit hole, I was just pointing out the anomaly.

[mc12345678]

It just seems to me that any installation fileset should be self-contained.
If you have multiple shops on the same server, whether duplicates/backups or different shops entirely, this will not auto-update to the "correct" location in the relevant fileset if the folder in SESSION_WRITE_DIRECTORY already exists anywhere else, which seems incorrect to me.

I'll let the the great and the good argue the toss/go down the rabbit hole, I was just pointing out the anomaly.

Seemed like a good find to me. Wondering if this section of code didn't get updated upon earlier determination of how to "properly" restore the setting, or if there was a true background reason for it.

Being community oriented, I merely wanted to point out some "issues" that possibly could occur nd may need to be documented or otherwise handled.