Forum Replies Created
-
Posts
-
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:
This isn’t unexpected. Print use the template setting whereas the PDF uses margin and font settings from the custom.config.php file.
There should be information in the tmp/log/php.log file. Please provide this. Also, in your database check the structure of the si_sql_patchmanager file and verify that the sql_id field exists.
In your config/custom.config.php file make sure you have the following settings:
debug.level = All debug.error_reporting = E_ALL & !E_DEPRECATED zend.logger_level = DEBUGThe debug settings are probably already set this way. But if not, will cause runtime errors to be reported in the tmp/log/php.log file.
The zend.logger_level setting will have a lot of debug information to written to the tmp/log/si.log file.
If your problem still exists, zip these files together and attach to a message added to this thread.
Recent Comments