Forum Replies Created
-
Posts
-
First request is that you update to master_2019.2. It has the most current fixes. From there we see what problem exists and work to resolve it.
Check out the attached pictures and test with the new PdoDb.php file.
Attachments:
OK, hopefully I am drilling into it. It seems like for some reason, the source field is not being returned as part of the si_sql_patchmanager table. I have attached another update for the PdoDb.php file for you to test with. It will generate even more information in the php.log file. As before, put the PdoDb.php file in the Inc/Claz directory and delete the tmp/log/php.log file before you test. Then give me the new php.log file so I can drill through it.
OK, that gave me some information but not why the logic to set the update value isn’t working. So attached is a zip file for an updated version of PdoDb.php file. Extract this into the Inc/Claz directory, delete your tmp/log/php.log file and test again. Then zip the log file and send it to me.
As Bullwinkle used to say, “This time for sure…” Please try again with file in attached file. Note that I modified the attached file name but the file inside is still PdoDb.php. This change will generate more output to the php.log file but hopefully will print what I am looking for.
That didn’t catch the error. I believe my debug test was wrong and have changed it. Put the PdoDb.php file in the zip attached to this message in the Inc/Claz directory and try again. First clear the php.log file then do the test and give me the php.log from that test.
Basically, you are free to modify templates and use them in your application. There is a well defined process for this. Unless there is a bug relative to the defaults, they will remain unchanged. That’s how it stands at this point.
I’m flummoxed by this. Attached is a zip file with the PdoDb.php source in it. Put this in the Inc/Claz file same as you did for the SqlPatchManager.php file. Keep the SqlPatchManager.php change in there also. Clear your tmp/log/php.log file (can delete it). Run with these changes and send me the new php.log file. Ignore the extra pdoDb-1.zip file.
In the Requirements link to the left, is a requirement to make your database allow zero dates. Not having done this might be the cause of your problem. Here is that requirement:
Make sure that zero dates are allowed in your database. Do this by setting “sql_mode=” in the my.ini file. For reference, make the current setting for this value into a comment by adding a # at the front of the line. An example of what this line might be set to is, sql_mode=NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTION.
You lost me with the www-data. On my windows 10 development system, the windows permissions give full control to my administrative user same as any other windows folder. However, if I look at the folders through the Git Bash window, I see the 755 for window permissions on all directories including tmp and public.
I modified the Inc/Claz/Config.php file to catch the error when the new file is opened rather than when the attempt is made to write to it. This doesn’t fix your error, but kills the request and reports the error where it occurs.
Try this to verify error occurs at attempt to open the new file for write access. If not there, then the resource handle is being corrupted after being opened and that information would be helpful.
The error indicates that SI was not able to create a custom.config.php.new file in the config directory. Check that the directory has 755 as its access (assumes non-windows system). On windows, the directory needs to read/write access for the user.
I see the error but not how it exists. I’ve attached a zip file that contains and modified SqlPatchManager.php file in it. Extract this into your Inc/Claz directory to replace the version you have. This will write some additional debug information into the tmp/log/php.log file.
First delete the tmp/log/php.log file. Then run your SI application to replicate the issue. Assuming it fails the same way, zip the tmp/log/php.log file into a zip archive. You can then upload the zip archive to a response on this forum and I’ll look to see if I have any idea what is going on.
I’m assuming that you changed the defaults to the values I asked you to use. That being the case, no errors in php.log and the si.log content shows a normal execution of the customer list request.
First thing to do is while this command is executing, take a look that the public/data.json file. You should see your customer information in it.
Assuming that is the case and it looks good, I’d like you zip your SI directory and attach it to a reply to this message. The zip file will be too big if you include all directories, plus the config directory contains personal info that should not be shared. So I have attached a picture that shows what directories and files to include. Using this, I can compare what you have with what I have to see if for some unknown reason, you have some different files than you should.
It is a long shot, but I’m not sure what else to suggest at this point.
Attachments:
Recent Comments