Page 1 of 1

Is it save to use the tmp-directory?

Posted: Sun Apr 24, 2016 8:18 pm
by pengels
Hi all,

background: The Showtime2 module (and previous Showtime) use a subdirectory css, where the corresponding css-files are stored for the different slideshows. This works fine. Disadvantage: this directory will be exported to the xml-file and therefore probably overwrite the settings of the users. One solution would be to delete this folder before exporting to xml. But then I have to recreate my own settings.

Therefore my idea is to place this folder inside the tmp-folder, eg. tmp/Showtime2/css.

Any reason speaking against this?

Regards Peter

Re: Is it save to use the tmp-directory?

Posted: Mon Apr 25, 2016 5:43 am
by Rolf
I don't see a problem, only delete the folder and files at uninstall.

Re: Is it save to use the tmp-directory?

Posted: Mon Apr 25, 2016 10:15 am
by velden
this directory will be exported to the xml-file and therefore probably overwrite the settings of the users
I think (and I expect many others with me) that users should never ever have to change anything in the module's folder. If they do, they deserve the settings to be overwritten on update ;D

CSS, by design, allows styles to be overruled by another stylesheet. So that should be the way to go for users I think.

Disclaimer: I never used the Showtime(2) module.

Re: Is it save to use the tmp-directory?

Posted: Mon Apr 25, 2016 2:33 pm
by calguy1000
a: modules should be using the PUBLIC_CACHE directory if writing files that need to be web accessible. but users should not be editing files directly in that folder.

b: If you have files that are distributed with your system that your users may edit you shoulde use the module_custom approach. i.e module_custom/<myModule>/templates or module_custom/<myModule>/css

Re: Is it save to use the tmp-directory?

Posted: Mon Apr 25, 2016 5:32 pm
by pengels
Hi calguy1000,

just to get things clearer: Do you mean, I should check for an existing directory module_custom inside modules and create it, if it does not exists and store the files inside here?

And where can I find the PUBLIC_CACHE directory? I have none and have never heared of it.

The only thing I need, is some kind of working-directory for the module outside the module-directory.

Thanks.

Regards Peter

Re: Is it save to use the tmp-directory?

Posted: Mon Apr 25, 2016 11:15 pm
by Jo Morg
If I understood your 1st post correctly, both velden and Calguy1000 provided alternative solutions to the problem. I personally think that most users will use velden's solution as it is the more intuitive one to use, others may chose Calguy1000's solution as it has other advantages, but the fact that ALL modules can benefit from either is what makes CMSMS and its modules so versatile. The module install/upgrade methods provide the users with default settings that the user can override WITHOUT ever having to touch any of the files inside the modules' own directory. In most cases (if not all of them) doing so renders an installation not valid for support from either the core Dev Team and or the module developer.
The correct way to customize the module css (when not available through Design Manager) is by using either of the above solutions, and that is something that shouldn't worry the module developer. If the users implement either of the above the module will never overwrite any customization on install or upgrade.
pengels wrote:And where can I find the PUBLIC_CACHE directory? I have none and have never heared of it.
That's currently the tmp folder.
pengels wrote:The only thing I need, is some kind of working-directory for the module outside the module-directory.
Again, if understood correctly, that's what the users need, not the module itself, and that would be module_custom/<myModule>/templates or module_custom/<myModule>/css as calguy100 specified.

Re: Is it save to use the tmp-directory?

Posted: Tue Apr 26, 2016 7:03 pm
by pengels
Hi Jo,

thanks for your response. I have now moved the folder /modules/Showtime2/templates/css to modules_custom/Showtime2/css.

regards Peter