My project is running perfectly fine when run locally (although it connects to the server database)_. When I deploy it and run off the server anything I try to open from the menu does not open up.
I’ve never seen such a behavior (although I have to admiit I just updated SC to v9.2.013 - so not shure if the update did something or it is something else…
Any ideas ?
All-too often, I have to completely re-deploy an entire project following a ScriptCase update. The project images, icons, and ScriptCase libraries as well.
NetMake sometimes breaks existing deployments with their updates, and the only option is to do a complete rebuild/re-deploy of the entire project. But you can’t count on them breaking it, either. You’ll only find out when you try to roll out a simple change and nothing works.
If they forced their marketing people and executive management to use remotely-deployed ScriptCase apps in order to access their bank accounts, updates would always work.
My workflow (this works so far):
Now, whenever you need to make a change to your project, move your existing ScriptCase (presumably updated) aside, pull your project, make any changes to your project files, ignoring the update warnings, deploy your updated apps, add or commit your changes in git, remove the old version, move ScriptCase back.
Alternatively, you can make a bzip2 tar backup of ScriptCase whenever you deploy, and name the backup for this version of your project. This way, you can restore a version of ScriptCase that won’t destroy your production environment every time you correct a spelling mistake on a label. This will use a LOT of disk space.
This might work and I do something bit similar but the problem is that I have never expected that App that runs of the local PC will have issues on the server. For the last year I almost always ZIP entire SC folder before I run any updates, but this was this one time I did not. Also doing all this not only takes gumongous HD space but it takes lots of time. Even if everything is automated those processes tie up my Pc for entire night or day, while I need to do other things.
Here is the issue more in detail:
The links on de server got screwed up. another words they are different from the local set. That is probably why the MENU fails to open anything, alhoutgh I’m not sure what those variables are for. There is a “sc_usa_grupo” parameter in the link which in my case on the server is empty and on the PC takes a string of “S”. Not sure if this is the culprit but that is the first difference I noticed.
See the links
LOCAL
[ATTACH=JSON]{“data-align”:“none”,“data-size”:“full”,“title”:“2018-10-29 23_21_16-menu.jpg”,“data-attachmentid”:85273}[/ATTACH]
SERVER
[ATTACH=JSON]{“data-align”:“none”,“data-size”:“full”,“title”:“2018-10-29 23_22_37-menu.jpg”,“data-attachmentid”:85274}[/ATTACH]
I’d move the production system out of the way (mv /var/www/html /var/www/html.wth), create a new folder (mkdir /var/www/html), re-extract the entire deployed project to that folder, and set the ownership (I presume you are setting ownership via chown -R www-data:www-data /var/www/html whenever you upload changes, because that will cause this behavior.
I’d verify that ownership thing no matter what, because ownership problems will definitely cause this. On most servers, www-data is the usual owner of web data, but check in /etc/passwd to make sure. ScriptCase’s default ownership is apache:apache… The NginX web server uses “apache” as well. Double, then triple check that.
If that doesn’t get it:
Set up to deploy the project, grab the archive created by Deploy Project and de-archive it to a folder, “Test1”, on the local system.
Grab the production files from the server (rsync is a good option) and put those in a second folder, “Test2” on the local system.
Run the commands:
cd Test1 && find . -type f -print -exec diff {} …/Test2/{} ; | less
That will show you all the files (paginated) with any differences marked via < or > to indicate which file contains that difference.
If none of that works, it might be time to find a witch doctor.
Hello,
This problem has been fixed and is available for update.
Regards,
Eduardo Kahn
Bug Tracker Team