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
3661
Features / Re: Plugin revs
« on February 11th, 2013, 06:50 PM »
rev 74 -- because it was on my to-do-list.
(2 files, 4kb)
* Renamed Theme Selector plugin to Skin Selector. This was a long time coming... I also renamed the author to Wedgeward. Again, this is something that can easily be reversed... (skin_selector)
* Rewrote skin selector to use the new skin retrieval code in Wedge (coming in the next commit.) (SkinSelector.php)
* Themes will now be shown through an optgroup, rather than a regular entry. The default skin gets a nice little 'Default' indicator. Same for the default mobile skin, but technically these are to be documented as Wedge rewrites. Also, if there's only one theme installed, the theme name is completely hidden. Well, it had better be, because the new code is totally, absolutely and shamelessly untested with multiple themes... (SkinSelector.php)
(2 files, 4kb)
* Renamed Theme Selector plugin to Skin Selector. This was a long time coming... I also renamed the author to Wedgeward. Again, this is something that can easily be reversed... (skin_selector)
* Rewrote skin selector to use the new skin retrieval code in Wedge (coming in the next commit.) (SkinSelector.php)
* Themes will now be shown through an optgroup, rather than a regular entry. The default skin gets a nice little 'Default' indicator. Same for the default mobile skin, but technically these are to be documented as Wedge rewrites. Also, if there's only one theme installed, the theme name is completely hidden. Well, it had better be, because the new code is totally, absolutely and shamelessly untested with multiple themes... (SkinSelector.php)
3662
Archived fixes / Re: sb refresh does not update scrollbar
« on February 11th, 2013, 02:32 PM »
Oh, bugger, you're right...
I'll work on this one straight away.
Fixed locally... I hate bugs that take an hour to 'understand'.
This is due to jQuery no longer (in v1.9+) copying originalEvent properties to the passed event object.
So I had to specifically name them. It added 3 bytes to the final code, but I guess that's still all right...
This was actually removed in v1.7.x, not 1.9, and isn't related to the stuff I read about originalEvent... It's just that they stopped supporting it, and said to go use a plugin.
Nice... They could have said it in their blog, for instance... Hmm? ::)
http://bugs.jquery.com/ticket/10676
I'll work on this one straight away.
Posted: February 11th, 2013, 01:30 PM
Fixed locally... I hate bugs that take an hour to 'understand'.
This is due to jQuery no longer (in v1.9+) copying originalEvent properties to the passed event object.
So I had to specifically name them. It added 3 bytes to the final code, but I guess that's still all right...
Posted: February 11th, 2013, 02:30 PM
This was actually removed in v1.7.x, not 1.9, and isn't related to the stuff I read about originalEvent... It's just that they stopped supporting it, and said to go use a plugin.
Nice... They could have said it in their blog, for instance... Hmm? ::)
http://bugs.jquery.com/ticket/10676
3663
Features: Posts & Topics / Re: Moderation Filters
« on February 11th, 2013, 01:28 PM »
Eh, good that you're considering helping with that annoying board, eh eh... ;)
Documentation really isn't my thing. When I reviewed all of these items a few days ago to update their completion status (surprisingly they're all set as 'complete', except for the Upcoming Features area unfortunately), I was surprised by the amount of work I'd put into it.
Anyway, I was thinking about moderation filters and here's an idea in case you ever miss working on them...
Allow (perm?) for *users* to set up their own moderation filters. Of course, they wouldn't be able to do any harm. The only point is to allow for users to 'monitor' new posts and receive a notification whenever someone posts, for instance, "I like cheese" in a new message, or even their nickname. (Perhaps not when used in a quote, though, for instance...)
It could either be an entirely separate feature that would use part of your moderation filter code, or something blended in, I don't know.
I'm not sure you'll like the idea, and you're free not to go for it, I just think it would be a nice new feature for Wedge. Plus, it would save us from people using the search engine to look for their name on a regular basis... Like I do sometimes at sm.org, eh eh ;)
Documentation really isn't my thing. When I reviewed all of these items a few days ago to update their completion status (surprisingly they're all set as 'complete', except for the Upcoming Features area unfortunately), I was surprised by the amount of work I'd put into it.
Anyway, I was thinking about moderation filters and here's an idea in case you ever miss working on them...
Allow (perm?) for *users* to set up their own moderation filters. Of course, they wouldn't be able to do any harm. The only point is to allow for users to 'monitor' new posts and receive a notification whenever someone posts, for instance, "I like cheese" in a new message, or even their nickname. (Perhaps not when used in a quote, though, for instance...)
It could either be an entirely separate feature that would use part of your moderation filter code, or something blended in, I don't know.
I'm not sure you'll like the idea, and you're free not to go for it, I just think it would be a nice new feature for Wedge. Plus, it would save us from people using the search engine to look for their name on a regular basis... Like I do sometimes at sm.org, eh eh ;)
3664
Features / Re: New revs
« on February 11th, 2013, 01:23 PM »
rev 1914 -- registration process optimization, no biggie.
(14 files, 15kb)
* Moved registration/reminder text strings to their JS file. Overhauled said file to be much shorter (by around 200 bytes), even after adding the strings. Not that it's gonna be noticeable on your bandwidth meter, but whatever... Every little helps. Plus, I was always put off by that unused index #3 in verification field arrays. Also... Why the heck did I leave these Optimize strings in the JS file, when Packer will always minify them anyway? (Register.template.php, Reminder.template.php, register.js)
* Moved draft removal text string to its JS file. (Class-Editor.php, editor-func.js)
* Rewrote captcha sound to use the generic popup. Also fixed the 'Play again' link to avoid jumping to the top of the page. (VerificationCode.php, Register.template.php, Login.language.php)
* Added placeholder text for e-mail input at registration time. You never know... (Register.template.php, Login.language.php)
! Adding to $context['footer_js'] directly is bad practice, and could even break the feature. Modified all instances to add to a local string and then call add_js with this string as a parameter. (Class-Editor.php, Aeva-Foxy.php, Aeva-Gallery2.php, Display.template.php, PersonalMessage.template.php)
! If a captcha was failed, the second instance wouldn't allow for the sound popup to be run. (Subs-Editor.php)
! Fixed minor typo in French translation. Eh, my bad... (index.french.php)
(14 files, 15kb)
* Moved registration/reminder text strings to their JS file. Overhauled said file to be much shorter (by around 200 bytes), even after adding the strings. Not that it's gonna be noticeable on your bandwidth meter, but whatever... Every little helps. Plus, I was always put off by that unused index #3 in verification field arrays. Also... Why the heck did I leave these Optimize strings in the JS file, when Packer will always minify them anyway? (Register.template.php, Reminder.template.php, register.js)
* Moved draft removal text string to its JS file. (Class-Editor.php, editor-func.js)
* Rewrote captcha sound to use the generic popup. Also fixed the 'Play again' link to avoid jumping to the top of the page. (VerificationCode.php, Register.template.php, Login.language.php)
* Added placeholder text for e-mail input at registration time. You never know... (Register.template.php, Login.language.php)
! Adding to $context['footer_js'] directly is bad practice, and could even break the feature. Modified all instances to add to a local string and then call add_js with this string as a parameter. (Class-Editor.php, Aeva-Foxy.php, Aeva-Gallery2.php, Display.template.php, PersonalMessage.template.php)
! If a captcha was failed, the second instance wouldn't allow for the sound popup to be run. (Subs-Editor.php)
! Fixed minor typo in French translation. Eh, my bad... (index.french.php)
3665
Archived fixes / Re: Codes appearing while viewing some topics.
« on February 11th, 2013, 09:11 AM »
I actually reproduced the bug locally last night while testing my Register rewrite (I had to log out to test it obviously, and this umme stuff would show up at the end of a Display page.)
I fixed it without committing because I really had plenty of stuff to commit. And still do. And I'm putting the priority on OUAT and TWD this morning. :P
At least I'm relieved to learn that this was introduced only in the latest updates, last night I thought it might have been a long-lived bug, considering I rarely ever log out of my websites...!
I fixed it without committing because I really had plenty of stuff to commit. And still do. And I'm putting the priority on OUAT and TWD this morning. :P
At least I'm relieved to learn that this was introduced only in the latest updates, last night I thought it might have been a long-lived bug, considering I rarely ever log out of my websites...!
3666
Features / Re: New revs
« on February 10th, 2013, 04:17 PM »
rev 1912 -- Bytenazi vs the world.
(10 files, 27kb)
+ Added support for @if/@else/@endif to JS files. No @elseif because there are only two possible states right now, guest and member. As you can imagine, this allows you to have your JS file only print whatever code is written for guests or members. For instance, removing the cookie code for members saved about 50 bytes, and removing objects related to non-guest permissions (Thought, auto-draft, quick edit...), saved over 800 bytes in script.js, over 400 bytes in editor-func.js, and over 1500 bytes in topic.js. And I'm talking about gzipped ones. Yaysir. (Subs-Cache.php, editor-func.js, script.js, topic.js)
@ Note that you don't have to indent code inside @if tags, it's just a personal preference of mine.
* In case I need it later -- and I will, believed me -- added a $supports_flexbox variable to the CSS commons, stating which exact browser versions can use the latest flexible box layout model. (common.css)
* Guests shouldn't be served any code that allows them to quick edit something... That doesn't make any sense. (Display.template.php)
* Merged sCookie with sOptionName into sOption. The idea is that there's no reason not to use the option name as the cookie name, as cookies support underscores and all... The only drawback is that it adds a couple of bytes to guest pages. But you're not going to blame me for that, are you...? Also, who decided that it would be a smart idea to test against guest status in an... admin page?! (Boards.template.php, index.template.php, ManagePermissions.template.php, :edit: script.js...)
* More mini-byte saving, such as: the eves array was indented by one tab too many (how come I never noticed..?!), and I removed the generator string, which the W3C no longer cares about. Also added a [] fallback to aSwapContainers. It's never needed, but because the other options do that, it actually saves a byte. (index.template.php, Subs-Template.php, script.js)
* I'm a naughty boy... And I've been doing something naughty. It's all in the name of saving trees, mind you. Well, at least if anyone's trying to print out the HTML source code of your forum. Which might happen. Don't deny it. (Subs-Template.php)
(10 files, 27kb)
+ Added support for @if/@else/@endif to JS files. No @elseif because there are only two possible states right now, guest and member. As you can imagine, this allows you to have your JS file only print whatever code is written for guests or members. For instance, removing the cookie code for members saved about 50 bytes, and removing objects related to non-guest permissions (Thought, auto-draft, quick edit...), saved over 800 bytes in script.js, over 400 bytes in editor-func.js, and over 1500 bytes in topic.js. And I'm talking about gzipped ones. Yaysir. (Subs-Cache.php, editor-func.js, script.js, topic.js)
@ Note that you don't have to indent code inside @if tags, it's just a personal preference of mine.
* In case I need it later -- and I will, believed me -- added a $supports_flexbox variable to the CSS commons, stating which exact browser versions can use the latest flexible box layout model. (common.css)
* Guests shouldn't be served any code that allows them to quick edit something... That doesn't make any sense. (Display.template.php)
* Merged sCookie with sOptionName into sOption. The idea is that there's no reason not to use the option name as the cookie name, as cookies support underscores and all... The only drawback is that it adds a couple of bytes to guest pages. But you're not going to blame me for that, are you...? Also, who decided that it would be a smart idea to test against guest status in an... admin page?! (Boards.template.php, index.template.php, ManagePermissions.template.php, :edit: script.js...)
* More mini-byte saving, such as: the eves array was indented by one tab too many (how come I never noticed..?!), and I removed the generator string, which the W3C no longer cares about. Also added a [] fallback to aSwapContainers. It's never needed, but because the other options do that, it actually saves a byte. (index.template.php, Subs-Template.php, script.js)
* I'm a naughty boy... And I've been doing something naughty. It's all in the name of saving trees, mind you. Well, at least if anyone's trying to print out the HTML source code of your forum. Which might happen. Don't deny it. (Subs-Template.php)
3667
Features / Re: New revs
« on February 10th, 2013, 12:32 PM »
rev 1911 -- the bytenazi strikes again.
(12 files, 5kb)
* Rewrote weToggle object to simplify it to death. altExpanded is replaced with the optional toggle-wide (rather than per-state and per-image) opt.title (which is actually never used... but you never know), and msgCollapsed/msgExpanded is completely removed (see below). Also updated upshrink_description to be more generic. (Admin.template.php, Boards.template.php, index.template.php, ManagePermissions.template.php, Packages.template.php, Post.template.php, script.js, stats.js, index.language.php)
* Rewrote Thought object to move all text strings to it. (:edit: script.js)
@ Sometimes, you spend time converting some JS to jQuery and save bytes, and that's all good. One day, you go through the code in a logical manner, and start wondering, why the hell is my HTML being rewritten? Then you realize you blindly ported some code when it could have been removed entirely. Saves something like 20 bytes AND as a freebie we get to integrate the upshrink_description text string, which means it saves an additional 20 bytes or so *per page load*. I nearly fainted.
@ Total overall cost of script.js's new features in this commit: 12 gzipped bytes. The 'click for new thought' string itself is 45 bytes... And HTML pages for members are now shorter by several dozen bytes (weToggler and Thought strings combined).
@ I need my pills.
(12 files, 5kb)
* Rewrote weToggle object to simplify it to death. altExpanded is replaced with the optional toggle-wide (rather than per-state and per-image) opt.title (which is actually never used... but you never know), and msgCollapsed/msgExpanded is completely removed (see below). Also updated upshrink_description to be more generic. (Admin.template.php, Boards.template.php, index.template.php, ManagePermissions.template.php, Packages.template.php, Post.template.php, script.js, stats.js, index.language.php)
* Rewrote Thought object to move all text strings to it. (:edit: script.js)
@ Sometimes, you spend time converting some JS to jQuery and save bytes, and that's all good. One day, you go through the code in a logical manner, and start wondering, why the hell is my HTML being rewritten? Then you realize you blindly ported some code when it could have been removed entirely. Saves something like 20 bytes AND as a freebie we get to integrate the upshrink_description text string, which means it saves an additional 20 bytes or so *per page load*. I nearly fainted.
@ Total overall cost of script.js's new features in this commit: 12 gzipped bytes. The 'click for new thought' string itself is 45 bytes... And HTML pages for members are now shorter by several dozen bytes (weToggler and Thought strings combined).
@ I need my pills.
3668
Features / Every byte is sacred, every byte is good.
« on February 10th, 2013, 11:20 AM »
And here's a topic about my all-time biggest obsession: bytesize reduction through gzip optimization...
Every byte saved after gzipping is a byte that doesn't have to go through the Internet pipes. Meaning it saves energy. Not much, but do you want your website to load fast? Yes? Then every byte saved is a step closer to that reality.
I'll post here any remarks I have regarding my work on this. Or any questions when the byte crunching comes at a possible price.
Here's the first of these cases I'd like to discuss. :edit: Actually, see last paragraph, already solved the first problem by myself, the second one really isn't that important, basically: you may skip this post entirely unless you're interested in exploring the mad psyche of yours truly. :geek:
I've rewritten the Thought class to move all of its text strings to the script.js file. First thing: sSubmit was totally redundant -- never used in the class, I forgot to remove the declaration after replacing it with we_submit. So that one's a freebie -- about 10 bytes saved!
Now, I moved sNoText, sEdit, sReply and sLabelThought to the script file. Since there's only one variable left (the privacy array), I also removed the aPrivacy name, and left it to just the array declaration. That saves a total of about *70 bytes* per gzipped file (80 counting the sSubmit thing). That's a *very* nice score. I'm also
Let's look at script.js now... After adding our text strings (and reordering them for good measure to see if I could save more bytes), I managed to reduce the overhead to about *30 bytes*.
First dilemma: is it worth adding 30 bytes of (a single download) to ALL users (including guests), to save 70 bytes (PER PAGE) for logged in users?
Second dilemma: I added an additional trick to save *25 bytes* per page load for *logged in users* who have *not yet set a thought* (that would represent, I think, a majority of them.) Instead of showing "Click here to set your first thought", I'm showing nothing, and then script.js fills in the text by itself. This adds approximately 8 bytes of overhead to the script file. Is it worth adding a single download of 8 bytes for everyone (including guests) to save 25 bytes per page for a majority of members?
I think that's all for now...
The things to keep in mind are that, (1) all of these strings are located at the bottom of the page, so hypothetically they're not supposed to slow down the page load, but in reality none of the browsers that I know show a 'partial' page when they've received part of the gzip for it, so essentially this is the same as if the text was at the beginning of the page. (2) adding 40 bytes represents about 0.5% of the total script file size. Removing 70 bytes off the homepage accounts for 0.8% of it.
Also, I should use the opportunity to simply suggest adding support for *guest* and *member* JS files... That would solve dilemma number 1 immediately. And a good deal of others. It also technically increases the number of JS files by 2, but it's *nothing* compared to the CSS cache, obviously. Not only that, but I can entirely remove the Thought object for guest files...!
Oh well, I think I'm going to do that... Perhaps I could use some help in finding the equivalent of a @if_guest and @if_member for the JavaScript files..? Woohoo, gonna have some fun... :lol:
Every byte saved after gzipping is a byte that doesn't have to go through the Internet pipes. Meaning it saves energy. Not much, but do you want your website to load fast? Yes? Then every byte saved is a step closer to that reality.
I'll post here any remarks I have regarding my work on this. Or any questions when the byte crunching comes at a possible price.
Here's the first of these cases I'd like to discuss. :edit: Actually, see last paragraph, already solved the first problem by myself, the second one really isn't that important, basically: you may skip this post entirely unless you're interested in exploring the mad psyche of yours truly. :geek:
I've rewritten the Thought class to move all of its text strings to the script.js file. First thing: sSubmit was totally redundant -- never used in the class, I forgot to remove the declaration after replacing it with we_submit. So that one's a freebie -- about 10 bytes saved!
Now, I moved sNoText, sEdit, sReply and sLabelThought to the script file. Since there's only one variable left (the privacy array), I also removed the aPrivacy name, and left it to just the array declaration. That saves a total of about *70 bytes* per gzipped file (80 counting the sSubmit thing). That's a *very* nice score. I'm also
Let's look at script.js now... After adding our text strings (and reordering them for good measure to see if I could save more bytes), I managed to reduce the overhead to about *30 bytes*.
First dilemma: is it worth adding 30 bytes of (a single download) to ALL users (including guests), to save 70 bytes (PER PAGE) for logged in users?
Second dilemma: I added an additional trick to save *25 bytes* per page load for *logged in users* who have *not yet set a thought* (that would represent, I think, a majority of them.) Instead of showing "Click here to set your first thought", I'm showing nothing, and then script.js fills in the text by itself. This adds approximately 8 bytes of overhead to the script file. Is it worth adding a single download of 8 bytes for everyone (including guests) to save 25 bytes per page for a majority of members?
I think that's all for now...
The things to keep in mind are that, (1) all of these strings are located at the bottom of the page, so hypothetically they're not supposed to slow down the page load, but in reality none of the browsers that I know show a 'partial' page when they've received part of the gzip for it, so essentially this is the same as if the text was at the beginning of the page. (2) adding 40 bytes represents about 0.5% of the total script file size. Removing 70 bytes off the homepage accounts for 0.8% of it.
Also, I should use the opportunity to simply suggest adding support for *guest* and *member* JS files... That would solve dilemma number 1 immediately. And a good deal of others. It also technically increases the number of JS files by 2, but it's *nothing* compared to the CSS cache, obviously. Not only that, but I can entirely remove the Thought object for guest files...!
Oh well, I think I'm going to do that... Perhaps I could use some help in finding the equivalent of a @if_guest and @if_member for the JavaScript files..? Woohoo, gonna have some fun... :lol:
3669
Features / Re: New revs
« on February 9th, 2013, 09:06 PM »
rev 1910 -- nothing interesting for normal human beings, you can skip that one!
(7 files, 4kb)
* Naoism: Optimized (very slightly) the likePost function and saved about 15 bytes. Thanks to function reordering, the filesize is only increased by 30 bytes ;) (topic.js)
* Naoism: Got inspired by the above, and renamed both $.get calls to $.post in the main script file. Saved plenty of bytes, yay. Then I looked into the Ajax code and realized that it was outdated. The 'time' variable wasn't used anywhere anymore. As a result, saved a total of 17 bytes. (script.js, JSOption.php)
* Naoism: A few minor modifications to the homepage intro. (Home.template.php, Home.language.php)
* Naoism: the current convention in JS files is to only have objects be capitalized, rather than function names. (Msg.template.php, topic.js)
@PS to Pete: no need to apologize, optimizing is my hobby :P I love doing that. Also, implementing Ajax here was surprisingly easy, as I can see! And the magic of gzipping makes it that your .replaceWith() call is actually better optimized than rewriting with $(target).load() instead!
(7 files, 4kb)
* Naoism: Optimized (very slightly) the likePost function and saved about 15 bytes. Thanks to function reordering, the filesize is only increased by 30 bytes ;) (topic.js)
* Naoism: Got inspired by the above, and renamed both $.get calls to $.post in the main script file. Saved plenty of bytes, yay. Then I looked into the Ajax code and realized that it was outdated. The 'time' variable wasn't used anywhere anymore. As a result, saved a total of 17 bytes. (script.js, JSOption.php)
* Naoism: A few minor modifications to the homepage intro. (Home.template.php, Home.language.php)
* Naoism: the current convention in JS files is to only have objects be capitalized, rather than function names. (Msg.template.php, topic.js)
@PS to Pete: no need to apologize, optimizing is my hobby :P I love doing that. Also, implementing Ajax here was surprisingly easy, as I can see! And the magic of gzipping makes it that your .replaceWith() call is actually better optimized than rewriting with $(target).load() instead!
3670
Features / Re: New revs
« on February 9th, 2013, 04:43 PM »
rev 1908
(1 file +1-1, 95kb)
* Updated jQuery 1.9 branch to v1.9.1, it saves 250+ gzipped bytes, me likey. It also adds the responseXML bug that I reported (and had fixed) in the upcoming v1.9.2, which isn't a problem because I fixed it on my side a few commits ago. (Load.php, jquery-1.9.*.min.js)
(1 file +1-1, 95kb)
* Updated jQuery 1.9 branch to v1.9.1, it saves 250+ gzipped bytes, me likey. It also adds the responseXML bug that I reported (and had fixed) in the upcoming v1.9.2, which isn't a problem because I fixed it on my side a few commits ago. (Load.php, jquery-1.9.*.min.js)
3671
Features / Re: New revs
« on February 9th, 2013, 04:42 PM »
rev 1907
(1 file, 2kb) (for a day's worth of work, really? Not well paid :P)
! Choosing to merge jQuery with script files *and* not minify JS files would result in a JavaScript error. This was technically fixed in jQuery 1.9.1 (not 2.0b1 though), but it doesn't matter, I should have done that before. Also added a quick hack to remove // comments on a file's last line (which could generate that bug), even though it wasn't needed, I'm not going to take any chances. (Subs-Cache.php)
* Ensuring that if inheritance causes a skeleton's block to receive the same operation multiple times, the last one should override the previous ones. For instance, if you're going to rename it, the following occurrence might not know of the new name... I'd rather always prioritize the latest request. (Subs-Cache.php)
* Now allowing for custom.xml to be loaded even if no skin.xml is found in the folder, you can even override its type but that would be unwise. Also, it now supports skeleton.xml hacks. Likewise, don't abuse it! (Subs-Cache.php)
* Naoism: some double quotes were used in preg replacements, and they were not always needed. Especially that "$1/*" one... Seriously?! (Subs-Cache.php)
(1 file, 2kb) (for a day's worth of work, really? Not well paid :P)
! Choosing to merge jQuery with script files *and* not minify JS files would result in a JavaScript error. This was technically fixed in jQuery 1.9.1 (not 2.0b1 though), but it doesn't matter, I should have done that before. Also added a quick hack to remove // comments on a file's last line (which could generate that bug), even though it wasn't needed, I'm not going to take any chances. (Subs-Cache.php)
* Ensuring that if inheritance causes a skeleton's block to receive the same operation multiple times, the last one should override the previous ones. For instance, if you're going to rename it, the following occurrence might not know of the new name... I'd rather always prioritize the latest request. (Subs-Cache.php)
* Now allowing for custom.xml to be loaded even if no skin.xml is found in the folder, you can even override its type but that would be unwise. Also, it now supports skeleton.xml hacks. Likewise, don't abuse it! (Subs-Cache.php)
* Naoism: some double quotes were used in preg replacements, and they were not always needed. Especially that "$1/*" one... Seriously?! (Subs-Cache.php)
3672
Features: Security / Re: Bad Behavior
« on February 8th, 2013, 11:40 PM »I think what will be far simpler is to just go through and review the features added/removed by comparison to SMF at the end, heh.
"It is only with the heart that one can see rightly; what is essential is invisible to the eye." (Le Petit Prince)
I will add the mod filters item to the Features board, meant to do it already.
Anyway... Time for bed. I did well today.
3673
Features / Re: New revs
« on February 8th, 2013, 11:19 PM »
rev 1906 -- XML skeleton operations
(5 files +1, 30kb)
+ Added skeleton operations to skeleton.xml files: move, rename and remove blocks/layers within any skeleton. More to come..? Right now, skin.xml move operations will not work, I'm trying to determine what's the best file to put them in. Also, operations are now found through a more generic function, so eventually I should be able to allow for all regular skeleton operations to be used in the XML files. (Class-Skeleton.php, Load.php, Subs-Cache.php)
* Moved Msg skeleton template functions to their own template. Well, at least it's funny, it gave me the opportunity to confirm that Wedge can perfectly call loadTemplate twice in a row... (Display.php, Display.template.php, Msg.template.php)
- Forgot to remove a useless param. (Class-Skeleton.php)
(5 files +1, 30kb)
+ Added skeleton operations to skeleton.xml files: move, rename and remove blocks/layers within any skeleton. More to come..? Right now, skin.xml move operations will not work, I'm trying to determine what's the best file to put them in. Also, operations are now found through a more generic function, so eventually I should be able to allow for all regular skeleton operations to be used in the XML files. (Class-Skeleton.php, Load.php, Subs-Cache.php)
* Moved Msg skeleton template functions to their own template. Well, at least it's funny, it gave me the opportunity to confirm that Wedge can perfectly call loadTemplate twice in a row... (Display.php, Display.template.php, Msg.template.php)
- Forgot to remove a useless param. (Class-Skeleton.php)
3674
Features: Security / Re: Bad Behavior
« on February 8th, 2013, 11:02 PM »But there are other neat tools that you can use, actually. We have the moderation filters system, which lets you moderate or even simply reject posts that contain certain words, and be selective about it.
I remember I built that board topic list out of a long study of commits 1-700 or 1-750 approximately, meaning there are currently up to 1200 undocumented commits that contain many features we never advertised on these boards...
I'm not suggesting that anyone gets to work and builds a list of extra features... But we'll definitely have to do it at some point. :-/
3675
Features / Re: Mini-skeletons
« on February 8th, 2013, 10:59 PM »
Added support for <move> on any skeleton, but also for <rename> and <remove>... Dunno what else I should support...
Also, I decided to have these commands in skeleton.xml instead of skin.xml, but I'm not sure what's best.
Wedge loads all skeleton.xml files (parents and children), from root to deepest level, and concatenates them. It doesn't care about 'replace' type items, mostly out of laziness. skin.xml is loaded but also deleted everytime it finds a new child skin.xml... I don't really know which is the best 'behavior'... Perhaps I should even drop support for replace-type skins... But I'm not confident that Weaving is simple enough to accomodate for everything. Meh...Quote from Arantor on February 8th, 2013, 09:38 PM Oh, you mean that... No, I just meant showing a list of links to the posts, each pointing to them 'in context'.Quote I never saw it as limited... But then again, you're the specialist.. :^^;:Quote Or maybe have two types of child skeletons, like in permissions... a copy type, and an extend type. copy = independant, extend = uses the same stuff as its parent(s).
I can already feel the headache coming up... Ahh... Ahhh... Yes it's here.Quote I won't insist, all right... :^^;:
Mine has only been interesting by the fact that Milady is travelling with a friend and thus I had all the time I needed to take matters in hand and finish the mini-skeleton system... Which would have probably stalled otherwise... :whistle:
Also, I decided to have these commands in skeleton.xml instead of skin.xml, but I'm not sure what's best.
Wedge loads all skeleton.xml files (parents and children), from root to deepest level, and concatenates them. It doesn't care about 'replace' type items, mostly out of laziness. skin.xml is loaded but also deleted everytime it finds a new child skin.xml... I don't really know which is the best 'behavior'... Perhaps I should even drop support for replace-type skins... But I'm not confident that Weaving is simple enough to accomodate for everything. Meh...
The concept of displaying an individual post on its own is nothing new - vB did it (I assume it still does but the train wreck since vB 4, I have no idea what it does and does not do any more)
No. Bans are for getting rid of people. Warnings are for less serious matters, behavioural correction. The current warning system is a bit limited.
Well, such behaviour is fine if it is documented, especially if there is a given actual use in the core.
I can already feel the headache coming up... Ahh... Ahhh... Yes it's here.
Today has been... interesting.
Mine has only been interesting by the fact that Milady is travelling with a friend and thus I had all the time I needed to take matters in hand and finish the mini-skeleton system... Which would have probably stalled otherwise... :whistle: