PHPJunkyard support forum

Script URL:
Version of script:
Hosting company:
URL of phpinfo.php:
URL of session_test.php:
What terms did you try when SEARCHING for a solution:

Write your message below:

Love this updated version. Thank-you!
I was wondering is there a way to have the current message box to be able to accept more characters. I found this part of the code in the index.php file: I tried to increase the rows="125" cols="260" to no avail. If at all possible I'm trying to set it around 9,000 characters. Any help would be greatly appreciated.
TIA

The message box will accept unlimited characters (the actual maximum http post size is limited by your server's settings). You can type in 9000 chars and it will accept them as long as your server settings accept such large posts, just a scroll bar will appear in the message box.

Your changing rows and cols didn't work because it's exaggerated and wasn't accepted by the browser. To make the box larger try leaving cols at 60 but changing rows to something like 30.

Thank-you Klemen.

Hi Klemen,

I don't know enough about php, databases, servers etc... Please don't get upset about this next question. (I'm trying to learn)

I did a test without changing any of the code.

When a customer 1st submits a ticket it will not accept over 13 rows of text. I've tried both ways of just numbers and actual 13 rows of solid text. (Same results).

On this test ticket when I reply to a customer or a customer replies once a ticket has been submitted, the system will accept more than 13 rows.

Question:
If it were my server settings, wouldn't the system not submit a message from the "Add Reply" if 13 rows were exceeded?


http://usetc.com/Tis/ticket.php
Ticket Id: 826U2LBHJT
---------------------------------------------------

Now I did find a work around for my purposes.

http://www.usetc.com/Dis/ticket.php

Ticket Id: NM6VH8SVT8

I changed the message code to:

Then created a custom field named "Body" with rows="12" cols="70"

The custom field I created will accept rows over what is deemed in the code the first time submitting a ticket.
------------------------------------------
Again I'm just trying to learn. Questions Please:

1) Why does the original code with only the "Message Box" not submit a ticket once the scroll bar is displayed, (rows exceeding what is in the code) but if a custom field is added, that custom field will submit a ticket if the rows exceed what is in the option code?

2) Why isn't there a problem with "Add Reply" when rows are exceeded? In both test instances whether the customer or admin was replying to a ticket I exceeded the rows deemed in the code and there wasn't a problem.

If it were my server settings, wouldn't I have problems with exceeding rows deemed in the code in the "custom field" and "add reply" message?

I'm just trying to make sense of it, I don't get it.

Thanks for taking a look....

P.S. I'm the first one to admit I can be dense as concrete so hang in there with me.

I had an idea; the problem could be a too long GET variable and thus Javascript not working properly in a browser.

In plain terms: go to the admin panel, set "Suggest KB articles:" to "NO", save changes, close all browser windows and see if it works then.

Just ran a few tests, here's what I found:

1. disabling the Suggest articles should indeed solve the problem (server returns a 406 error but in the end the browser doesn't continue because Javascript fails)

2. it's not a browser problem, it must be a server (security) setting which prevents long GET variables in the request (looks like the limit is a bit over 500 chars per variable).

Would you mind uploading phpinfo.php file to your server (get it at viewtopic.php?t=138 ) and posting a link to it here (or to me directly in a private message), so I can get an insight of how your PHP is setup?

Hi Klemen,

Your suggestion of "Suggest KB articles:" to "NO" worked like a charm.

http://usetc.com/Tis/ticket.php
Ticket ID: SYSWM4YTDV

Thank-you for taking the time to look at this for me. I sent the requested link via pm.

I do apologize for not having this loaded before posting. I had read the sticky before from the first Hesk system, and thought my memory of it had served me well. I know better and wasn't thinking. Besides the fact that the sticky could have been updated, I do believe it's safe to say my memory isn't what it used to be.


Thank-you again for all of your hard work and patience.

Thanks for sending me the phpinfo. I was correct, the Suhosin extension is the one blocking requests with GET variables longer than 512 bytes. I will see if I can make the "Suggest articles" sent using the POST method instead in the new version, that should prevent Suhosin making troubles.

Glad to see it's working fine now.