Forum Replies Created
-
AuthorPosts
-
October 22, 2019 at 8:13 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #697
ppmt
ParticipantI have about 200 invoices I think. It can be a bit slow as well but since I am only testing it at the moment it is not on the fastest machine. It takes about 10 seconds for me to load the invoices pages
October 22, 2019 at 7:44 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #694ppmt
ParticipantRichard seems to be away at the moment. He is really the one that would be able to help you.
October 22, 2019 at 2:51 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #692ppmt
ParticipantNo PDF export does work for me. The issue I had was my templates would not display properly with things all over the place.
I found that mpdf which Richard is using has some limitation with some CSS attributes.Once knows the templates can be adapted
On my side I am using a bit of strange config.
I have a docker container running:
– linux Alpine rev 3.10.2
– PHP 7.3.9 with PHP-FPM
– Nginx 1.16.1in another container I have Mariadb (rev 10 I think)
October 22, 2019 at 2:31 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #690ppmt
ParticipantGlad you got it sorted.
For the PDF I feel for you. It is not as easy as one would think to export to PDF. I have been struggling myself with its limitations.
October 21, 2019 at 12:50 pm in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #681ppmt
Participantfor the php.log file what does the custom.config.php contains? Here is mine
debug.level = All debug.error_reporting = E_ERROR phpSettings.date.timezone = Europe/London phpSettings.display_startup_errors = 1 phpSettings.display_errors = 1 phpSettings.log_errors = 1 phpSettings.error_log = tmp/log/php.log
October 21, 2019 at 9:00 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #674ppmt
Participantwell if all of them are really set to 0 then you have a different issue than I did. I would still check the sqlbackup file to be sure.
And are you sure you don’t have a php.log file in your tmp/log directory?
October 21, 2019 at 8:52 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #670ppmt
ParticipantIs that all your product listed there? If you are like me then only a few were loaded..
I would suggest to check the sqlbackup file (it should be a text file) to make sure that the field default_tax_id_2 is really set to either null or 0 for all product.
-
This reply was modified 5 years, 4 months ago by
ppmt.
October 21, 2019 at 2:19 am in reply to: going from version 2018.1.3 to 2019.1.1 (database issue) #667ppmt
Participantcan you check the database dump file you have (the one you imported) and check that the table si_products.
If the field default_tax_id_2 is set to “” (empty) then it is the reason it was failing for me. The solution is to update the file to set the empty field to null and the reimport the database and restart the upgrade.
ppmt
ParticipantI have tried to play a bit with using div and span rather that table. I also tried to use css grid…
But whatever I try I can get it to display well in the html version (print icon) but if I render it to PDF it just doesn’t render the same.The default theme has the same behaviour
ppmt
Participantany opinion on this issue?
ppmt
ParticipantHum…turns out that apparently float and clear are not supported for table in mpdf
https://stackoverflow.com/questions/51579343/mpdf-float-not-working-for-tables
time for a reflow of my template 🙂
ppmt
ParticipantUploaded and tested. It works
Glad it got sorted 🙂
ppmt
Participanthow about using
$config->email->secure ?
it works for me if I do that
ppmt
ParticipantRight!!!!!
I managed to send an email at last!
But I had to modify the file Inc/Claz/Email.php line 81 to add ssl like this:
$transport = new Swift_SmtpTransport($config->email->host, $config->email->smtpport<strong>, 'ssl'</strong>);
is there any reason why the email.secure from custom.config.php is not used?
ppmt
ParticipantI have been having a long email exchange with the support people at byethost. In the end we could not find the problem but they pointed me to some script example using Switmailer.
Here is the script swiftmailer.php I have written and put in /modules/invoices:
<?php use Inc\Claz\Email; print_r( stream_get_transports()); // Create the Transport $transport = (new Swift_SmtpTransport('sv4.byethost4.org', 290, 'ssl')) ->setUsername('myusername') ->setPassword('mypassword') ; // Create the Mailer using your created Transport $mailer = new Swift_Mailer($transport); // Create a message $message = (new Swift_Message('The Subject')) ->setFrom(['fromemail@mydomain' => 'John Doe']) ->setTo(['toemail@myotherdomain' => 'A name']) ->setBody('Here is the message itself') ; // Send the message $result = $mailer->send($message); ?>
I then use http://myserver/index.php?module=invoices&view=swiftmail to execute it.
and it works. The email is sent and received.Now if I set the custom.config.php to use the same data like this
email.host = sv4.byethost4.org email.smtp_auth = true email.username = myusername email.password = mypassword email.smtpport = 290 email.secure = ssl email.ack = false email.use_local_sendmail = false
if I then try to send an email the normal then it fails with the Timed Out error!
I don’t understand!!
-
This reply was modified 5 years, 4 months ago by
-
AuthorPosts
Recent Comments