I don't know if anyone notices this. If your user information penal on the left is longer than the content of your post plus your signature on the right, the table stretch will go with the content of the post, which causes an overflow of the user penal out of the containing cell of the table. The current post is an example. See the flag on the left is outside the table?
windyhawk said:
I don't know if anyone notices this. If your user information penal on the left is longer than the content of your post plus your signature on the right, the table stretch will go with the content of the post, which causes an overflow of the user penal out of the containing cell of the table. The current post is an example. See the flag on the left is outside the table?
Click to expand...
Click to collapse
Oh yeah, I've noticed aswell with some mods with long titles, donations, carrier, location etc... it will overlap to the person belows post
windyhawk said:
I don't know if anyone notices this. If your user information penal on the left is longer than the content of your post plus your signature on the right, the table stretch will go with the content of the post, which causes an overflow of the user penal out of the containing cell of the table. The current post is an example. See the flag on the left is outside the table?
Click to expand...
Click to collapse
Yep, known issue I'm afraid
Related
To moderators,
Please, please, please ... reduce the size allowed to signatures
Some users have endless signatures, with many graphics, pictures ... it makes threads difficult to read
Ok, I use AdBlock Plus to remove many, but that´s an endless fight
Cheers
ChefChaudart said:
To moderators,
Please, please, please ... reduce the size allowed to signatures
Some users have endless signatures, with many graphics, pictures ... it makes threads difficult to read
Ok, I use AdBlock Plus to remove many, but that´s an endless fight
Cheers
Click to expand...
Click to collapse
Click the link in my sig please would you say those signatures there are too big , I will happily resize them if they are , their resolution is 600*200 and btw. Moderators will ask members with over sized sigs to resize them
ChefChaudart said:
To moderators,
Please, please, please ... reduce the size allowed to signatures
Some users have endless signatures, with many graphics, pictures ... it makes threads difficult to read
Ok, I use AdBlock Plus to remove many, but that´s an endless fight
Cheers
Click to expand...
Click to collapse
Size of the signature is already greatly restricted by the number of characters in it.
If someone puts care into their signature, the number of characters could be much greater, but take up less screen space. Just changing the color counts as characters.
The total vertical pixels of all images in signatures could could have a limit, which would prevent the signatures that are blatantly too large.
Often times using more characters can actually reduce the total screen space taken up by the signature.
For instance posting a raw URL takes up more screen space than embedding it as something like
using { and } in place of [ and ]
{URL=the raw URL}link{/URL}
By doing this, many links can all appear on one line.
Rather than modifying the site to automatically restrict this, I think enforcement would probably be better done by making a site policy to not have obscenely large signatures.
If someone does, and a complaint is made, the user would be warned and the signature would be editted or removed by a mod with a message to the user.
That would be similar to how an inappropriate post by a user would be handled.
The mods already do an excellent job at handling those issues.
MacaronyMax said:
Click the link in my sig please would you say those signatures there are too big , I will happily resize them if they are , their resolution is 600*200 and btw. Moderators will ask members with over sized sigs to resize them
Click to expand...
Click to collapse
Yeah, our policy is to not restrict the size of signatures, unless one of the mods finds it to be too big. At that point, we'll ask the user to trim it!
Well, I guess, another option would be a user option that allows to display or not members signatures
ChefChaudart said:
Well, I guess, another option would be a user option that allows to display or not members signatures
Click to expand...
Click to collapse
You mean this? (in your usercp)
Visible Post Elements
You have the option to show or hide various elements of messages, which may be of use to users on slow internet connections, or who want to remove extraneous clutter from posts.
Show Signatures
Show Avatars
Show Images (including attached images and images in code)
[/QUOTE]Built into vBulletin long ago
Click to expand...
Click to collapse
MordyT said:
You mean this? (in your usercp)
Built into vBulletin long ago
Click to expand...
Click to collapse
Oups
Yes What a (new) pleasure to read XDA !!!
annoying mod signatures!
Yes, these large signatures, especially by moderators with constant moving colors and images are annoying and distract from the content/purpose of each thread. It is possible to turn off signatures. Go to User CP>Edit Options>Thread display Options and you can turn them off. But in reality, mods should not be allowed to have such large annoying signatures advertising their wares.
JVH3 said:
Size of the signature is already greatly restricted by the number of characters in it.
If someone puts care into their signature, the number of characters could be much greater, but take up less screen space. Just changing the color counts as characters.
The total vertical pixels of all images in signatures could could have a limit, which would prevent the signatures that are blatantly too large.
Often times using more characters can actually reduce the total screen space taken up by the signature.
For instance posting a raw URL takes up more screen space than embedding it as something like
using { and } in place of [ and ]
{URL=the raw URL}link{/URL}
By doing this, many links can all appear on one line.
Rather than modifying the site to automatically restrict this, I think enforcement would probably be better done by making a site policy to not have obscenely large signatures.
If someone does, and a complaint is made, the user would be warned and the signature would be editted or removed by a mod with a message to the user.
That would be similar to how an inappropriate post by a user would be handled.
The mods already do an excellent job at handling those issues.
Click to expand...
Click to collapse
I agree with your points. Would you mind reducing the size of your signature?
me even too dont like big signaturs cause problems wid loading of page wen ur net sucks :-/
If you see someone with a ridiculously large signature image, report them using the "report post" button at the top right of one of their posts
hi,
when i have an avatar in my profile my country flag exceeds the permitted display space on the left side of a post. how can i fix this ?
mjehan said:
hi,
when i have an avatar in my profile my country flag exceeds the permitted display space on the left side of a post. how can i fix this ?
Click to expand...
Click to collapse
If you make a longer post, it will be fine. It's a template bug.
This hasn't been fixed yet?
I had to put some blank characters in my signature,
(this is a workaround for people who mostly make short posts)
Hi,
I use a lot the small arrow to the left of each subscribed thread to jump to the 1st unread post.
Most of the time it works correctly, but from time to time it will show me the start of the previous page and be left at the top, since the URL anchor is not present on that page.
The original link will be something like ".../showthread.php?goto=newpost&t=nnnnnn", which later resolves to ".../showthread.php?p=mmmmmm#postmmmmmm".
The problem is that "showthread.php", when processing with the "p=..." argument, sometimes fails and presents the previous page than it should. If I were to replace "p=mmmm" by "t=nnnn&page=yyy", leaving the anchor, it will work.
Based on some experiments, my guess is that that php, when processing in the p= mode, fails to handle the edge case where post_count mod page_length is 0. I tried it with multiple page sizes, and for the case I was trying it (before I read the post and now need to wait for another case like this), the post was a multiple of 10, 20, 30 and 40 but not 50. So, only after changing the page length to all values to confirm it was failing, and finally to 50, did it work properly.
I normally use 20 posts per page so the chances of the last unread being a multiple of that are pretty slim, but those using 10/page are likely to experience this more often.
FIX: The formula for the page count "page_number=((post_count - 1) DIV page_length) + 1" or equivalent. Currently there's an offset of 1 that probably nobody ever complained about (at least I didn't find any post mentioning this).
This occurs regardless of the selected theme, and also on the XDA app (the server side is probably the same, or shares that part of the code).
EDIT: It appears that the conditions are not that simple. Sometimes, *after* the situation has been triggered (or so it seems), refresh of the subscribed threads view won't solve it immediately. Even if my next unread post is, say, the 3rd on the next page, I'll still be taken to the top of the previous page and therefore not land on the right post (correct anchor, but wrong page). Something to do with caching, perhaps?
Tungstwenty said:
Hi,
I use a lot the small arrow to the left of each subscribed thread to jump to the 1st unread post.
Most of the time it works correctly, but from time to time it will show me the start of the previous page and be left at the top, since the URL anchor is not present on that page.
The original link will be something like ".../showthread.php?goto=newpost&t=nnnnnn", which later resolves to ".../showthread.php?p=mmmmmm#postmmmmmm".
The problem is that "showthread.php", when processing with the "p=..." argument, sometimes fails and presents the previous page than it should. If I were to replace "p=mmmm" by "t=nnnn&page=yyy", leaving the anchor, it will work.
Based on some experiments, my guess is that that php, when processing in the p= mode, fails to handle the edge case where post_count mod page_length is 0. I tried it with multiple page sizes, and for the case I was trying it (before I read the post and now need to wait for another case like this), the post was a multiple of 10, 20, 30 and 40 but not 50. So, only after changing the page length to all values to confirm it was failing, and finally to 50, did it work properly.
I normally use 20 posts per page so the chances of the last unread being a multiple of that are pretty slim, but those using 10/page are likely to experience this more often.
FIX: The formula for the page count "page_number=((post_count - 1) DIV page_length) + 1" or equivalent. Currently there's an offset of 1 that probably nobody ever complained about (at least I didn't find any post mentioning this).
This occurs regardless of the selected theme, and also on the XDA app (the server side is probably the same, or shares that part of the code).
EDIT: It appears that the conditions are not that simple. Sometimes, *after* the situation has been triggered (or so it seems), refresh of the subscribed threads view won't solve it immediately. Even if my next unread post is, say, the 3rd on the next page, I'll still be taken to the top of the previous page and therefore not land on the right post (correct anchor, but wrong page). Something to do with caching, perhaps?
Click to expand...
Click to collapse
+1
I have recognized this radom issue from time to time in xda app and on my PC.
The last few times when the jump to first unread post failed (jumped to the wrong post), there was a new page in the thread.
And instead of jumping to the first post on the last page of the thread, this action jumped to the first post on the second-last page of the thread (which was the last page before the new post was added).
But I also recognized the issue, that the jump to first unread post lead me to the last post of the thread, even if I have not read one or two posts before this last post.
The strange thing is that this function works correct most of the time ... only sometimes it misbehaves.
Same problem here! Will anyone fix this?
BUMP! When will this be fixed?
kevindd992002 said:
BUMP! When will this be fixed?
Click to expand...
Click to collapse
Bump again, still not fixed and very annoying.
I'm having issues recreating this problem. We have a query that is similar to the one you said but a little bit different, also there are also factors that may be playing into consideration such as if a post was deleted and I'm wondering if that might be returning the incorrect offset. Can you give me steps to reproduce this again? Is it only threads where you have an unread post count = the number of posts per page?
bitpushr said:
Can you give me steps to reproduce this again? Is it only threads where you have an unread post count = the number of posts per page?
Click to expand...
Click to collapse
For me, using the 2010 interface, anytime on any thread, when I use the shortcut sent to me via an email sent by the XDA website, or use the jump to first unread button it will normally go to the top of the page of the last page I read. Then the next several times I use a shortcut to the thread it goes to that place even when more pages are used and I've read through them all. Then after several visits it will reset and go to the top of the last page I visited again.
I use 50 posts per page. And using the 2010 interface, it NEVER goes to the first unread post whether I use a shortcut from an email sent by XDA or using the button on the top of the page.
Thanks for the help.
Lately I haven't come across this issue, or at least I haven't noticed. I'm not sure if it's because the frequency I check the forum is quite lower, if something was fixed / updated on the server, if it's because I'm now using the 2013 Beta theme instead of the 2013 Beta - 1024 I used before, or something else.
I'll keep an eye out, though, and post here if I do come across this problem again with as much info I can infer from the situation.
Tungstwenty said:
Hi,
I use a lot the small arrow to the left of each subscribed thread to jump to the 1st unread post.
Most of the time it works correctly, but from time to time it will show me the start of the previous page and be left at the top, since the URL anchor is not present on that page.
The original link will be something like ".../showthread.php?goto=newpost&t=nnnnnn", which later resolves to ".../showthread.php?p=mmmmmm#postmmmmmm".
The problem is that "showthread.php", when processing with the "p=..." argument, sometimes fails and presents the previous page than it should. If I were to replace "p=mmmm" by "t=nnnn&page=yyy", leaving the anchor, it will work.
Based on some experiments, my guess is that that php, when processing in the p= mode, fails to handle the edge case where post_count mod page_length is 0. I tried it with multiple page sizes, and for the case I was trying it (before I read the post and now need to wait for another case like this), the post was a multiple of 10, 20, 30 and 40 but not 50. So, only after changing the page length to all values to confirm it was failing, and finally to 50, did it work properly.
I normally use 20 posts per page so the chances of the last unread being a multiple of that are pretty slim, but those using 10/page are likely to experience this more often.
FIX: The formula for the page count "page_number=((post_count - 1) DIV page_length) + 1" or equivalent. Currently there's an offset of 1 that probably nobody ever complained about (at least I didn't find any post mentioning this).
This occurs regardless of the selected theme, and also on the XDA app (the server side is probably the same, or shares that part of the code).
EDIT: It appears that the conditions are not that simple. Sometimes, *after* the situation has been triggered (or so it seems), refresh of the subscribed threads view won't solve it immediately. Even if my next unread post is, say, the 3rd on the next page, I'll still be taken to the top of the previous page and therefore not land on the right post (correct anchor, but wrong page). Something to do with caching, perhaps?
Click to expand...
Click to collapse
BUMP! When will this be fixed?
Example the rom name K50a40_S112_150610_ROW_TO_K50a40_S114_150618_ROW_W CDE.zip
Forum setup long word to 50 characters.
123456789012345678901234567890123456789012345678901234567890
123456789012345678901234567890123456789012345678901234567890
Yep, this has always been the case, for as long as I can remember. Not sure if the limitation is vBulletin, SQL or something else?
We've encountered the same in our forum & turned out to be vBulletin bug.
@natong
It would be better if you put all those long filenames inside CODE tag.
Titokhan said:
We've encountered the same in our forum & turned out to be vBulletin bug.
@natong
It would be better if you put all those long filenames inside CODE tag.
Click to expand...
Click to collapse
Could you adjust more width and unlimit height for CODE tag ?
Currently it limit to display only 10-20 lines height with scrollbar.
@natong
Sorry, I can't help you with that. But its indeed better to get a CODE window without any horizontal scrollbar.
I known how to post long word now.
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
In this post:
http://forum.xda-developers.com/and...ide-list-installed-apps-dont-support-t3509547
There's a space "platfo rm" where I actually wrote "platform".
Please fix this!
It's a vBulletin thing. After a certain amount of characters, a space gets added. There's no way around this, unless you use code tags or something similar.
Thanks, solved using CODE tags.