Forum Replies Created
-
Posts
-
The problem is the PDF logic on a localhost server cannot handle an absolute URL path to the icon image. It does work with a relative path.
I just update the files on github to change the logo path to a relative path on all export template. This is version 2020.3.20. If you have your own template, you can remove the holiday_logo function from it as the logo value passed to the template is correctly modified and any holiday logo resolved before it is passed to the template.
The holiday_logo function in the template still exists but does not change anything. It will generate an entry in the error_log file indicating that the template should be updated. This is done so that your template will process correctly even with this function still in it.
Turn on tracing to see if there are any places that processing stops. Do this by setting these values in the confgi/custom.config.ini file:
debugLevel = All
debugErrorReporting = E_ERRORThis will report information in the tmp/log/si.log file.
Note that secure information is reported in this file, so make sure any is obscured if you show this info in this forum.
Normally, when the unresolved loading happens, something is wrong with the data table information. Do make sure that you have the both the gdt and the intl extensions enabled in your php.ini file. You can verify this via the SI phpinfo.php file. To use this, modify the $secure setting to false. Then access this file by specifying /phpinfo.php after the SI https entry.
The attribute error has nothing to do with the logo. I have the same issue on my windows system that you do. However, on my live website, hosted on a Linux domain server, I do not have a problem. So while I haven’t resolved the issue, I think it has to do more with PDF generation on my XAMPP setup; possibly because it doesn’t have an SSL implementation. That is, the logo URL used, uses https and not http. This is something I’ll test later to see if that is the case.
The issue is that your data base is not set up. Make sure you can read it via your phpMyAdmin app (or whatever app you use to setup and view your database). For the master_2019.2 version, the database information is in the config/custom.config.php file. For the master_2020 version it is in the config/custom.config.ini file. If it is the master_2020 version you are loading, it is possible that the databasePassword value needs to enclosed in quotes. Once this information is properly set up, the application will proceed to the update screen.
If you want to deploy on another system with a version of PHP 7.4x, it shouldn’t be difficult provided you can get a full extract of your existing database. You can create a new database on the new system, upload the extracted contact. You will need to download the master_2019.2 version. Make sure this is the version you down load. It needs to be used to update the database content before you can change to the master_2020 version. You will need to update the information in the config/config.php file for the database. You can get this info from the config/config.ini file on your existing system, It might be necessary to enclose the database password in double quotes if it has special characters.
Once this setup is in place you can access SI from your browser. If it is set up correctly for database access, you will get the update screen that shows you a list of updates to apply. If not set up correctly, you will get a message that you need to create your database. In this case, check the settings in config/config.php file and try again.
The master_2019.2 update is important. It contains a change to add foreign key support to the database. All updates prior to this one will apply but the foreign key update can stop if it encounters orphaned records. This situation needs to be handled on a case by case basis.
For example, one user had multiple domain ID’s in his setup and this caused the the update to stop reporting records with orphaned ID’s. Other examples are orphaned si_invoice_items records or orphaned si_cron or si_cron_log records. The domain required the missing domain record to be added to the si_user_domain table. The later issues probably need to orphaned records to be deleted. Whatever is required, you need to address the issues and then access SI again so the update process completes.
Once he master_2019.2 update completes, you can update to master_2020. You can get all the needed update information via the Version Update Process link on the left menu.
Hope this all works out for you.
Recurrence by definition is the creation of a duplicate of a specified invoice. Since my recurring invoices are not always complete duplicates (may have additional charges, etc.). My approach is to set recurrence for the invoice that most closely resembles what I want. I turn OFF the option to email it to the customer but turn on the option to email it to the biller (aka, me). When the new invoice is generated, I can view it in my email to see if it is what I want. If not, I modify the new invoice and then send it to the client. If it is what I want, I typically forward it from my email scrubbing all indications it is being forwarded.
If you update the new invoice to be what you want and wish to have that be your future recurrence, you can edit the existing recurrence record and have it reference the new invoice. You do not need to update start date unless you want the day of recurrence to be other than an anniversary of that date. Logic exists to prevent a recurrence from being processed multiple times. So if your start date is 2022-04-16 and your recur period is 1 year, the next recurrence will be on 2023-04-16.
The current version is 2020.3.17. You can download the zip file for it from GitHub @ fearless359/simpleinvoices. The default version of master_2020 is what you want. Here is the path: https://github.com/fearless359/simpleinvoices
The setting to defer rendering of other than the first page is set. This allows first page to display one rendered, deferring the rendering of the remaining page until requested to computer overhead allows. Not sure how to improve on this short of changing the logic to only display x-months worth of data on initial load with an option like a flag up top to load remaining data. If people keep having trouble like this, that might be a solution to be pursued.
What version of SI are you on? Check the About link on the top menu line. Also, what version of PHP are you on? Verify that you are on a version of 7.4x.
Great news. The issue evolved around the last update required for master_2020 being 319 and that being the last update you had. Why this hasn’t happened before, I don’t know. But I’ll post the fix and it shouldn’t happen to others. Thanks for helping work this out.
I’ve attached a zip file with an update index.php file in it. Use this in place of the one you have in your root SI directory. Reset your database to what it was before the upgrade and run SI to see if this doesn’t resolved the issue. Let me know what happens, good or bad.
In your database, what is the greatest value of the sql_patch_ref field in the si_sql_patchmanager dataset. If the dataset is not empty, the greatest value should be 319. This is the greatest patch number applied in master_2019.2 and master_2020 begins it patch settings from there, starting at 320. If this dataset is empty, you are doing a fresh install an the essential data adds patches 319 through 326 (or greater when future patches added) to the dataset.
Things to also check:
1) In config/custom.config.ini, make sure the database settings are correct. I suspect they are because the code is acting as though it can access the database.
2) Check the tmp/log/php.log file and see if there is an error being reported. If you are unsure of the error info being from your last test, delete the content and save the empty file. Then access SI again to recheck the content of this file.
3) Delete the tmp/log/si.log file if there is one. Then in the config/custom.config.ini file set the loggerLevel to DEBUG. Run your access again and see what gets logged.
You can zip either the php.log or si.log file to this forum if you want me to look at them. Although, you should sanitize the confidential data in either file. There probably isn’t any in the php.log, but you will see database names and passwords and possibly email names and passwords in the sl.log file. Just replace these with x’s as nobody but you needs to see them.
Check the version of SI you are on. If master_2020, the config/custom.config.php is no longer used. The config/custom.config.ini is used and that is where you should make changes. If not on master_2020, you should update to it before reporting an issue.
Recent Comments