Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
3781
Archived fixes / Re: Plugin execution
« on January 28th, 2013, 06:52 PM »
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...
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?
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.)
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.)
3782
Archived fixes / Re: Plugin execution
« on January 28th, 2013, 06:45 PM »
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 =...?
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 =...?
3783
Features / Re: New revs
« on January 28th, 2013, 06:42 PM »
rev 1878
(2 files, 2kb)
! Can't use $this inside a static method for the wess_prefixes rewrite... It slipped my mind for a minute. (Or half a day.) Considered moving everything to a static object, but seriously... Is it worth it? (Class-CSS.php)
* Minor updates to Warm... I'm afraid the most visible ones are the footer gradient (which is unlikely to stay forever), and the single extra pixel of padding in the linktree, which makes it look better IMHO... (Warm/extra.css)
(2 files, 2kb)
! Can't use $this inside a static method for the wess_prefixes rewrite... It slipped my mind for a minute. (Or half a day.) Considered moving everything to a static object, but seriously... Is it worth it? (Class-CSS.php)
* Minor updates to Warm... I'm afraid the most visible ones are the footer gradient (which is unlikely to stay forever), and the single extra pixel of padding in the linktree, which makes it look better IMHO... (Warm/extra.css)
3784
Features / Re: New revs
« on January 28th, 2013, 11:53 AM »
rev 1877 -- more CSS fixes and preparing for the future.
(7 files, 9kb)
* Moved the iOS media query out of its own file so that it can be applied to any mobile device. This will allow me to test wedge.org extensively from my Galaxy SIII, so please bear with me if it doesn't look great. Also started fixing the looks of a few places in low-width mode... (header text and menu icon positions.) (extra.ios.css, index.css)
+ Decided to consolidate Wess and moved all prefixing code to it as well. The -prefix keyword should also be safer to use now, e.g. it won't break CSS classes like ".menu-prefix-element", if you ever needed to have such a class name... (Class-CSS.php, Subs-Cache.php)
+ Added support for min or max-device-pixel-ratio prefixing, because of the Firefox hiccup (min--moz-device-pixel-ratio, REALLY?)
! Fixed a Chrome v26 bug (let me insist, it's a bug from Chrome, not from Wedge) where adding a border to :hover or :focus on a textarea or input box will prevent it the latter from accepting text entry. It's completely silly and as yet unexplained. Hopefully it'll be fixed later but I'd rather not take any chances and will probably leave that hack in for quite some time. (index.css)
! Fixed print media query. It was hanging to its old #headerarea which hasn't existed for years (lulz?), so I modified it to hide the header, menu and sidebar. (index.css)
- Removed the 'strong' tag from pinned topic lists. Useg CSS to style their span instead. (MessageIndex.template.php, index.css)
! $reddish was indicated as an unused var, but it was very much used and should (semantically?) be in the var declaration area. (common.css, index.css)
(7 files, 9kb)
* Moved the iOS media query out of its own file so that it can be applied to any mobile device. This will allow me to test wedge.org extensively from my Galaxy SIII, so please bear with me if it doesn't look great. Also started fixing the looks of a few places in low-width mode... (header text and menu icon positions.) (extra.ios.css, index.css)
+ Decided to consolidate Wess and moved all prefixing code to it as well. The -prefix keyword should also be safer to use now, e.g. it won't break CSS classes like ".menu-prefix-element", if you ever needed to have such a class name... (Class-CSS.php, Subs-Cache.php)
+ Added support for min or max-device-pixel-ratio prefixing, because of the Firefox hiccup (min--moz-device-pixel-ratio, REALLY?)
! Fixed a Chrome v26 bug (let me insist, it's a bug from Chrome, not from Wedge) where adding a border to :hover or :focus on a textarea or input box will prevent it the latter from accepting text entry. It's completely silly and as yet unexplained. Hopefully it'll be fixed later but I'd rather not take any chances and will probably leave that hack in for quite some time. (index.css)
! Fixed print media query. It was hanging to its old #headerarea which hasn't existed for years (lulz?), so I modified it to hide the header, menu and sidebar. (index.css)
- Removed the 'strong' tag from pinned topic lists. Useg CSS to style their span instead. (MessageIndex.template.php, index.css)
! $reddish was indicated as an unused var, but it was very much used and should (semantically?) be in the var declaration area. (common.css, index.css)
3785
Development blog / Re: It only took two guys two years...
« on January 27th, 2013, 06:34 PM »I have to write code to export our forum from Drupal Advanced Forum to SMF or Wedge.
3786
Archived fixes / Re: Plugin execution
« on January 27th, 2013, 06:30 PM »
Try to switch to French.
It seems to happen only in French, actually... That may be a clue?
It seems to happen only in French, actually... That may be a clue?
3787
Features / Re: New revs
« on January 27th, 2013, 06:28 PM »
rev 1876 -- I'm baaaad!
(2 files, 1kb)
! Fixed CSS @language parser... Again ;) (Subs-Cache.php)
! Typo resulting in a crash. Boo. (EmailTemplates.french.php)
(2 files, 1kb)
! Fixed CSS @language parser... Again ;) (Subs-Cache.php)
! Typo resulting in a crash. Boo. (EmailTemplates.french.php)
3788
Features / Re: Plugin revs
« on January 27th, 2013, 11:30 AM »
rev 71
(1 file, 2kb) (not worth 2kb, really...)
* [mass_upload] At least making the mass attach stuff work, until I get word from Dragooon about the plugin name & owner... (plugin-info.xml)
(1 file, 2kb) (not worth 2kb, really...)
* [mass_upload] At least making the mass attach stuff work, until I get word from Dragooon about the plugin name & owner... (plugin-info.xml)
3789
Archived fixes / Re: Plugin execution
« on January 27th, 2013, 11:28 AM »
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..?
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..?
3790
Plugins / Re: Plugin CSS in regular files?
« on January 27th, 2013, 11:14 AM »
Wasn't this seen as too hackish..?
I guess only time will tell...!
I guess only time will tell...!
3792
Bug reports / Re: SMF bug: replying to topic with mismatch of replies
« on January 27th, 2013, 10:26 AM »
I thought SMF did the change to last post before we forked it. I kinda remember making a bug report about it at the time... maybe I was even the one who started the idea of using last post Id. Don't remember too well. Years ago.
Maybe they reverted it? dunno. It doesn't make sense to me.
Maybe they reverted it? dunno. It doesn't make sense to me.
3793
Bug reports / Re: Weaving & Warm issues in iOS
« on January 26th, 2013, 07:22 PM »
Yep... Looking good I can see :)
BTW I'm at a loss about something... My code indicates that up until now, iPads were considered as wireless devices, and thus guests would get the Wireless skin by default. Can you confirm it's the case? Because your screenshots as a guest said otherwise, but OTOH they seem to be taken after specifically switching to that skin...
BTW I'm at a loss about something... My code indicates that up until now, iPads were considered as wireless devices, and thus guests would get the Wireless skin by default. Can you confirm it's the case? Because your screenshots as a guest said otherwise, but OTOH they seem to be taken after specifically switching to that skin...
3794
Bug reports / Re: SMF bug: replying to topic with mismatch of replies
« on January 26th, 2013, 07:20 PM »
Heck, ideally we should provide the post with the complete list of message IDs.................... NOT :P
3795
Plugins / Re: Plugin JS language settings
« on January 26th, 2013, 07:19 PM »Then it will be broken because all of the loadPlugin* functions need two parameters ;) They need the plugin id and the plugin file to load. I don't mind how we do that, as I suggested before we could accept it as author:plugin:file, explode on : then recombine the first two.Quote @language xxx does exactly this: loadPluginLanguage('xxx').
loadPluginLanguage($exp[0] . ':' . $exp[1], $exp[2]);$exp being the exploded string ;)
I haven't tested with paths yet, though...
Wait a minute though, if you're calling this for a given plugin, the implication is that you'll already have the plugin id...