This topic was marked solved by its starter, on May 26th, 2013, 12:52 PM

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Plugin execution
« Reply #15, on January 28th, 2013, 07:01 PM »
Quote from Arantor on January 28th, 2013, 06:53 PM
O RLY
Who/what is that sarcasm directed to? :^^;:
Quote
OK, so yeah, I suggested there might be issues with language juggling ;)
Yep, you were right in the first place...
Quote
I know we fixed it to load English first all the time, but I don't know why it's loading them twice.
I really remember that we had this conversation, but I can't find where (used the search engine and all...)

I've even got this halfway through my to-do list (line 612!):

Code: [Select]
*** loadTheme() is called twice

'***' meaning a high priority item...
Quote
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.
Hmm, I guess we can do that...
I'll try to see if it happens locally, first.
Quote
* Arantor is still fighting with security issues right now.
Oh... That sounds fun. :-/
Re: Plugin execution
« Reply #16, on January 28th, 2013, 07:23 PM »
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!

Code: [Select]
// 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!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin execution
« Reply #17, on January 28th, 2013, 07:35 PM »
Quote
Also... Why don't we have a UI for $settings['disable_language_fallback']...?
Because, like SMF, it is supposed to be a hidden setting.
Quote
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...?!
Can I make a tactical suggestion?

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.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Plugin execution
« Reply #18, on January 28th, 2013, 09:40 PM »
Quote from Arantor on January 28th, 2013, 07:35 PM
Quote
Also... Why don't we have a UI for $settings['disable_language_fallback']...?
Because, like SMF, it is supposed to be a hidden setting.
Oh... Another setting I thought we'd added.
Maybe it was done during my tenure at SMF, though... That might explain why I thought it was Wedge-only.
Anyway!
Quote
Do we really actually need the Re: part everywhere?
Not really, no... If you'll look at noisen.com, I deliberately decided to hide the post titles, and internally I think I did without the response prefix, although it wasn't removed entirely. (The code I pasted above is actually repeated several times in the codebase, e.g. in Merge.php or the PM stuff.)
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.
Quote
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.
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 know I would be lost otherwise, e.g. Newest Posts page, Stats page (most liked posts: new topic or regular post..? The Re: says it all), stuff like that.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin execution
« Reply #19, on January 28th, 2013, 10:18 PM »
Quote
Oh... Another setting I thought we'd added.
I'm not entirely sure when it was added in SMF - in some fashion or another anyway.
Quote
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...)
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.
Quote
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..?
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.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Plugin execution
« Reply #20, on January 28th, 2013, 10:48 PM »
Quote from Arantor on January 28th, 2013, 10:18 PM
I'm not entirely sure when it was added in SMF - in some fashion or another anyway.
I'm sure there's a beta testing report of mine suggesting it. Probably.
Quote
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.
You mean, per-post titles?
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.)
Quote
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.
We might as well want to check all topic queries, and ensure they all comply to {query_see_topic}, at least when needed...
Quote
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.
Sure is.
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!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin execution
« Reply #21, on January 28th, 2013, 10:58 PM »
Quote
You mean, per-post titles?
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)
Quote
Not storing them makes a lot of sense though.
I would rather leave replies' subjects empty unless they different from the topic title; removing them from the messages table and attaching them to the topics table brings its own set of problems.
Quote
We might as well want to check all topic queries, and ensure they all comply to {query_see_topic}, at least when needed...
True enough - but for now at least, it occurs to me that this measure would essentially encourage us to re-review all the queries.
Quote
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..
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.
Re: Plugin execution
« Reply #22, on February 10th, 2013, 06:23 PM »
OK, so the core bug is fixed, around double language handling.

What say we move the response prefix debate to another thread?

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Plugin execution
« Reply #23, on February 14th, 2013, 07:11 PM »
Quote from Arantor on January 28th, 2013, 10:58 PM
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)
Yup, as I probably said before, it's done that way in Noisen... Titles are hidden, unless someone manually changed it in their post. It's really what's best. But it just doesn't "work" when the browser doesn't show the page title anywhere, e.g. Chrome or mobile ones.
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.
Quote
Quote
We might as well want to check all topic queries, and ensure they all comply to {query_see_topic}, at least when needed...
True enough - but for now at least, it occurs to me that this measure would essentially encourage us to re-review all the queries.
Yes.
(I've always hated privacy stuff... Well, even more since I implemented per-topic privacy in Noisen... Took me days, probably weeks :P)
Quote
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.
'kay.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin execution
« Reply #24, on February 14th, 2013, 07:14 PM »
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.
Quote
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.
Yeah, please don't.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Plugin execution
« Reply #25, on February 14th, 2013, 07:24 PM »
You have to help with thought menus first, you cheat :P

Drunken Clam

  • Drool, drool, drool....!
  • Posts: 154
Revision Number Display
« Reply #26, on April 15th, 2013, 04:16 PM »
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)

 New revs page 83 No version number.png - 10.97 kB, 748x100, viewed 152 times.

 New revs page 83 Version number.png - 11.45 kB, 824x88, viewed 152 times.


Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Revision Number Display
« Reply #27, on April 15th, 2013, 04:42 PM »
Interesting. Sounds like a strange thing regarding caching. I've seen odd things with the caching lately.

(It's a plugin btw)

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Plugin execution
« Reply #28, on April 15th, 2013, 04:56 PM »
Merged the topics...

As far as I can say, this used to be a problem, and I fixed it, re:
Quote
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!
If it no longer works, then it's probably due to language caching, since this was implemented by Pete only recently. It's expected to have bugs with it, considering it also saves much processing time on each page. However, I'm afraid I can't reproduce the bug here... Really, it always shows me the rev number. Maybe it's for a specific language, I don't know..?

:edit: Reproduced with English UK... Happens about 1 out of 5 times.
Re: Plugin execution
« Reply #29, on April 15th, 2013, 05:08 PM »
See differences... The buggy version, has 3 extra files loaded (2 cached, one uncached -- the plugin one.)

 langbug.png - 39.15 kB, 997x258, viewed 127 times.