1 (edited by MattF 2008-04-01 03:36)

Topic: pun_user question/advice

Are there any normal circumstances that can lead to the $pun_user array not being set? Having a problem with one of the search scripts, (not core), which is clapping out due to the pun_user array not being defined. The common.php include is at the top of the file, as normal, and the script works fine until it's specifically called with a set of id's for multiple page listings. I'll honestly be damned if I can see where the problem lay, however. big_smile It appears when the $_GET['dsid'] array is set, on the second+ page of a search. The script itself is here:


2 (edited by MattF 2008-03-31 18:18)

Re: pun_user question/advice

Just thought to check the SQL logs. big_smile It's the new get_current_url function combined with the online table which is causing the problem. The URI is too long to go in the prev_url column. (The error message wasn't displaying).

Edit: Just whilst on the subject, would there be a better way to supply the id's to the script other than in the pagination links?

Re: pun_user question/advice

Is this with 1.3?


Re: pun_user question/advice

I backported the prev_url setup to 1.2*, but it is with the same function & column setup as 1.3, in that regard. (I'll just double check to make sure I haven't made any changes to the basic premise, though). The prev_url column is varchar(255). A pagination link or suchlike with more than that length fails to insert due to the 255 max setting.

5 (edited by MattF 2008-03-31 18:52)

Re: pun_user question/advice

Just checked. The get_current_url() function is unaltered from how it is in 1.3, (other than removing the hooks, obviously), big_smile and I put the same varchar(255) setting on the column, so it may be worthwhile instituting a length check/strip on the URI before it's returned by the function, or removing the 255 characters limitation on the column.

Re: pun_user question/advice

Oh, I bet I know what happened: you have strict mode enabled so that query failed.
I'll look into it, thanks smile


Re: pun_user question/advice

I'm on PgSQL. big_smile Not sure if it's implemented the same way as MySQL.

Btw, the lack of an error message for the db error was a self inflicted coding injury. big_smile

Re: pun_user question/advice

Well, same idea tongue


Re: pun_user question/advice

big_smile big_smile

Just whilst on the subject, btw, would I be best setting the character limit to something like 1000, or just removing the column limit altogether? Or, would I be better off stripping the URI down to length if it exceeds?

Re: pun_user question/advice

There isn't a way to remove the limit altogether, as far as I know: I don't know PostgreSQL well enough to say for certain. You could set it to a TEXT column (or the PostgreSQL equivalent), that would likely be more than enough. And snipping the URL has the potential to break things.
We'll have to see what the fix is for 1.3, since the online table in MySQL is a HEAP table and we can't just go around adding TEXT columns there.

11 (edited by MattF 2008-03-31 22:27)

Re: pun_user question/advice

I believe it works the opposite way round with this one. The limit has to be implicitly specified, otherwise there is no limit on the length of input, by default. http://www.postgresql.org/docs/8.2/stat … acter.html

Re: pun_user question/advice

Well, there sort of is. From that page:

In any case, the longest possible character string that can be stored is about 1 GB

In any case, you're simply setting it to text, as I said before tongue
That likely won't be the solution those, since, as I said, we can't just do that in MySQL for various reasons.


Re: pun_user question/advice

My apologies. smile I wasn't trying to suggest how to do the MySQL side of things. I was merely trying to provide info for PgSQL. smile

Just on a slight sidenote, might I make one request/suggestion? I haven't gone through the 1.3 code to any degree, so don't know if it's applied later, but it may be worthwhile doing a str_replace for the ampersand to it's numeric entity in the get_current_url function before it's returned. Might save someone a bit of head scratching if they switch to XHTML1.1. smile

Re: pun_user question/advice

No problem, don't worry about it smile

With regard to your suggestion, it's good but it then makes things more difficult for uses of the URL where you don't want & (I don't know what the numeric entity is offhand). For example, redirecting to that URL via a 301/302 header. Also, it means storing more characters in the database. It's simpler to encode it when necessary.


Re: pun_user question/advice

Good point. I hadn't considered redirects.