-
I noticed something odd... On some pages, sometimes, the 'rev 1873' mention in the footer just doesn't show up.
This is in any browser (I think), Warm (probably all other skins too). Last reproduced on the Post page (i.e. where I am right now), usually refreshing the page will fix it. At one point I refreshed again and it disappeared again (after being there the last time). All subsequent (20+) refreshes had the rev number.
So I'd say this is very, very random, but if the plugin executing on every page is critical, it might be a show-stopper...
Sorry I can't help more. Just try it a couple of minutes and tell me if you can reproduce!
-
I'm sorry I can't reproduce this.. I tried with different skins, different topics/boards but I always see the rev..
-
Just reproduced on refresh #3 of this very page. Using Safari 5.1 on regular Display page (not Post page.)
And again after posting this... Three refreshes in a row! Refresh #4 had the rev number, and refresh #5 didn't.
I'll just stop here, I won't spend the day reloading :P
-
I refreshed 6 times, nothing :P
-
Anyone else..?
Posted: January 25th, 2013, 12:01 PM
:edit: Had rev number on reading this page. Quick replied. Page refreshed with my post, and with no rev in it. Can you check what it does after posting..?
:edit: Did another quick reply, Wedge didn't hide it this time though.
:edit: It hid it after I pressed Merge Posts :P
-
That is truly strange. But it sounds to me more like it's a bug of the plugin than of execution as such. Need to double check - but I wasn't able to get it to misbehave myself locally when I wrote it.
Posted: January 25th, 2013, 02:19 PM
Wait... actually... I can imagine one case where it might - if it ever has to play switcheroo on languages, which it can do under certain circumstances of merging. The plugin is a bit cheeky, it just fudges the language strings.
-
Merging what..? Posts? As I was saying, this happens from time to time, just by refreshing a page...
I'm at a loss too, though. I've never, ever seen the Skin Selector disappear for instance. Maybe it's the exact hook that's to blame..?
-
Not merging, moving. The move topics stuff does a strange switch of languages.
I still haven't seen it fail yet...
-
Try to switch to French.
It seems to happen only in French, actually... That may be a clue?
-
Only seems to happen on topic pages after a refresh with the French language being used.
-
After switching languages and browsing around, it happened to me the grand total of once where it didn't show up.
That would imply that under some set of circumstances, the hook isn't being called for some reason, but it's not clear why or why not that might be the case.
-
As I said, it also happens to me on Post pages... Not only Display. But it's true that I haven't been able to reproduce it anywhere else (although I haven't tested much.)
Last time I tried on a topic page, I got it to 'omit' the rev plugin *four* times in a row. Then it showed it twice, then hid it again... See what I mean.
I think it should be fixed. There's no telling whether or not another plugin will go through the same hassles. Maybe it's due to the hook being loaded too soon...?
So... Display.php + hook in loadTheme() + French language =...?
-
It's not Display.php, loadTheme is called long before Display.php even loads.
It means loadTheme is ending earlier than expected - and if so that would imply it is originally an SMF bug ;)
-
Okay, I've managed to work it out.
It's a Wedge bug, all I can say ;)
Also: the plugin is always executed, even if it doesn't show up.
It's due to the way languages are loaded: English first, then French second... Sometimes it'll execute the plugin on English, then rewrite with the French version, and thus the rev number doesn't show up. It has to execute on the second run...
Posted: January 28th, 2013, 06:49 PM
Hmm, nope, sorry it's always applied to the French file... I misread the string. So -> English loaded -> French loaded -> plugin executed -> at this point it's all fine -> then the French language is loaded again..?!
If you'll look at the admin log below the page, here's the loading order:
index.english (default), index.french (default), index.english (default), index.french (default),
So, plugin gets executed in the middle of these. Not at the end though. And I'm not sure why languages are loaded twice..? Isn't this something we worked on fixing at some point?
Posted: January 28th, 2013, 06:51 PM
We have to find out why loadTheme() is called twice, to begin with.
Does Wedge have a protection to prevent hooks from executing twice? That would explain everything... (I mean, it'd prove that it's due to loadTheme being called twice.)
-
O RLY
OK, so yeah, I suggested there might be issues with language juggling ;)
I know we fixed it to load English first all the time, but I don't know why it's loading them twice. What I'd be inclined to do is try and dump the backtrace upon hitting loadLanguage where it's called to load 'index' to see why it's loading them twice.
/meis still fighting with security issues right now.
-
Who/what is that sarcasm directed to? :^^;:
OK, so yeah, I suggested there might be issues with language juggling ;)
I know we fixed it to load English first all the time, but I don't know why it's loading them twice.
I've even got this halfway through my to-do list (line 612!):
*** loadTheme() is called twice
'***' meaning a high priority item...What I'd be inclined to do is try and dump the backtrace upon hitting loadLanguage where it's called to load 'index' to see why it's loading them twice.
I'll try to see if it happens locally, first./meis still fighting with security issues right now.
-
Looks like it never happens on my local install... I always get the rev number. :-/
Also, the index language is only ever loaded twice at the most (if French is selected), unlike here. Could this be another plugin problem...? Or... Configuration? Hmm...
I guess I'll have to do my tests here.
Posted: January 28th, 2013, 07:06 PM
Also... Why don't we have a UI for $settings['disable_language_fallback']...? I went looking for it in Languages > Settings, to no avail... :(
Posted: January 28th, 2013, 07:07 PM
Woohoo!
Here it is!
// For quick reply we need a response prefix in the default forum language.
if (!isset($context['response_prefix']) && !($context['response_prefix'] = cache_get_data('response_prefix', 600)))
{
if ($language === we::$user['language'])
$context['response_prefix'] = $txt['response_prefix'];
else
{
loadLanguage('index', $language, false);
$context['response_prefix'] = $txt['response_prefix'];
loadLanguage('index');
}
cache_put_data('response_prefix', $context['response_prefix'], 600);
}
That's the code that gets 'index' to be loaded another time.
It's really strange, because the code seems to indicate that it won't be called more than once every 600 seconds...?!
At this point, I don't know if loadTheme() is actually called twice somewhere (outside of this...), because I couldn't reproduce that behavior. But by putting my backtrace inside loadLanguage(), this is what I got.
Posted: January 28th, 2013, 07:18 PM
And, fixed!
Instead of reloading the index language a last time, I just saved $txt before that, and restored $txt immediately after... It should also be much faster, eh!
-
Also... Why don't we have a UI for $settings['disable_language_fallback']...?
That's the code that gets 'index' to be loaded another time.
It's really strange, because the code seems to indicate that it won't be called more than once every 600 seconds...?!
Do we really actually need the Re: part everywhere? The number of people who ask about removing it on sm.org is quite significant, and this is a lot of fluff just for a minor operation that isn't actually needed.
It would also allow us to safely rewrite queries to use the first post's subject rather than the last post's and then replies could all leave the subject empty - saving space.
It's not like we can't rejig the template to use 'Reply #x' as the link to the post either.
-
Also... Why don't we have a UI for $settings['disable_language_fallback']...?
Maybe it was done during my tenure at SMF, though... That might explain why I thought it was Wedge-only.
Anyway!Do we really actually need the Re: part everywhere?
The main drawback is that when you're on mobile (or even on Chrome Desktop!), there's no other way to know the topic title than going to the beginning of the page. Only Firefox Mobile shows the title in the URL bar, but I'm not a big fan of that either (especially since Wedge shows the topic title in the URL in the first place...)
So that's something I was always a bit upset with.It would also allow us to safely rewrite queries to use the first post's subject rather than the last post's and then replies could all leave the subject empty - saving space.
It's not like we can't rejig the template to use 'Reply #x' as the link to the post either.
-
Oh... Another setting I thought we'd added.
The main drawback is that when you're on mobile (or even on Chrome Desktop!), there's no other way to know the topic title than going to the beginning of the page. Only Firefox Mobile shows the title in the URL bar, but I'm not a big fan of that either (especially since Wedge shows the topic title in the URL in the first place...)
Sure we could. But do we have the willingness to rewrite every single post link to indicate whether they're a reply or a new topic..?
I'm thinking we could have an icon to indicate reply vs new topic. Or even if we wanted to be fussy, use whatever $txt['response_prefix'] in the *current* language is. None of this farting about collecting whatever language response prefix or shoving it in to the subject data, just store it without, and display it with it.
Just a thought. It seems like an awful lot of effort for 4 characters.
-
I'm not entirely sure when it was added in SMF - in some fashion or another anyway.
I don't mind leaving it there in the post, though it also wouldn't exactly gnaw at my soul if it were removed either.
Keeping them visually is relatively important for me. Not storing them makes a lot of sense though.
I thought Noisen didn't store them, but it does, I just checked. It only decides to hide them if the title is "Re: Name of Current Topic". If the title is different, or doesn't start with "Re:", it shows it at the top of the post body (which makes sense.)That wasn't quite what I had in mind. Most places where we're getting stuff like that, we're getting topic data, and frequently joining to the first message anyway, so it's not a difficult matter for us to determine in those places whether or not it's the last message in a topic.
I'm thinking we could have an icon to indicate reply vs new topic. Or even if we wanted to be fussy, use whatever $txt['response_prefix'] in the *current* language is. None of this farting about collecting whatever language response prefix or shoving it in to the subject data, just store it without, and display it with it.
Just a thought. It seems like an awful lot of effort for 4 characters.
Suggestion: replace all Re: internally with <r> or something else that's unlikely to be used in a HTML page. Then do a global replace from <r> to the response prefix.. Only drawback I can think of: it brings problems if we're showing the title without going through ob_sessrewrite. I think that PM notifications might be a concern here...? Or do they go through the output buffer?
Ah, early time for bed for me tonight... See you!
-
You mean, per-post titles?
Not storing them makes a lot of sense though.
We might as well want to check all topic queries, and ensure they all comply to {query_see_topic}, at least when needed...
Suggestion: replace all Re: internally with <r> or something else that's unlikely to be used in a HTML page. Then do a global replace from <r> to the response prefix..
-
OK, so the core bug is fixed, around double language handling.
What say we move the response prefix debate to another thread?
-
Well, effectively we have per-post titles. And it's possible for people to change them mid-flow if they want to. (And there are times it's advantageous, e.g. if you merge threads but don't change the post titles)
And I'm not ready to do it like some software that, ahem, adds a position:fixed div with the title whenever the actual title scrolls out of view... It's fun for a minute. Not for daily use.We might as well want to check all topic queries, and ensure they all comply to {query_see_topic}, at least when needed...
(I've always hated privacy stuff... Well, even more since I implemented per-topic privacy in Noisen... Took me days, probably weeks :P)We *could* do that, but I'd rather not, personally. I'd simply avoid the effort of it by just outputting it in the template when necessary. Saves the space in the DB, the extra 'performance hit' is negligible at worst.
-
Um, Chrome displays the page title in the tab at the top of the page, it's only power users who have lots of tabs that have that problem, followed by the fact that there is the big ol' title at the top of the page.
I'd argue that removing the per-post title really isn't a problem any more when it's the same as the topic title.And I'm not ready to do it like some software that, ahem, adds a position:fixed div with the title whenever the actual title scrolls out of view... It's fun for a minute. Not for daily use.
-
You have to help with thought menus first, you cheat :P
-
Not sure if this is a 'bug' per se, or just me being stupid!
I am always interested in the 'New revs' topic and, after reading the latest post, always scroll down to see which revision the site is running on.
I've just noticed that the revision number is sometimes missing, but reappears after refreshing the page?
Like I said, it could very well be me! (BTW using Chrome 26)
-
Interesting. Sounds like a strange thing regarding caching. I've seen odd things with the caching lately.
(It's a plugin btw)
-
Merged the topics...
As far as I can say, this used to be a problem, and I fixed it, re:Instead of reloading the index language a last time, I just saved $txt before that, and restored $txt immediately after... It should also be much faster, eh!
:edit: Reproduced with English UK... Happens about 1 out of 5 times.
-
See differences... The buggy version, has 3 extra files loaded (2 cached, one uncached -- the plugin one.)
-
What I want to know is why there are two separate load requests to the index page. That's fairly clearly the problem: index is loaded, the injection applied, then it's loaded again overwriting the injection.
Now, I could find a later place in which to make the injection but I think what I'd rather do is expand the debugging to find out where the call is coming from.
-
Did you quick-edit the post above..? Because I got the 'New' icon another time after I pressed Refresh. Also, that refresh caused rev 2051 not to show up. I made a dozen more refreshes, and it didn't happen again, but I guess it means it's not due to the wrong caching level, or somethin'.
I don't know why the index language is reloaded. I find it even weirder, that the SkinSelector language file was loaded in one instance, and not in the other...
-
I did not, no. It's definitely screwy. I'm willing to bet there's a locking condition and/or caching.
What I'll do is extend the debug log to include where the call to loadLanguage was made from.
-
Reproduced in French, too...
Same files loaded, really. Same logic.
Adding debug_backtrace to loadLanguage is exactly how I fixed it the last time, so I'll do that here again, and give it a few minutes... ;)
-
Yes, but I intend to add it as a permanent feature to the debug log.
-
So... Reproduced with this file list:
index.french (default, cached), plugin.french (Dragooon:WeMentions), Notifications.french (default, cached), index.english (default, cached), index.french (default, cached), Post.french (default, cached), ActiveMembers.french (live627:active_members), lang/TopicSolved-Display.french (Arantor:TopicSolved), SkinSelector.french (Wedgeward:SkinSelector), Stats.french (default, cached).
I've cleaned up the error log, its last entry is for that particular page load (17:38 for me, probably says 16:38 for you). I THINK. I can't say 100%, but I immediately stopped loading that page after I reproduced the problem, and went to the admin menu, while I was also disabling the logging of language file loading.
Only thing that surprises me is that it has like, 6 entries only for the page... Oh wait, it's probably right -- it can load multiple files per call.
Posted: April 15th, 2013, 05:43 PM
Note that file lines are related to the current online rev, i.e. 2051, not the latest ones.
Also, I don't really see the point in making language loading a feature in the debug area... A better feature, would be to prevent logging some stuff like the block list, which is nice when you're reading a topic page and don't want to have this huge block list come up at the end, eheh... The magic of mini-skeletons ;)
Posted: April 15th, 2013, 05:46 PM
So, interestingly... This looks like the problem is AGAIN due to getRePrefix...
I should have considered it, ah ah...
It simply wasn't "updated" for your new cache system, I guess..?
Posted: April 15th, 2013, 05:47 PM
And, fixed!
Instead of reloading the index language a last time, I just saved $txt before that, and restored $txt immediately after... It should also be much faster, eh!
Anyway, it's an easy fix, so I'm redoing it...
Bummer. Hoping this didn't happen more than once, otherwise...