Extend Character Count for Subject Line

[jawad96]

Hi all,

I'm on the latest 2.0.9 version. I've searched around and found a couple of threads related to this, however found them slightly confusing - some required database change and edit in the theme or something. Currently I am using a custom theme.

I was wondering how I can include more characters in the subject line when creating a thread as it is currently limited to 81 I think? This should reflect in all the posts below it and when viewing it in the board.

Any mods available or anything?

Thanks!

[Arantor]

They do generally require changing the database structure itself to make it work depending on language used.

Also not recommended for performance reasons.

[Kindred]

As Arantor says -- this would require changing the database, changing the template(s) and possible changing some of the source file(s).

*AND* is not recommended...

[Arantor]

Oh, it definitely requires source changes.

[jawad96]

Despite these negative effects, should I wish to go down the route, any advice on doing this? 

[Arantor]

When you have the project manager and one of the world's most foremost experts on SMF (and so modest ) telling you it's a bad idea... you pretty much would need to have a fairly exceptional reason to do it, not to mention providing more details about the circumstances, configuration and whatnot that you're using...

[margarett]

Not trying to do the "good cop" thing here but I don't see why not give it away.
In fact, this was debated and solutions given in the past (which, as always happens to me, I can't find off-hand )

The "subject" field in the table is a VARCHAR(255). Depending on the language you're using, each character can actually be *some* characters long, thus a safe limit of 1/3 of the field size exists.
To change the column type to a different type (bigger) is actually a bad ideas as you are being told. Yet, if you only use English and your members don't use strange characters, I don't see why not

Apart, of course, from breaking your layout completely (see attached image)

In short: edit Post.template.php and increase the field's "maxsize" property. Edit Post.php and search for instances of "$smcFunc['strlen']", there you'll see a comparison of the subject with 100. Increase 100 to the number you want (don't go above 255 in any circumstance and even 200 should cause you problems with strange characters...)

Keep a copy of your original files, you will want to have them back

[Arantor]

The "subject" field in the table is a VARCHAR(255). Depending on the language you're using, each character can actually be *some* characters long, thus a safe limit of 1/3 of the field size exists.

Here's the principle problem.

Going above VARCHAR(255) has some very interesting characteristics. But also, some characters take *more* than three bytes for this to be a thing. So 255 is a generally - but not totally - safe limit and it's quite possible to overflow beyond 255 chars even without extending beyond 80 "characters".

The reason this is problematic is because it's when it's going to cross the byte threshold for the internalised length handling in MySQL and some versions do not handle this properly.

[jawad96]

Thank you for your assistance. I couldn't get it to work though, however I saw this:

It is currently set to a max of 80.  I believe your can change it in /Themes/default/MessageIndex.template.php.

Code: [Select]
<input type="text" name="subject" value="\' + subject + \'" size="60" style="width: 99%;"  maxlength="80"

Change maxlength="80" to whatever value you want.

Also you will need to change the same information in /Themes/default/Display.template.php

Code: [Select]
<input type="text" name="subject" value="%subject%" size="60" style="width: 99%;"  maxlength="80"


I was wondering if this does any damage and has the same end result? It has worked for me

Thanks

[jawad96]

Actually, I'm not even sure what it does - it seems whenever I have reached to the end of the subject bar, it doesn't let me type anymore. However, I can go back to the beginning and start writing behind what I had written and it will type more characters?

[Kindred]

Changing it in the template will not result in the desired change.   We've alreayd stated that it will involve template files, source files and database

You have not answered WHY you think you need to do this...

[Vince S]

I am buying in here as I would really like to see this happen, if it is a possible practical reality - with full deference to the points Arantor makes as, when all is said and done, we CAN live with the restriction (as we are). But it is a regular source of frustration to me and I would rather not have to.

Starting with some facts. We ACTUALLY have 76 characters to use as a topic title as 4 are reserved for "Re: " - check the maxxed out title of this post. That is an absolute pain in the ring for me as I am often arranging physical events and want the topic title to tell people all the critical data, basically name of the event, its location, day & date/s, departure point and time. It is a rare event indeed that this fits in the topic header without some crunching.

The other aspect of this general topic is that we have been using widescreens for nearly a decade now and it is just wasted screen space having a topic length lucky to be 1/4 the width of it. For my particular use it would be sooo nice to have 150 characters. But equally, on the screen width logic, 256 characters would be a pretty tidy compromise for typical theme layouts. the issue raised of "some characters are multiple characters long" should be a language pack issue. For Unicode they are ONE character long, so let's deal with that - even if it is a user chosen field length choice that they take the risk on truncations

With long topics the practical reality option to get in effect tweeting happening via a topic response being the next level back from a Quick Reply.

Increasing topic length is a natural progression issue that should just drop on the radar in a normal development cycle as it is an idea that is well past its time but hasn't happened. If there are real impediments to that going ahead then fair enough, it shouldn't get e guernsey. I am well aware of the competing issues that could arise, but really - is it that hard? (um, "yes" is a perfectly acceptable answer, if true!)

[Kindred]

Well.., I hear you... But I disagree...

[Arantor]

But equally, on the screen width logic, 256 characters would be a pretty tidy compromise for typical theme layouts

Actually it wouldn't from a technical standpoint as already explained. I will also point out a growing trend towards mobile use where shorter is more advisable for the obvious reason.

the issue raised of "some characters are multiple characters long" should be a language pack issue. For Unicode they are ONE character long

No, they're not. The problem is not strictly characters in this situation. It is partially about actual byte count too.

And that's even before we get anywhere near the thorny issue of 'the various exciting characters that get transcoded to entity form'.

Increasing topic length is a natural progression issue that should just drop on the radar in a normal development cycle

No, it isn't.

[Vince S]

OK, I "get" and accept those points. What about this, is it something I could do too (using 150 in lieu of 80) or is it setting up for a train wreck somewhere?:

It is currently set to a max of 80.  I believe your can change it in /Themes/default/MessageIndex.template.php.

Code: [Select]
<input type="text" name="subject" value="\' + subject + \'" size="60" style="width: 99%;"  maxlength="80"

Change maxlength="80" to whatever value you want.

Also you will need to change the same information in /Themes/default/Display.template.php

Code: [Select]
<input type="text" name="subject" value="%subject%" size="60" style="width: 99%;"  maxlength="80"

I was wondering if this does any damage and has the same end result? It has worked for me

[Arantor]

As has already been said in this thread, literally just changing the template will not solve the issue; the other limits elsewhere will still be applied.

[Vince S]

So this is bs:?

It has worked for me

Perhaps Jawad would be kind enough to elaborate on this comment - perhaps even send a link to a topic with a long subject and dummy or real posts showing it was preserved....?

[Arantor]

No, it's just that it doesn't work quite how you might imagine.

The limit in the browser is 80 characters. There is another check elsewhere in the source that extends it to 100 characters to allow for certain non-Unicode expansions. I suspect jawad has managed to do something like 90 characters which doesn't require changing the other checks.

Additionally, the other checks treat encoded entities less like multi-characters and more like their actual characters so 100 'characters' as $smcFunc['strlen'] calculcates may not be the 100 'characters' you were thinking of.

It's actually ridiculously complicated in terms of code path.

[jawad96]

Hi again,

Sorry Vince, I commented immediately after that

Actually, I'm not even sure what it does

It looked like it had no effect..? Not sure.

The reason I need more characters in the subject line is so I can add more information. Majority of the times 80 characters is too short, so if there was an easy method to change it I was planning to do so. But looks like the unanimous vote to do this from a technical stance, is a big no.

I'm sure there are other users who may like to see this implemented as I have seen other threads re this, however none had any solution which were simple step by step instructions or actually even worked.

[Kindred]

jawad96,

why is 80 characters too short?   What specifically are you putting in to the title?
Vince has his edge case where he wants to put all of the details about an event into the title (which I would argue is silly -- you put the event title into the title and the details go into the body)

so, what case do you have for needing information that takes more than 80 characters? What information are you trying to cram in there?

[margarett]

This
http://stackoverflow.com/questions/7755629/varchar255-vs-tinytext-tinyblob-and-varchar65535-vs-blob-text
Kinda sums it up.

In true honesty, I don't see why can't it just be changed to VARCHAR(something) and do the edits I mentioned above to Post.template.php and Post.php (or other affected files)... But I'm far from a SQL expert
Yes, there's an implicit overhead and, attached to it, performance penalty. In most setups out there, I seriously doubt this would be noticeable...

[Vince S]

oh, OK jawad - I took that as a "process" comment; ie you didn't know what it did to get you the "worked for me" outcome.

So dead in the water I guess as it kinda has the death stare from anyone that has a proper grasp of what is involved in doing what we dweebs think looks like a snack and would be damn handy. That is why we are dweebs, we don't know!

And this dweeb is an edge dweller to boot - I have always loved the maxim that "if you're not living on the edge you're taking up too much room" so it is pretty comfortable out here.

And, from the edge, I would like to lob this grenade back into the middle, read the few posts following this one and see what y'all reckon:

http://www.simplemachines.org/community/index.php?topic=359405.msg2450415#msg2450415

Sounds like there might be an answer, at least from RC2 days - Waddya reckon punks / punkettes, anyone keen enough to try?

[jawad96]

Hi Kindred,

It is going to be usually for similar thread names from the Warrior Forum, i.e

[Investors Pay Attention] Real Estate Millionaire Shows You The Secrets To UNLIMITED Cash Buyers!

Clickbank officially recommend us Warrior App Maker! Just One Click To Get Huge Profits From Pytch!

Thanks

[margarett]

And, from the edge, I would like to lob this grenade back into the middle, read the few posts following this one and see what y'all reckon:
http://www.simplemachines.org/community/index.php?topic=359405.msg2450415#msg2450415
Sounds like there might be an answer, at least from RC2 days - Waddya reckon punks / punkettes, anyone keen enough to try?

Which is, if you notice, pretty much the same I said some posts ago

[Vince S]

yep, I did notice. I expected a bit of well deserved basking in the warm afterglow of recreated brilliance. Good to see it.

But it is the guys with the big messy code axes that can despatch an afterglow with the haste of a well streamed demon's lamp-light o'er that dreamy shadow I am waiting to hear from.....

[margarett]

LOL

@jawad96: that's a 2-lines subject that you will *NOT* be able to achieve...

[Vince S]

I think jawad was suggesting two examples of topics - which MS Word assures me are 97 and 99 characters long respectively.

With the aid of MS Word reality checking I have revised my own desires down from 150; 120 would be beautiful overkill and 100 would be just fine, even still losing the 4 "RE: " characters.

[Steve]

@jawad96: that's a 2-lines subject that you will *NOT* be able to achieve...

While not a two-line topic wouldn't this essentially achieve the same result?

http://custom.simplemachines.org/mods/index.php?mod=3012

[margarett]

Nice catch. I'm not sure if the description is "searcheable" but it could really solve the OP's issue

[Steve]

Thanks!

I haven't tested it yet as it wants a lot of manual edits on my forum and I've been too lazy to do it.

[Arantor]

In true honesty, I don't see why can't it just be changed to VARCHAR(something)

It already is a VARCHAR, it used to be TINYTEXT but that screwed with performance even worse.

*shrug* I thought I already explained the details here, that's you're dealing with changes to templates AND source AND database and that the changes to the database will have performance quirks that will slow everything down.

And the reason it is varchar(255) is related to how MySQL internally counts the size of fields (which is more to do with bytes than characters)

But I'm pretty used to not being listened to at this point. Fairly used to explaining that there are reasons for things being so and being ignored by people who are fairly sure they know better than I do. Makes me wonder why I keep hanging around here, really.

[margarett]

Don't do that, you know it's not true Not in my case, at least

Obviously I didn't meant for that change to be core. But if the users in need accept that they will get a performance penalty, it might be a possibility, just saying
Bottom line is: it's not recommended, but your forum will not explode

[Arantor]

For some value of 'not explode' anyway.

[Vince S]

The axe falleth ...

I thought I already explained the details here, that's you're dealing with changes to templates AND source AND database and that the changes to the database will have performance quirks that will slow everything down.

but oh - the wretchedness ....

I'm pretty used to not being listened to at this point. Fairly used to explaining that there are reasons for things being so and being ignored by people who are fairly sure they know better than I do. Makes me wonder why I keep hanging around here, really.

For those of us not all hung up in the Shakespearean futility of it all, any chance of informing we mere mortals in a way we can make sensible decisions?

We all agree this is not a life and death issue. Hara-Kiri is not on the table. In fact it is so unimportant in the scheme of things that we are unlikely to even crack open a pack of band-aids, let alone get the Savlon out. So no legends need to fall. The sword can remain in its scabbard and un-dived on, and absolutely no puppies are to be harmed. Egos shouldn't even blush, let alone contemplate picking up a bruise or taking on a battered persona for the benefit of their long-suffering owners.

So, if one goes and does the things intimated by the as-yet-unglowed margarett and laid out in more detail by those of the interminable era of pondering the intimacies of RC2, what happens? I mean what exactly? or at least the loose version of "exactly".

From this discussion thread, it seems adopting a 100 character limit might be a no-brainer (but check how many brains we have here...!), and the RC2 era discussion suggests even bigger limits would be OK. So, the first important question is:

1) Is increasing character length likely to actually break something? To me, "break" means things like Announce Topic doesn't work as expected, or important errors are generated or infinite loops happen to be timed out of. "Not explode" is a manifestly inadequate way to describe this outcome, unless this is exactly what it means....?

then

2) What does "performance hit" mean? Are we talking 0.03secs larger processing time? or a 0.1 sec increase to page loading? or a 0.001sec calc time increase multiplied by 20,000 calcs per second?

Do tell. Thank you

[Steve]

[OT]Dude, if you're not a writer, you missed your calling.[/OT]

[margarett]

1) not likely, but possible. Some layout issues and some possible overlooked functions (which I can't remember one right now )

2) The link I posted from SO should more or less clear that. If you keep VARCHAR 255, there are no differences (sou you will be just changing the code I pointed out. You might loose some characters if using strange characters or something like that (but thats's also unlikely if you keep your distance from the 255 limit )
If you increase the VARCHAR size, you earn a byte of overhead (for the size) plus the obvious increase in the data size. For other technicalities, going to a TEXT field type is slower in access. Not more data, a slower way to access it. I have no idea how to quantify that.

[Arantor]

Except increasing beyond varchar 255 does not behave consistently depending on character set, collation and other server configuration details with the way SMF uses it. And there are other hidden gotchas in MySQL around row size too.

And in fact, the reason TEXT is slow (forces filesort) can become a thing in varchar cases too if you go beyond 255 because of how MySQL determines whether or not to perform its own sorting.

Can I give you metrics? No, because it's instance specific. But consider the fact of where the subject is used, in both retrieved and sorted cases, and that there is guaranteed to be an increase time everywhere...

Then again, given the number of other performance bottlenecks I found over the years, *shrug*