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
4411
Features / Re: Things to do before the Mayan apocalypse: membergroups
« on September 23rd, 2012, 11:37 PM »
But do you see more issues coming out of using membergroups for contact lists, or a proper contact list table..?
I think that contact lists are the easiest to do, and thus probably the easiest to maintain afterwards... And we can always add privacy settings for contact lists afterwards.
I think that contact lists are the easiest to do, and thus probably the easiest to maintain afterwards... And we can always add privacy settings for contact lists afterwards.
4412
The Pub / Re: Language editing inside Wedge
« on September 23rd, 2012, 11:27 PM »
(Re: latest rev -- should it be notewarn for new PMs..? IIRC I set the semantics to use notenice because a PM isn't usually a 'warning' but something neutral or maybe even 'good news'... Or maybe I was just a bit too thorough with these three notice states..?)Quote from Arantor on September 23rd, 2012, 04:30 PM If you wander into the media area, you'll also get media and zoom files.Quote Hmm it's called in wedge_cache_js, only at the time of caching, otherwise it'd defeat the purpose of it all... add_js_file doesn't call wedge_cache_js, unless the file isn't found.Quote (Process?)
script-123.js -> script.js with English strings (or whatever the default language is)
script-french-123.js -> script.js with French strings (or whatever the alternative language is)Quote I'm not sure we're on the same line here..?
Anyway, to make things short:
We need to determine whether a language file has been modified. The easiest/quickest is to do it at loadLanguage time, because it's rather likely that PHP internally loads file data when including it (i.e. it knows the file modification date and doesn't waste time retrieving it again). If a language file is found to be updated, then we can do a simple call to clean_cache('js') to empty the JS folder. This means all JS files will have to be regenerated, even for a language file that never gets used in them -- but it's acceptable since (1) it's unlikely an admin is going to update their language files a lot...?, (2) these files only get generated when needed, thus they won't be regenerated all at the same time, and the extra CPU time is split over several minutes or hours.
Now, there are some potential problems once again...
- Imagine that script.js uses @language ManageTopics, and the admin never actually visits the admin area... It means the script file never gets updated, even if the corresponding language file is updated. It's unlikely, but still...?
- I still can't think of a 'correct' way to cache file dates. I'm thinking of something like this... Please give me your opinion?
A $settings['lang_dates'] array that contains keys like 'Admin_french' (as indicated in my previous post), and a value representing the modified date. The array is only filled with entries that are found in the JS scripts (@language entries), in the language requested. At compile time, the current language files and user language are used to store this data in the array, then submit it via updateSettings(). When it comes to doing loadLanguage(), the language and filename are determined, and if (isset($settings['lang_dates'][$filename . '_' . $lang]), then compare the actual filedate with that value... This would ensure that only the files actually cached in JS scripts will be tested for modifications. (Of course, if a plugin/feature is removed that used to include a certain language file, that entry will be wasting space in the database for nothing... But I don't have a solution for this, either.)
I count 9 JS files at present: admin, captcha, editor, mediadmin, register, script, script-sha1, suggest, topic. That's not necessarily definitive, but what I've encountered so far in general use.
add_js_file would load the file, you'd be calling loadLanguage or loadPluginLanguage anyway from there.
That means, basically, you'll still fall into the process I'm talking about. There's no reason why the same process couldn't also contain the JS language file, though if I understand you correctly, you're almost talking about having multiple language JS files too...
script-123.js -> script.js with English strings (or whatever the default language is)
script-french-123.js -> script.js with French strings (or whatever the alternative language is)
Either way, I see no reason why an editor couldn't cope with being able to edit either and load from the DB, caching the results. It only has to worry about caching if people are daft enough to edit files directly, but then all bets are off anyway.
Anyway, to make things short:
We need to determine whether a language file has been modified. The easiest/quickest is to do it at loadLanguage time, because it's rather likely that PHP internally loads file data when including it (i.e. it knows the file modification date and doesn't waste time retrieving it again). If a language file is found to be updated, then we can do a simple call to clean_cache('js') to empty the JS folder. This means all JS files will have to be regenerated, even for a language file that never gets used in them -- but it's acceptable since (1) it's unlikely an admin is going to update their language files a lot...?, (2) these files only get generated when needed, thus they won't be regenerated all at the same time, and the extra CPU time is split over several minutes or hours.
Now, there are some potential problems once again...
- Imagine that script.js uses @language ManageTopics, and the admin never actually visits the admin area... It means the script file never gets updated, even if the corresponding language file is updated. It's unlikely, but still...?
- I still can't think of a 'correct' way to cache file dates. I'm thinking of something like this... Please give me your opinion?
A $settings['lang_dates'] array that contains keys like 'Admin_french' (as indicated in my previous post), and a value representing the modified date. The array is only filled with entries that are found in the JS scripts (@language entries), in the language requested. At compile time, the current language files and user language are used to store this data in the array, then submit it via updateSettings(). When it comes to doing loadLanguage(), the language and filename are determined, and if (isset($settings['lang_dates'][$filename . '_' . $lang]), then compare the actual filedate with that value... This would ensure that only the files actually cached in JS scripts will be tested for modifications. (Of course, if a plugin/feature is removed that used to include a certain language file, that entry will be wasting space in the database for nothing... But I don't have a solution for this, either.)
4413
The Pub / Re: Language editing inside Wedge
« on September 23rd, 2012, 01:22 PM »There shouldn't be much if any string concatenation, I'm fairly sure I phased most of that crap out.
As far as the array declarations, it's still not a problem, the language editor just has to understand how to read the array, and then be able to overwrite the array later. All that really means is to store the serialised array and unserialise it when loading from the DB.
The speed issue is the big one. Practically it means intercepting loadLanguage and loadPluginLanguage calls, perform them then pull from the database. We can also cache the resulting language file, though.
This would complicate the above significantly, though. The only real problem I see with doing that is you end up consuming a lot of space in cache files by having editor-english.js and editor-french.js - and if you have a site with lots of languages, you potentially end up with dozens of files at once.
Other than that, it's just on average twice the current amount of cached JS files, which is very, very small, especially when compared to the number of CSS files in the css cache... Just go have a look ;)
No, the real problem with language caching here, is two-fold. Here's how I've been writing the stuff: script files can contain $txt['something'] strings, and we add a "@language index" keyword at the start of the file (or anywhere...), to tell Wedge where it can find this string, thus it loads the language file beforehand. You can use multiple @language entries, or merge all entries into a "@language index, Admin, Media" call or whatever you want. Flexibility is my thing.
- The first problem is easily solved, but pretty ugly if you'll ask me... People using the default language: no problems. People using another language: add_js_file (or whatever it is) should test for script-french.js.gz, if it's there, return that, otherwise test for script.js.gz, if it's there, return that, otherwise cache the file, under the name script-french.js.gz if it has language strings in it, or script.js.gz otherwise. The problem is that French users have to go through two file_exists tests. Okay, it's not that big a deal...
- The second problem comes when you update the language files. Even if these aren't strings we use in the script, we still need to regenerate the cache, 'just in case'... But how do you determine that the language files are modified? If the script file is already cached, does that mean you have to open it the uncached version, then look for the @language command, list all language files in it, then check every single language file for date changes...? It screams "needs wedge_settings caching!" to me... But I don't even know how to deal with that one. e.g. everytime we do a loadLanguage(), do we need to see if the filedate has changed, and if yes, store it into a DB setting like 'lang_date_Admin_french' or something...? Does it make sense at all?
Other than that, this feature is something I'm really starting to like. It was an easy implementation (i.e. just a few regexps), it works very well (with the added benefit of being able to cache JavaScriptEscape calls!!), and it does save a lot of space in the HTML... Which is something I'm always going to push for!
I just need to coordinate this change with you, considering you're thinking it's going to cause trouble for plugins.
I really can't remember :(Quote What did we decide in the end?
4414
Features / Re: Things to do before the Mayan apocalypse: membergroups
« on September 23rd, 2012, 01:00 PM »
So, err... No opinions I guess..?
4415
Plugins / Re: Something I started working on
« on September 23rd, 2012, 12:59 PM »I don't actually like JavaScript that much if I'm honest, but as I said, if I knew how I'd like it to look, I could probably make my own.
The plugin provides absolute URLs for everything, and the code was designed with that in mind and has been that way since I wrote the guts of the plugin manager a year ago. The problem with relative URLs is that it assumes the structure doesn't change, just as some mods assumed that Sources would always be at $boardurl/Sources, which it isn't. I know at least a dozen sites that do that, and I can well imagine they would want to do the same with plugins.
It's no biggie, but absolute URLs can be a pain when doing getimagesize() on them, so doing, in Wess, a "width(absolute_url)px" call might fail if the server doesn't allow for these... :-/
Other than that, yeah, it makes more sense to test for absolute URLs inside the dynamic function, but the above is the reason why I wanted to explore something else before, ah ah...
4416
Off-topic / Re: Doctor Who
« on September 23rd, 2012, 11:18 AM »
And, three out of four!
Congrats to Chibnall for writing his best episode of the show so far! I totally forgive him for my disappointment in Dinosaurs :)
This is exactly the kind of storyline I enjoy in Who: an episode-length mystery, humour, not too many silly monsters, not too much action, just time to think and laugh...
The only lesser part of the episode, is the resolution I'd say. The part where the Doctor fixes it.
(click to show/hide)
Oh, I forgot... Yesterday I finally watched The Second Coming (2003), a TV movie written by Russel T. Davies and starring Chris Eccleston, before they made Who together. It was very slow but engaging, and overall a pretty solid story. I'd recommend it to anyone interested in seeing RTD stuff that may have inspired his stints on Who (Eccleston's enthusiasm) and Torchwood (the grittiness of it all).
Congrats to Chibnall for writing his best episode of the show so far! I totally forgive him for my disappointment in Dinosaurs :)
This is exactly the kind of storyline I enjoy in Who: an episode-length mystery, humour, not too many silly monsters, not too much action, just time to think and laugh...
The only lesser part of the episode, is the resolution I'd say. The part where the Doctor fixes it.
It's just too quick... "Oh, I'll just do this and that to their computer and it'll reverse everything."
Even then -- didn't the Shakri say they were sending a second wave...? What about it?
Posted: September 23rd, 2012, 11:13 AM
Oh, I forgot... Yesterday I finally watched The Second Coming (2003), a TV movie written by Russel T. Davies and starring Chris Eccleston, before they made Who together. It was very slow but engaging, and overall a pretty solid story. I'd recommend it to anyone interested in seeing RTD stuff that may have inspired his stints on Who (Eccleston's enthusiasm) and Torchwood (the grittiness of it all).
4417
Plugins / Re: Something I started working on
« on September 22nd, 2012, 03:55 PM »I haven't found one in jQuery that I like the look of though, and don't know exactly how I'd like it to look either...
Okay, may have found a bug somewhere, *or* I incorrectly set something up, but it shouldn't be doing this...
Warning: getimagesize(/my_root/wedge/Themes/default/images/admin/http://wedge.org/.../topic_solved/img/tick.png) [function.getimagesize]: failed to open stream: No such file or directory in /my_root/wedge/Sources/Class-CSS.php on line 619
This is caused by the admin menu's call to the @dynamic CSS icon generator, which in turn expects the 'icon' entry of admin menus to be a relative URL, rather than absolute...
And it seems that your plugin system provides an absolute URL to the tick.png file. It should either calculate the relative position for it, or we should update the admin code to deal with absolute URLs... What do you prefer..?
4418
Features / Re: New revs
« on September 22nd, 2012, 03:39 PM »
rev 1701 -- the cleanup rev, + @if at last! I'm seeing the end of the tunnel!
(4 files, 9kb)
+ Added @if function to Wess. The difference with @is is in the syntax: "@is (test, true, false)" can be done inline (so basically it's an @inlineif), while "@if test" is on its own line, and should be followed by an @endif on the same tab level, with a potential @else in between. This should allow for cleaner tests. And just like @is, they're nestable. Replaced a few @is calls with @if. (Class-CSS.php, common.css, index.css)
* Made more functions stricter when it comes to whitespace (i.e. not accept linebreaks within their declarations): rgb(a), hsl(a), gradient, @import, @charset, @mixin, mixes, properties, reset, virtual, unextends (extends was already done this way), final, @remove, @dynamic, @ifnull, @is and @if. Also on variable declarations, which made me realize that their regex is a bit flaxed, someone please remind me to rework it. (Class-CSS.php)
@ Note: I've compiled a before/after version and the result is the same, so it's probably bug-free.
+ Added more support for @is and @if to manage variables, but it's still not built in. The idea is to call the plugin twice: once before the mixins, to do the globals, and once after, to deal with local variables mostly. And no, this isn't ready yet. Dunno if it'll even be ready before the first release. (Class-CSS.php)
* Some cleaner code in the media quota edit page. (ManageMedia.php)
(4 files, 9kb)
+ Added @if function to Wess. The difference with @is is in the syntax: "@is (test, true, false)" can be done inline (so basically it's an @inlineif), while "@if test" is on its own line, and should be followed by an @endif on the same tab level, with a potential @else in between. This should allow for cleaner tests. And just like @is, they're nestable. Replaced a few @is calls with @if. (Class-CSS.php, common.css, index.css)
* Made more functions stricter when it comes to whitespace (i.e. not accept linebreaks within their declarations): rgb(a), hsl(a), gradient, @import, @charset, @mixin, mixes, properties, reset, virtual, unextends (extends was already done this way), final, @remove, @dynamic, @ifnull, @is and @if. Also on variable declarations, which made me realize that their regex is a bit flaxed, someone please remind me to rework it. (Class-CSS.php)
@ Note: I've compiled a before/after version and the result is the same, so it's probably bug-free.
+ Added more support for @is and @if to manage variables, but it's still not built in. The idea is to call the plugin twice: once before the mixins, to do the globals, and once after, to deal with local variables mostly. And no, this isn't ready yet. Dunno if it'll even be ready before the first release. (Class-CSS.php)
* Some cleaner code in the media quota edit page. (ManageMedia.php)
4419
The Pub / Re: Logo Madness
« on September 22nd, 2012, 11:46 AM »
Footer version of the W one... And alternative version of the popular one, using the last footer's color/style.
Alternative bright version... Doesn't work well on this background.
Updated homepage logo to stop having the text stuck to the square...
Posted: September 21st, 2012, 09:34 AM
Alternative bright version... Doesn't work well on this background.
Posted: September 22nd, 2012, 11:38 AM
Updated homepage logo to stop having the text stuck to the square...
4420
Features / Re: Sidebar emulation method in IE6/7
« on September 22nd, 2012, 10:51 AM »
It's just that I'm obviously trying to get rid of the old IE compatibility code when it gets in the way of readability for the main Wedge code...
It's really a problem to me because I can't make my mind between readability and the fact that most themers won't touch that area of code anyway. But it's still in index.template.php and thus is something that bothers me a bit. It's quite plain-in-the-face.
It's really a problem to me because I can't make my mind between readability and the fact that most themers won't touch that area of code anyway. But it's still in index.template.php and thus is something that bothers me a bit. It's quite plain-in-the-face.
4421
Features / Re: New revs
« on September 21st, 2012, 06:02 PM »
rev 1700
(9 files -2, 5kb)
* Wine now uses a minor hack to switch the sidebar position, removing the need to provide a new skeleton in the skin file, as well as updated macros. You can still view sample macros and skeletons in the Warm skin, which is pretty much there precisely for that reason... Also updated Warm and Wuthering to react correctly. If you look closely, you'll see that Wuthering redefines #sidebar but this is needed, as currently Wess will remove items from classes listed in @remove, regardless of whether there are other classes using them. Rewriting Wess any other way would make it way too complex. Finally, wanted to say that since Warm redefines the HTML layout it won't react to it properly anyway, it should be repositioned slightly differently. I've indicated how in an extra.css comment as well. (Wine/extra.css, Wine/skin.xml, Warm/extra.css, Warm/skin.xml, Wuthering/extra.css)
- Are IE6/7/8 users really worth showing a subtle gradient in select box buttons...? Would they even notice it? No, I don't think so. That saves us about 100 gzipped bytes per CSS file. (select_arrow_bg.gif, select_arrow_bg_hover.gif, extra.ie[-8].css)
! Shortened clearfix for IE 6/7. While not exactly critical here, I've still decided to write a proper version... And it's shorter than for other browsers, for once. Also, fixing clearfix additions that were badly handled -- for some reason, they were using spaces instead of tabs. (common.css, extra.ie6.css, extra.ie7.css)
* Now using box shadows instead of gradients for Wine headers. They're too small to have any strong impact on browser rendering performance, I'd say. Also fixing inline blocks in responsive layouts. (Wine/extra.css)
(9 files -2, 5kb)
* Wine now uses a minor hack to switch the sidebar position, removing the need to provide a new skeleton in the skin file, as well as updated macros. You can still view sample macros and skeletons in the Warm skin, which is pretty much there precisely for that reason... Also updated Warm and Wuthering to react correctly. If you look closely, you'll see that Wuthering redefines #sidebar but this is needed, as currently Wess will remove items from classes listed in @remove, regardless of whether there are other classes using them. Rewriting Wess any other way would make it way too complex. Finally, wanted to say that since Warm redefines the HTML layout it won't react to it properly anyway, it should be repositioned slightly differently. I've indicated how in an extra.css comment as well. (Wine/extra.css, Wine/skin.xml, Warm/extra.css, Warm/skin.xml, Wuthering/extra.css)
- Are IE6/7/8 users really worth showing a subtle gradient in select box buttons...? Would they even notice it? No, I don't think so. That saves us about 100 gzipped bytes per CSS file. (select_arrow_bg.gif, select_arrow_bg_hover.gif, extra.ie[-8].css)
! Shortened clearfix for IE 6/7. While not exactly critical here, I've still decided to write a proper version... And it's shorter than for other browsers, for once. Also, fixing clearfix additions that were badly handled -- for some reason, they were using spaces instead of tabs. (common.css, extra.ie6.css, extra.ie7.css)
* Now using box shadows instead of gradients for Wine headers. They're too small to have any strong impact on browser rendering performance, I'd say. Also fixing inline blocks in responsive layouts. (Wine/extra.css)
4422
Features / Re: Sidebar emulation method in IE6/7
« on September 21st, 2012, 05:50 PM »
So, err, in case my post yesterday wasn't clear... I was saying, solution (1) should be amended to say, "the main drawback is that IE 6/7 can't have their sidebar moved to the bottom in case we're in a low resolution."
Should I make a proper poll for this...?
Or... Silly me... I could 'simply' use a 'always below' position for IE6/7... i.e. we still use <div> tags on them, but the sidebar is considered as a block instead of a table-cell, and thus is always moved to the end. We can complete this with a max-width on IE7 to ensure the text doesn't expand too wide compared to other browsers.
Bump! I love bumps. Except on my forehead...
Should I make a proper poll for this...?
Posted: September 21st, 2012, 09:38 AM
Or... Silly me... I could 'simply' use a 'always below' position for IE6/7... i.e. we still use <div> tags on them, but the sidebar is considered as a block instead of a table-cell, and thus is always moved to the end. We can complete this with a max-width on IE7 to ensure the text doesn't expand too wide compared to other browsers.
Posted: September 21st, 2012, 10:07 AM
Bump! I love bumps. Except on my forehead...
4423
Features / Re: Plugin revs
« on September 21st, 2012, 09:32 AM »
Enabled here... Haven't set permissions, though. So it's admin-only for now. Haven't tested anything. Just thought you'd want to ensure it works here ;)
4424
The Pub / Re: Logo Madness
« on September 20th, 2012, 10:16 PM »
And this? Hmm no better...
The more I do logos, the less they're like.
In two weeks time I'll be going back to my very first ugly ones...! We'll see then :P
The more I do logos, the less they're like.
In two weeks time I'll be going back to my very first ugly ones...! We'll see then :P
4425
Features / Re: New revs
« on September 20th, 2012, 07:23 PM »
rev 1699
(6 files, 2kb)
* Another update that stayed in my local install for a long time... Overhauled the search page UI to go from 'quite ugly' to 'watchable'. Many changes, although in the end most of it is under the hood, I guess. (Search.php, Search.template.php, Search.language.php, index.french.php)
* Just adding an extra comment to the macro area in the index template... I believe it's needed to explain what it does in this case. (index.template.php)
(6 files, 2kb)
* Another update that stayed in my local install for a long time... Overhauled the search page UI to go from 'quite ugly' to 'watchable'. Many changes, although in the end most of it is under the hood, I guess. (Search.php, Search.template.php, Search.language.php, index.french.php)
* Just adding an extra comment to the macro area in the index template... I believe it's needed to explain what it does in this case. (index.template.php)