You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the way that the application names apache config files and file hosting directories based upon campaign ID, it is not possible to host both a development and a production environment simultaneously on the same server without one environment mangling the other. Duplicate ID numbers issued in sequence will affect the other instance to the extent that a change made on one environment happens to have the same ID number present in the other environment. Even if you use separate PF instances running out of separate directories, the apache config files still get mangled because of the store location.
One possible solution would be to change the location of the apache config files to reside in the PF directory and to add that directory as an include in the main apache config file as is done with sites-enabled. This would also keep from having to grant access to www-data to the sites-enabled directory.
The text was updated successfully, but these errors were encountered:
If you are going that route I would also use the same naming convention for the deployed campaign directories too. That would give you the option to have a test and production environment that is different databases but the same repo pull. Thats what I was originally trying to do - give a staff guy something to play with without having to worry about him messing with live campaigns or templates.
Due to the way that the application names apache config files and file hosting directories based upon campaign ID, it is not possible to host both a development and a production environment simultaneously on the same server without one environment mangling the other. Duplicate ID numbers issued in sequence will affect the other instance to the extent that a change made on one environment happens to have the same ID number present in the other environment. Even if you use separate PF instances running out of separate directories, the apache config files still get mangled because of the store location.
One possible solution would be to change the location of the apache config files to reside in the PF directory and to add that directory as an include in the main apache config file as is done with sites-enabled. This would also keep from having to grant access to www-data to the sites-enabled directory.
The text was updated successfully, but these errors were encountered: