Alexander.X Posted October 10, 2016 Share Posted October 10, 2016 Hello everyone! Its strange, but I haven't found the answer in official documentation... So, the question: for example, I want to register global Smarty plugin, or nake my own global defines, or make something else global... Seems like best place for those purposes are the /config/* files (smarty.config.inc.php, defines.inc.php and so on). But I'm still not sure that change of any file in "/config" dir is safe and will not be lost when I update PS engine or some module or somewhat else. Could you assure me that this is safe? Thanks in advance. Link to comment Share on other sites More sharing options...
rocky Posted October 11, 2016 Share Posted October 11, 2016 Those files will be overwritten when you upgrade PrestaShop. You shouldn't be using global variables anyway. Link to comment Share on other sites More sharing options...
Alexander.X Posted October 11, 2016 Author Share Posted October 11, 2016 thanks for reply, rocky! Those files fill be overwritten when you upgrade PrestaShop. ... hmmm... and what about config.inc. php, settings.inc.php? they contain a store-specific settings (DB access information, crypto-keys like _COOKIE_KEY_, and so on), and I thought they should not be owerwritten... and I really thought that all /config dir is for store-specific settings, safe from overwriting, no? OK, lets say I'm wrong... then I have new questions: 1. do I have to copy and restore my settings everytime I upgrade PS? (I speak not about making backup to restore if something went wrong, I speak about normal upgrade workflow, the steps to be done to upgrade when everything goes OK) 2. where should I register global Smarty functions/modifiers to be used in any template? ... You shouldn't be using global variables anyway. You right, I shouldn't, but I speak not about global variables, but about global settings (smarty modifiers t be used in any module, define that stores path to some new directories, and so on). Link to comment Share on other sites More sharing options...
rocky Posted October 11, 2016 Share Posted October 11, 2016 Yes, those files are overwritten too, but after reading the code, it seems settings.inc.php is copied to settings.old.php before it is overwritten. Link to comment Share on other sites More sharing options...
Alexander.X Posted October 11, 2016 Author Share Posted October 11, 2016 OK, got it... And what about the place to register global smarty plugin? I see that all plugins are registered in smarty.config.inc.php , but where should I register my own custom plugins? Link to comment Share on other sites More sharing options...
rocky Posted October 11, 2016 Share Posted October 11, 2016 You can put them in that file. You'll just have to remember to back it up before upgrading PrestaShop and restore the file afterwards. Link to comment Share on other sites More sharing options...
Alexander.X Posted October 11, 2016 Author Share Posted October 11, 2016 Hmm... As for me that is the wrong way. It's like changing the kernel files, and "just to remember to backup changes before upgrading and to restore changes afterwards". What is the convention "I dont modify core - prestashop dont owerwrite my changes" for in this case? Are you sure there are no the better place to register global smarty plugin? Link to comment Share on other sites More sharing options...
rocky Posted October 11, 2016 Share Posted October 11, 2016 I guess you could override FrontController.php for the Front Office or Controller.php for both the Front Office and Back Office and register them there. Link to comment Share on other sites More sharing options...
Alexander.X Posted October 11, 2016 Author Share Posted October 11, 2016 afaik, constructor of base class will be called every time the any derived class instance is created. so the question is: how many controllers (instances of different derived classes) may be initialized when processing one request? I feel possibility of registering plugin multiple times per request on creating different derived classes, instead of registering once when initialize engine. Yes, I can manage it by semaphores (like booleans in special singletones), but it looks like fixing consequences of wrong decision. Link to comment Share on other sites More sharing options...
Alexander.X Posted October 11, 2016 Author Share Posted October 11, 2016 is there a class that is definitely initialized once per request? Link to comment Share on other sites More sharing options...
rocky Posted October 12, 2016 Share Posted October 12, 2016 Sorry, I'm not sure about that. Maybe index.php? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now