Email template and data exhaustion

Ok,
so now I ran into some issues :slight_smile:

Trying to send a quote I get a fatal error:

**Fatal error** : Allowed memory size of 33554432 bytes exhausted (tried to allocate 32 bytes) in **/home/mydomain/public_html/ip/vendor/mpdf/mpdf/src/TTFontFile.php** on line **4676**

Uh? 33554432 bytes exhausted ?? with a simple email and a quotation PDF attached to?

Another one is the:

Template tags can be used to add dynamic information like the client name or an invoice number to the email template. Click on the Body textfield and then select a tag from the drop down. It will be automatically inserted into the textfield.

Clicking on the Body text field and selecting a tag doesnā€™t add anything?

Which side of my brain isnā€™t working here? :wink:

Thanks for rattling me awake.

Ops, too late here, so I forgot:
Trying to view the quotation in the ā€˜client viewā€™ link, throws a

404 Page Not Found

Update:
I tried all three [3] email sending options;
PHP Mail
Sendmail
SMTP
All three options throw the same bytes exhaustion error message!

Bug?

You can ā€œhackā€ the memory exhausted error by disabling the memory limit in either your php,ini, .htaccess, or even index.php file.

However, the root cause is some large information that is being passed to the quote. It is difficult to determine where that might be happening without first hand exposure to your installation.

1 Like

Maybe, just maybe youā€™re using a custom font? The data you have can be great to test a new version of invoiceplane.
First solve problems locally (docker will help you) and then deploy to your server.
I think that you are encountering these issues on your live server, correct?

Live server > Correct (My MAMP server on my Mac behaves different and is of no use to test there before)
Havenā€™t even touched fonts. Neither did I know there is something like a custom font.
No, everything is original as per installation. Havenā€™t touch any code or CSS, etc.,

What do you mean by that, what data?

I mean the database. The information in the database causes this error.
Since itā€™s live data itā€™s difficult to use in testing since then I will know information about your customers and thatā€™s something we need to look into avoiding :slight_smile:

Thanks for the ideas, Crafter, but Iā€™m rather for a global solution. I mean, there must be something that can be done, changing the original code so this wonā€™t happen. No really a point in having a function/module which wonā€™t work without hacking it. Am I wrong? :wink:

UnderGog, not sure what you mean with testing. The invoiceplane is setup live, on the server.

Perhaps I should take a step back and explain.

This is not necessarily an error. The out of memory error could be caused my many issues. Now. the memory limit is set as a default. Some sites will change the limit according to their own needs. This is part of your PHP installation and has nothing to do with CI.If you are working with large amounts of data from somewhere. this could occur.

Having said that, this error could also occur due to a bug, or badly written code. Without working with your actual data, if is difficult to know which. I am unable to replicate the error with my own data,

I suggest you get this to work by changing the limits.

Afterwards, work with the developers to find a global solution.

1 Like

@crafter, Iā€™m not working wiht large amount of data anywhere, nor is the data limit small. Itā€™s rather huge since I am on a VPS with a setup to cater for large portals (this is only an accounting software).
I am not engaging ā€œDevelopersā€ to look into and pay for something that shouldnā€™t be an issue in the first place.
Itā€™s now weeks since I reported this issue and I havenā€™t got time to wait 2 yeas to have an issue resolved.

Since you canā€™t replicate the issue and I canā€™t get ahead of it, it appears invoiceplane isnā€™t for me.

@Nobby_Whyas soon as you can replicate your problem in your development environment just let us know.
In that case you can start testing where your problem resides in the code.
As soon as you have done that feel free to make a pull-request, so the software can get updated.

Without steps to reproduce the problem cannot be resolved.
The solution is in the data that gets sent to the PDF generator.

  • test locally (your development environment)
  • fix locally (your development environment)
  • send in pull request as soon as you have fixed your problem.

Good luck

I can understand your frustration with the lack of a solution, but you will really have to do more to assist with resolving this issue.

Firstly, this issue is not widespread and you are the only person reporting this. As I explained earlier, I was unable to reproduce the error. This makes it impossible for me to work on any possible solutions. A request to provide your test data has been rejected by you as well, so we can only rely on data that we have, which, as I mentioned, is not producing the issue.

Secondly, understand that the issue is not happening inside Invoice Plane itself, but in a third party PDF library. It is quite possible that there is a bug within the library itself.

Thirdly, I have made a suggestion to change the memory limit, as a temporary work around, which you have rejected. Even your large VPS has configured limits. From your error, the PHP memory limit seems to be 32 M, which is very small compared to the limits set on my own server. You should work with your system administrator with this.

You need to understand that the development and support is done by volunteers. Like you, I am a business owner and use this software for my business. I have never earned a cent from providing support and code to IP, and lots of others active in this community is in the same boat. My contribution to the project is my time, skill and experiences on the application.

It could be that invoiceplane is not for you. However, your co-operation in helping us resolve this issue will go a long way for both you and the application itself that might help others too. There are a number of other ways you could help the developers debug and resolve this issue, if you are willing.

1 Like

Never said Iā€™m not willing, rather the opposite. What I said is, Iā€™m not a PHP developer so my expertise to help is limited. That said, Iā€™d be more than happy to contribute in any way.

With regards to the 32Mb limit, not true. I mentioned that my VPS is configured to cater for large portals. I had a realestate portal on it and created all sorts of (large) PHP files, without any problem. Not sure where that 32mb limits should stem from now.

But Iā€™ll have another look at.

That is great @Nobby_Why.

Unfortunately helping might involve getting your hands dirty with editing some files on your system.

My first suggestion would be to turn on the debugging on the file ipconfig.php. You are probably familiar with this file as you had to change it when installing IP. This will create log file entries in the ā€œapplications/logsā€ directory that might offer further information that might be useful.

  : 
# Having problems? Enable debug by changing the value to 'true' to enable advanced logging
ENABLE_DEBUG=true
       : 

You can also visit the slack channel where things are a bit more interactive. I am not always onlne on slack but can visit to assist if required.

1 Like

My apology, @crafter .

As told that Iā€™d look into the limit again and although global values on the server are set quite high, of course, cPanel sets its own values for every site hosted and since I still use this annoying cPanel, of course cPanel resets values to the standard minimum of the minimum (stupid).

Changed the values in the site own cPanel ini file and all good.

Again, my apology for overreacting. No excuse for that.