-
(I decided I'd make this into a general purpose topic about my stupid micro-optimizations :P)
I had a look at addLoadEvent() in Wedge, and I can confirm that none of the calls use a string format at all. Heck -- it's actually used only 3 times in the entire codebase by now: to resize avatars on the fly, to resize images when clicking them, and to fix the code box sizes in FF, WebKit and IE. This last one I don't think even deserves being called through .load() but simply directly... Heck, I don't even know if the bug is still a valid one!
Thus, it even seems a bit odd to be using it when we could simply call $(window).load, although it's two bytes longer, but well, it also saves a function alias and declaring the function to begin with in script.js :P
Of course there's the possibility of modders calling addLoadEvent themselves, but... err... Since we're not compatible anymore... Maybe it'd be time for them to determine whether they want to use add_js() or DOMContentReady instead (i.e. anything that doesn't require images to finish loading...)
What do you think?
-
I've used addLoadEvent before but now that I think about it, it'd probably be OK with just the add_js stuff.
Put it this way, is there a compelling reason to keep it as it is? Does it perform a task that cannot be accomplished in another way? It sounds to me is though there is no task that it does that can't be done another way.
-
addLoadEvent, as of now, is simply an alias to $(window).load(), which also carries the task of converting a string into a function (through new Function()). I was parsing the script.js file through JSHint (not JSLint) and wanted to fix a few of the notes (although on a performance note, this doesn't help at all so I won't use JSHint on all scripts in the end), and it did point out that Function() was compiled at execution time, and that it was bad, etc etc. So I went and looked for addLoadEvent calls, and it turned out I'd already converted all strings to functions, so this was only left in as emulation code. However, *Wedge is friggin' not compatible with SMF* to begin with. So I don't really see the point in having this function anymore... I'd rather encourage the use of other solutions ;)
-
Then encourage use of other solutions and mash it with a hammer until you feel better :)
-
Eheh.
Posted: August 5th, 2011, 05:27 PM
(Committed in rev 907.)
-
I like hammers.
-
Whilst I'm not familar with the functions you mention as alternatives IIRC the addLoadEvent was added because of pages with multiple triggered events.
The function was meant to enable modders to use so they stay clear from domcontentready or onload events.
-
$(window).load(function) is really a jQuery way of adding a load event to the onload queue. So it effectively solves the multiple trigger issue ;)
Basically, anywhere I can use jQuery, I'll try to use it. (Except on performance critical functions. But I have yet to see a real one in SMF/Wedge :P)
Hey Karl, I was just working on your PM! I've got a large backlog of long PMs and posts to answer to... Can't work... ahhh >_<
-
On my to-do list is a rewrite of the forum version code...
The issue is that it's pretty messy. It's using $forum_version and WEDGE_VERSION (SMF_VERSION) to begin with. $forum_version is never redefined, so I don't see why we couldn't use WEDGE_VERSION everywhere. The only time it's defined out of the usual index files is in install.php where it's set when the recycle bin is enabled (???), and only used once, when it could just as well have used $current_wedge_version... Uh.
Now, $forum_version uses the format "forum version", rather than "version", while the const is just "version". Looking at the code, in most places $forum_version is actually parsed to remove the Wedge at the beginning... I really, really don't see the point in having Wedge in the name. What's it for? We're the only ones setting it, it's not like it's going away.
So... I'd suggest we (I) transform all $forum_version code to use just a version number. I've already done part of it. I'm also considering pushing it further and using WEDGE_VERSION instead, although the const could just as well be removed -- it's always defined, but never used once, except in upgrade.php which won't be used by Wedge anyway (uh.) Vars are slightly faster than consts, but it's not noticeable because it's not used in loops obviously.
-
Pete? A partial answer would be fine ;)
-
Sorry, been limited on internet today.
I believe version emulation is the reason for it, that it has to be in a variable in order for it to work as currently implemented, plus the old copyright check.
I agree that just storing the version number (i.e. 0.1) in the constant is all that's actually needed, and we can insert 'Wedge' into the copyright string itself normally.
I'm still not convinced that constants are slower than variables, the only evidence I've seen for that is a claim to that effect without any real benchmarking to prove it, and even my own limited benchmarks don't seem to validate it being slower - if you're not throwing it around between scopes, and referencing it in only one major place per page load, the saving of not declaring both a variable and a constant should outweigh any performance issues from a constant, especially since that's the ideal context for using such a thing...
-
- Did my own benchmark... Constant is faster for me, too, by about 15%.
- Haven't seen anywhere where $forum_version is redefined. As for package emulation, it first stores the version into $context['forum_version'] and then redefines it.
Going for the constant, then...! :)
Posted: August 6th, 2011, 11:33 PM
Just FYI -- code is cleaner now. Having no issues.
I noticed, however, that the 'detailed versions' admin page was broken. Is it also broken in the current dev?
This is due (among other things) to jQuery not supporting $('#randomidwithaperiod.likethis') as an ID name. Had to escape the period. Also, dozens of recently added files were not in the full list of files.
Honestly though -- I don't really see the point of retrieving a version Id for all files in the list. Is it to avoid forcing admins to upload all of their files again when just a few have changed? It's just annoying -- not updating the version number list, but updating the file list remotely!
-
Honestly though -- I don't really see the point of retrieving a version Id for all files in the list. Is it to avoid forcing admins to upload all of their files again when just a few have changed? It's just annoying -- not updating the version number list, but updating the file list remotely!
I'm inclined to think that maybe it could be ripped out.
-
Here's the thing: I don't really see ourselves updating the file version manually on each upgrade ('did I update that file since the last update? I'll check against the last copy...'). It's tedious and will definitely be on our list of 'annoying things that don't encourage us to do early & frequent releases'. I'd rather we do a mass update on @version 0.1 to @version 0.2 etc...
So, basically, forcing people to reupload all files should they want to check all file versions in that area, doesn't seem like a big deal to me.
Or we could have Wedge auto-update its files itself, though some magical device... Although it wouldn't work on servers where the Apache owner can't overwrite files from the FTP owner ('nobody'? Or something else. Ayway. It's not like it happens everywhere.)
Why the heck am I awake and working at 7am on a Sunday...?!
-
No, they don't have to upload all the files; the check is simply to validate whether what they have is the current version, since only the files that changed get new version numbers - if you're producing what amount to diff patches, it's trivial to add in the file versions.
To illustrate, I dug out the 1.1.12 install I had laying around. I'm not sure why I had it laying around but I did, and as it happens, it also has Aeva installed. It's not a patched version, it was installed as 1.1.12.
The results of the version check are as follows: (just keeping to sources to make the point)
| Admin.php | 1.1.6 | 1.1.6 |
| Aeva-Admin.php | ?? | ?? |
| Aeva-Admin2.php | ?? | ?? |
| Aeva-Admin3.php | ?? | ?? |
| Aeva-Embed.php | ?? | ?? |
| Aeva-Exif.php | ?? | ?? |
| Aeva-Gallery.php | ?? | ?? |
| Aeva-Gallery2.php | ?? | ?? |
| Aeva-Media.php | ?? | ?? |
| Aeva-ModCP.php | ?? | ?? |
| Aeva-Sites-Custom-Example.php | ?? | ?? |
| Aeva-Subs-Vital.php | ?? | ?? |
| Aeva-Subs.php | ?? | ?? |
| BoardIndex.php | 1.1.11 | 1.1.11 |
| Calendar.php | 1.1.5 | 1.1.5 |
| Display.php | 1.1.11 | 1.1.11 |
| DumpDatabase.php | 1.1.12 | 1.1.12 |
| Errors.php | 1.1 | 1.1 |
| Help.php | 1.1 | 1.1 |
| Karma.php | 1.1.5 | 1.1.5 |
| Load.php | 1.1.11 | 1.1.11 |
| LockTopic.php | 1.1 | 1.1 |
| LogInOut.php | 1.1.6 | 1.1.6 |
| ManageAttachments.php | 1.1.11 | 1.1.11 |
| ManageBans.php | 1.1.10 | 1.1.10 |
| ManageBoards.php | 1.1.2 | 1.1.2 |
| ManageCalendar.php | 1.1.11 | 1.1.11 |
| ManageErrors.php | 1.1 | 1.1 |
| ManageMembergroups.php | 1.1.4 | 1.1.4 |
| ManageMembers.php | 1.1.11 | 1.1.11 |
| ManageNews.php | 1.1.5 | 1.1.13 |
| ManagePermissions.php | 1.1.11 | 1.1.11 |
| ManagePosts.php | 1.1 | 1.1 |
| ManageRegistration.php | 1.1.10 | 1.1.10 |
| ManageSearch.php | 1.1.12 | 1.1.12 |
| ManageServer.php | 1.1.5 | 1.1.5 |
| ManageSmileys.php | 1.1.12 | 1.1.12 |
| Memberlist.php | 1.1 | 1.1 |
| MessageIndex.php | 1.1 | 1.1 |
| ModSettings.php | 1.1 | 1.1 |
| Modlog.php | 1.1.11 | 1.1.11 |
| MoveTopic.php | 1.1 | 1.1 |
| News.php | 1.1.12 | 1.1.12 |
| Notify.php | 1.1 | 1.1 |
| PackageGet.php | 1.1.12 | 1.1.12 |
| Packages.php | 1.1.11 | 1.1.11 |
| PersonalMessage.php | 1.1.10 | 1.1.10 |
| Poll.php | 1.1.11 | 1.1.11 |
| Post.php | 1.1.11 | 1.1.11 |
| Printpage.php | 1.1 | 1.1 |
| Profile.php | 1.1.11 | 1.1.11 |
| QueryString.php | 1.1.9 | 1.1.13 |
| Recent.php | 1.1.5 | 1.1.5 |
| Register.php | 1.1.10 | 1.1.10 |
| Reminder.php | 1.1.6 | 1.1.6 |
| RemoveTopic.php | 1.1.5 | 1.1.5 |
| RepairBoards.php | 1.1 | 1.1 |
| Reports.php | 1.1 | 1.1 |
| SSI.php | 1.1.7 | 1.1.13 |
| Search.php | 1.1.5 | 1.1.13 |
| Security.php | 1.1.9 | 1.1.9 |
| SendTopic.php | 1.1 | 1.1 |
| SplitTopics.php | 1.1.11 | 1.1.11 |
| Stats.php | 1.1.6 | 1.1.6 |
| Subs-Aeva-Sites.php | ?? | ?? |
| Subs-Auth.php | 1.1.11 | 1.1.11 |
| Subs-Boards.php | 1.1.11 | 1.1.11 |
| Subs-Charset.php | 1.1 | 1.1 |
| Subs-Compat.php | 1.1.6 | 1.1.6 |
| Subs-Graphics.php | 1.1.11 | 1.1.11 |
| Subs-Members.php | 1.1.9 | 1.1.14 |
| Subs-Package.php | 1.1.12 | 1.1.12 |
| Subs-Post.php | 1.1.9 | 1.1.9 |
| Subs-Sound.php | 1.1.6 | 1.1.6 |
| Subs.php | 1.1.11 | 1.1.13 |
| Themes.php | 1.1.11 | 1.1.11 |
| ViewQuery.php | 1.1 | 1.1 |
| Who.php | 1.1 | 1.1 |
This is what the system's designed for - each version only the changed files ever get updated and even in a quick release cycle this isn't necessarily a bad thing. And when you only change the headers on those files that updated, it means you can very easily see what's not been patched yet.
That said, the reality is that it isn't a lot of use because of file edits and if people do get into trouble they're often advised to simply upload fresh copies of everything. In our case the intention is that we'd do even more of that because we're aiming for less need of file editing. Perhaps it should just go after all.
-
A suggestion. Maybe we could store the md5 for all files *minus* the file version (i.e. we take the file, and substr it to after the @version line, or just remove the comments), and check them against the latest database...? That way, we can modify the version number in one go, but if the file contents themselves are the same, we're good to go. Another perk of this would be that if users had their files corrupted at upload time, they'd be noticed immediately.
Of course it can be seen as an annoyance that were the files to be modified by add-ons, we'd never be able to get their proper md5. But maybe it's a path to explore...?
-
I'm inclined not to bother; the more I think about my experiences supporting SMF, the more I was inclined not to ever ask for it when provided simply because I don't think it made a lot of difference.
It's only really useful in the core if we provide patches, I think, and if we don't provide patches there's not a lot of value in keeping the complete list of files and versions (or signatures) - not in the core anyway.
That said, there is the validity of providing such for part of a diagnostic tool, but then you'd probably want to keep all the different versions then but not in the core, and it could flag up that a file has been changed.
In fact, could go one step further - as part of an add-on's install if it requires (and is permitted to perform) raw edits, we could do md5 before and after and store that somewhere so that we do have the signature available for testing.
But I think we can ditch it from the core to be honest. It's less code there that's really going to help us.
-
When writing the smf patches it was always a pain in the backside to have to change the header version no. for every file altered. And often one might get forgotten.
If the version was set at the top of the patch, the program should automatically update the version info at the top without having to code the find/replace statement.
-
Wondering about the database tables...
I was looking into them, and found an awful lot of INTs (small, tiny, etc.) that are not unsigned, even though they're assigned to things like id_* where you rarely get a negative number (only on a few exceptions.)
Shouldn't we change these to unsigned...? Or whatever?It's only really useful in the core if we provide patches, I think, and if we don't provide patches there's not a lot of value in keeping the complete list of files and versions (or signatures) - not in the core anyway.
OTOH, maybe files shouldn't get a @version at all, in these conditions. I mean, if we set up a system where users can automatically update their files to the latest version, based on their Wedge version and ours, we don't want them to have files with 'outdated' version numbers. (Of course if we remove the version check, they won't see that in the admin area, but that might still look odd if they open the files manually.)
(Or we just don't care and leave files with their old version numbers.)In fact, could go one step further - as part of an add-on's install if it requires (and is permitted to perform) raw edits, we could do md5 before and after and store that somewhere so that we do have the signature available for testing.
-
Shouldn't we change these to unsigned...? Or whatever?
Tinyint, smallint and mediumint can all be safely made unsigned if the values never go negative.OTOH, maybe files shouldn't get a @version at all, in these conditions
-
Working on a lot of JavaScript optimizations right now...
I think that the editor code (in the HTML) should be tighter. Not that it's going to change anything on compressed files, but if for any reason your server is not sending gzipped data, I've found that my optimizations, while not changing anything to the feature set, actually saves over 3KB... That's not a bandwidth saving I'm going to laugh at, really.
I'm having a couple of issues with one thing though... SMF/Wedge always define images_url in the HTML JS. In Wedge, it is we_images_url. It is only used 3 or 4 times in the entire code, and never for interesting things.
I've been looking at the code for $settings['images_url'], and I can't find any place where it is set to anything else than $settings['theme_url'] . '/images'.
So, my question would be... Can't we just print the we_theme_url variable, and add /images/ to it when needed?
I'm just worried it could be set at some point to $settings['default_theme_url'] . '/images', but I couldn't find it. (I have to say, I'm drowing in micro-optimizations right now... Big commit coming up, eh.)If we can guarantee we never need an unsigned value, we can use that. However int is problematic because unsigned int is an unsigned 32 bit value which runs over the limit of PHP at times (and can be silently switched for a float)
However, I don't feel like checking all INT entries and adding unsigned to them, so if you're not interested with the idea, I guess we can simply forget about it, at least for now...Tinyint, smallint and mediumint can all be safely made unsigned if the values never go negative.
OTOH, maybe files shouldn't get a @version at all, in these conditions
I don't think the actual @version string is of any interest, whether in the program or legally.
-
I'm just worried it could be set at some point to $settings['default_theme_url'] . '/images', but I couldn't find it. (I have to say, I'm drowing in micro-optimizations right now... Big commit coming up, eh.)
So, my question would be... Can't we just print the we_theme_url variable, and add /images/ to it when needed?
Never heard about that... But yeah, I figured the signed stuff must be an oversight on the SMF devs' part.
However, I don't feel like checking all INT entries and adding unsigned to them, so if you're not interested with the idea, I guess we can simply forget about it, at least for now...
I don't think the actual @version string is of any interest, whether in the program or legally.
-
The idea is that you could have a theme whose image folder is something else but the reality is that theme never specifies an actual folder AFAIK (at least not in its own theme-info.xml), but there is a setting actually stored for it.
I'm okay with themers and modders being given abilities to do plenty of things that aren't by default in SMF/Wedge.
It's another thing when you start offering features that they have absolutely no reason to use.
For instance -- if they want to put their image folder into a separate (cookieless) subdomain, it's something that can be done without any changes. You just point the subdomain to that folder... It's what I used to do for Noisen (until I decided I was bored of paying $10/y for a domain name I only used to redirect to static content :P)I don't recall there being any performance issues with it, so I'm not that bothered with fixing it right now, but at some point if we get bored...
If we're not providing patches, there isn't really a great deal of good reason to leave the version number in the files, per se - but there may be a reason that hasn't occurred to us yet to leave them in.
Even if we provide automatic updates through the website, I don't see anything that would require having a version number.
-
Yeah, I guess that makes sense when put like that about the theme dir; but it's something that most people won't ever realise they can do - even if it's something that would be pretty useful in the scheme of things.
That said, there are places in the code that do make the assumption that images_url is just theme_url with /images/ after it, so it wouldn't be a bad idea to make everything consistent - but switching it to use theme_url with images consistently isn't a bad thing, because you can still do that sort of thing; you can move the entire directory for a given theme (sans PHP files) to a separate URL for that reason and just update theme_url.It's not about the performance, rather about doubling the amount of IDs you can suddenly start using...
-
So... Is that a yes as to whether I can use theme_url + /images/? :P
We may want to document that... And maybe simplify the code later on, to ensure we don't go through extra lines of code when we could do things simpler. (More simply... Simplier? Why does my spellchecker underline that word? Heck, why does it underline spellchecker, too? :P)
As for topics and posts, no doubt this should be enough, but I was thinking more about the 'smaller' IDs, like tinyints and smallints, really... Even mediumints are not that worthy of attention.
-
So... Is that a yes as to whether I can use theme_url + /images/?
-
Yes, I think so, since separate subdomain etc is still supportable through that.
-
Then what's the short form of 'more simple'?
-
But it doesn't mean the same thing... It's COMPLICATEDER :^^;:
-
It does mean the same in English.
-
Hmm... In French we have 'plus simple' and 'plus simplement'. They really don't mean the same thing. "It's simpler to do this (c'est plus simple de faire ça)", and "He did it in a simpler way (il l'a fait plus simplement)" or "Simply put, you suck at English (plus simplement, t'es nul en anglais)".
-
Since we often have the same spelling and pronunciation of words for different parts of speech (more can be used as an adjective, an adverb, or (rarely) as a noun), we don't much care about the difference between adjectives and adverbs.
So it is common to see "She spoke quickly, but he spoke quicker than she did", even though it is grammatically incorrect.
http://www.grammarbook.com/grammar/adjAdv.asp
-
UK or US English, out of interest?
-
(American IP.)
-
I was guessing American anyway, but I figured I'd clarify. US and UK English are very interestingly at odds with one another a lot of the time.
-
Stop readin' the Oatmeal, FFS :P
http://theoatmeal.com/comics/minor_differences4
-
Stop readin' the Oatmeal, FFS :P
http://theoatmeal.com/comics/minor_differences4
You forget, though, I'm firmly British and I regularly talk to Americans - and do find myself dealing with the accent barrier and more generally the language barrier. It's not a high barrier but it is a barrier nonetheless.
But for true accent win, get a Brit, an American and a Canadian on the same conference call. ;)
-
I must be even weirder, with my constant mix between US and UK expressions. That's what happens when you learn English mostly from TV shows and the Internet. You tend to hear a bit of both ;)
-
Ha!
Try living with an American in the UK (now naturalised I should point out)... She's infected me with Americanisms, and complains at me when I use them!
I blame the feral fire trucks...
-
I must be even weirder, with my constant mix between US and UK expressions. That's what happens when you learn English mostly from TV shows and the Internet. You tend to hear a bit of both ;)
Try living with an American in the UK (now naturalised I should point out)... She's infected me with Americanisms, and complains at me when I use them!
-
Love your sig, PantsMan :P
-
Love your sig, PantsMan :P
-
Tommy Saxondale FTW - not too keen on much of Steve Coogan's recent works, but there were bits of Saxondale that made me laugh out loud.
-
good ole americanisms.
All the zeds. I mean zee's.
-
Okay, I'm currently looking into doing a mass replace from 'smf_' to 'we_' in the codebase...
There are about 700 occurrences, I'm checking them manually and then I'll do the replacement.
So far so good, but apparently sessions are named smf_sess_*. Do you think it's still okay to replace them? I mean, at the worst it'll reset the session, right...?
Oh, and I know it means we can take even less code verbatim from other versions of SMF... But do we really need to?
-
So far so good, but apparently sessions are named smf_sess_*. Do you think it's still okay to replace them? I mean, at the worst it'll reset the session, right...?
Oh, and I know it means we can take even less code verbatim from other versions of SMF... But do we really need to?
-
It's fine. Yes, it will reset the session.
Other than the base is there anything we'd actually want to take verbatim from SMF anyway? Seems to me as though it's something we neither want or need to worry about.
I mean, it would be a bit dishonest of us to take code from SMF when we're preventing them to use ours...
I guess bug fixes don't fall into this -- if only because I've myself pointed out bug fixes to them for years, and even made the changelog accessible with the list of fixable bugs...
Also. I'm changing define('SMF') to something else. I could use WE: it's shorter. But it would only save ~200 bytes across the entire project, so... Well. As for WEDGE, it's longer, makes us waste an extra 400 bytes, but OTOH I'd rather have the full software name in here. So I'm changing to WEDGE, please tell me if you disagree. Otherwise, no need to reply ;)
-
Pete, just wondering... Did you make sure to remove corresponding $txt variables when you removed tons of features, mainly at the beginning...? Because I still found another unused variable... And I'm starting to wonder if you made the check at all...? Rule of thumb: always check for dependencies when I remove something... :whistle:
Maybe we could, hmm, build some tool that would take all of the $txt variable names and check whether they're used in any template or source file... I'm sure we could remove tons of entries that way!
-
I missed a few but by and large I do remove them as I go, I try to make sure I check at least. Some of the strings you've pulled out lately aren't properly used in SMF either...
I'm sure we could remove tons of entries that way!
-
I missed a few but by and large I do remove them as I go,
I try to make sure I check at least. Some of the strings you've pulled out lately aren't properly used in SMF either...
Bad idea. Quite a few strings are identified programmatically, never directly,
-
We're human, we miss things, it happens. But it's not something that's hell to fix after, fortunately.
Of course, but we could find them anyway. I'd just like for a tool to allow us to narrow down a list of suspects
-
dishonest of us to take code from SMF when we're preventing them to use ours...
I am guessing you will be more proud of your work if you change the constant name, the variable names, and the session name, regardless of the additional work it might cost you in the future. That pride might be a good enough reason to make those changes.
-
As long as you follow the licensing agreement, you are honest.
I'm not disputing that it's not exactly pleasant for us to be taking from SMF without giving something back, but I feel firmly that I gave a lot more to SMF than I've got back from them so far...
-
Yes, we can postpone $txt to later -- but remember how we postponed changing SMF stuff to Wedge for later...? I'm doing it now because I fear I will forget later, and I'd rather have done it before... :P
I'm not disputing that it's not exactly pleasant for us to be taking from SMF without giving something back,
- Several years of work for the SMF community from the both of us. We gave that without getting anything in return. I think at least half of the SMF team agrees that it's only fair to consider we don't owe SMF anything -- and it's the other way around.
- The changelog. It might seem like nothing, but as I said multiple times, it documents the entire list of SMF bugs that we fixed. It's up to the SMF team to process the changelog, analyze what they need changing, and do it themselves. I made over 400 bug reports at Mantis, including many *after* I was post-banned from SMF. I didn't suddenly stop spotting and fixing bugs in SMF... The only difference, now, is that I can't submit them directly to SMF because they removed my beta tester account. And even then, I'm still making the changelog public and thus the list of SMF bugs is now accessible.
- The ideas. We published our feature list months ago, and we're now discussing publicly as much as we can of our current ideas and implementations (just look at this very topic, since we're totally OT here.) Ideas can't be copyrighted. SMF can steal those ideas, we can't do anything about it -- except to take note that they considered our ideas to be good enough to steal them... We own our implementations of these ideas. But they may not even be the *best* implementations of it. (Although, TBH, I don't think the current SMF developer team is up to the task to make better implementations... :whistle:)
So, yeah, I'm sorry but at this point, I can see a lot of things we're giving back to the SMF community.
If all the SMF team wants is *for us to share our code*, then they should have asked us to become the SMF developer team a year ago. Instead, they showed us the way out, indicating they didn't feel the need for our ideas and work.
It's as simple as that... It would be quite preposterous from the SMF team to expect anything more than what we're currently giving them.but I feel firmly that I gave a lot more to SMF than I've got back from them so far...
-
- Several years of work for the SMF community from the both of us. We gave that without getting anything in return. I think at least half of the SMF team agrees that it's only fair to consider we don't owe SMF anything -- and it's the other way around.
-
I could very easily repeat most of what ttForum did, rebranding the software throughout, even released it as a paid package and still be well within the terms of the licence
That's the funny thing about the BSD license. It is not CC-by-SA.
-
Yep. It might not be considered friendly, but it is certainly permitted, and someone might try it one of these days.
That's the funny thing about the BSD license. It is not CC-by-SA
And specifically for the record, if we went CC, I suspect it would be BY-SA-NC.
-
I can *wish* you would use CC-BY-SA-NC, but clearly the choice is yours. I am content to disagree.
-
Heck, given how we're incompatible with current SMF mods, we could even go GPL just to annoy everyone :lol:
-
BSD to the "something like the old SMF license" to GPL. That's something like the SMF/YaBB SE licensing history, in reverse.
-
The change to GPL will occur shortly after the following events all come to pass:
1. GPLv4 is released that isn't hideously virus like in its approach, tainting everything it touches.
2. Richard Stallman steps down from being a hypocritical, misguided zealot.
3. It's the day after the 12th. The 12th of Never.
But it isn't "something like the old SMF licence." It is the old SMF licence with very minor changes, as per http://wedge.org/license/
The irony is that the licence change to a restricted licence is done to protect the code from perceived abuse from other directions.
-
Hey Pete! You're spoiling the fun by publishing the license with our Hall of Shame clause :P
-
Didn't you already post that, though? *confused*
-
TROLOLOLO.
What if my name is that but I'm not that person you're talking about? :(
-
@Ara Blunder> Nope, we never posted it ;) I wanted to leave them the surprise :P
Although it won't be a surprise to anyone, knowing our history with the guys. But still, it's good fun.
@Norodo> Well, if you happen to share both the same name and nickname, then you're banned from here yeah :niark: As for other people... They could simply contact us and request special treatment.
-
Thanks for publishing the license.
I see that it is similar in some respects to the old SMF license, and different too.
Condition 1.e. is of a very unusual type. I have read your reasons for these restrictions. I only wish things could have gone differently.
-
I for one think the conflict has some good points to it. Namely, fiercer competition. :>
Go team [insert preference]!
-
You guys actually got that clause? +Score!
-
@AngelinaBelle, we wish it had been different, but it isn't like we didn't offer the opportunity for amends to be made.
-
Thanks for publishing the license.
I see that it is similar in some respects to the old SMF license, and different too.
(So, basically, the more you help Wedge grow, the faster it gets to a more permissive license :P)Condition 1.e. is of a very unusual type.
I have read your reasons for these restrictions. I only wish things could have gone differently.
Okay, Pete -- back to the topic... I was looking into the wedge_themes table (the per-theme per-user settings), and noticed that there is a 'skin' variable in theme id = 1. I'm a bit in a hurry and should leave and have been unable to find this for now -- could you look into the code (or anyone with svn access) and tell me where this variable is retrieved and used, exactly...? I'm considering either dropping it, or using it more... :P
-
The change to GPL will occur shortly after the following events all come to pass:
1. GPLv4 is released that isn't hideously virus like in its approach, tainting everything it touches.
2. Richard Stallman steps down from being a hypocritical, misguided zealot.
1. Well yes xenophobic/discriminatory. I couldn't have described GPL in practice better myself, although theoritically speaking I did initially support the movement. If your not the same licence or compatible with gpl then you deserve to die. (In my opinion GPL which expressed its need for openness, honesty & integrity ends up looking more like the 4th Reich of Nazi Germany.)
2. He's the Julian Assange of the open source community, all ego, wrong in so many ways.
They forget that the
(FSF || Richard Stallman) != Free Open Source Community
-
1. Well yes xenophobic/discriminatory.
From what I gather, Joomla enforces the GPL strictly, which means in their view even LGPL doesn't really fit since LGPL does not 'guarantee the same freedoms' of the software and its uses that the GPL does.
Theoretically, the GPL should be an ideal licence, because it is supposed to ensure that code is produced that everyone can use without restriction on that use. Except that the reality is slightly different: the restriction that is supposed to ensure the freedom of the code is in itself a restriction, meaning that people who have a different idea of freedom, like the BSD people, are in effect kept at arms length simply because they have a different definition of freedom.2. He's the Julian Assange of the open source community, all ego, wrong in so many ways.
The debate I read recently was about him lambasting the OpenBSD people for not conforming to his views on 'free' software. I'm not fully conversant with OpenBSD, but I gather there is a ports area in the repository that links to external software where people can go to get things, and he takes the view that having such things in the base distribution (*links* to non-free software) is promoting their use, which it isn't. Then he completely ignores the fact that the same basic argument is levied against Emacs, which has code in it specifically to engender it running on non-free platforms. His argument is that if you don't encourage people to use free platforms, you're somehow wrong - which is sort of blown out of the water with Emacs. (Since if he were holding true to his line of argument, Emacs wouldn't be provided on Windows, when in fact it has a bunch of code in the core to make it run on Windows.)(FSF || Richard Stallman) != Free Open Source Community
-
I had a post above. Sob.
-
You did, yes, and I thought glancing at your latest commit you'd answered that question.
Okay, Pete -- back to the topic... I was looking into the wedge_themes table (the per-theme per-user settings), and noticed that there is a 'skin' variable in theme id = 1. I'm a bit in a hurry and should leave and have been unable to find this for now -- could you look into the code (or anyone with svn access) and tell me where this variable is retrieved and used, exactly...? I'm considering either dropping it, or using it more...
Presumably, a user should be able to pick any skin from any currently available theme? (Assuming admins allow them to choose) If that's the case, does it need to remember which skin within a given theme that a user picked?
i.e. if you have two actual themes, and two skins in each (Themes 1 and 2, skins A & B, giving you 1A, 1B, 2A, 2B), when the user picks a skin from 1 (say 1B when 1A is default), then switches to 2 (either), should the fact they picked 1B be remembered if they come back to 1 later?
I'm inclined to think not, which without looking over finer points, seems to me to suggest we don't need it and only need to bother with what the user currently has selected, i.e. in their record in the members table.
-
Okay, here's how I envision the thing...
Theme 1
Skin A (root)
Skin B (add-type)
Skin C (replace-type)
As you may have seen in the new revs, this is now represented as such in the pick theme page:
Theme 1
Skin A
Skin B
Skin C
Which makes more sense than having Skin C as a child of Skin A (or Skin B as a root skin, like it used to be.)
Now, Wedge allows you to choose the default *theme + skin* combination for the forum, for guests (so that the forum would be using Theme 1B by default for instance). With the variables $modSettings['theme_guests'] (already in SMF) and $modSettings['theme_skin_guests'] (new to Wedge.)
Thing is, if admin adds Theme 2, which itself has 3 color variations... What if they want a secondary variation to be the default when users choose Theme 2 for themselves?
- Wedge doesn't implement the ability to choose a default skin for a non-default theme, because SMF doesn't have 'skins' per se, and as such, there's nothing else to choose from, apart from the theme ID...
- Adding the ability to choose a default skin for a secondary theme might be overkill. In terms of UI, it could be more complicated than necessary, add clutter to the admin area's theme page.
- I think the most logical solution would be to keep the situation where the admin can choose a default theme+skin, but outside of this one, if users choose another theme, they'll get the root skin for it (except, of course, if they directly choose another skin within the theme.)
The goal really is to both maintain simplicity for users, and customizing for admins.
Again, as such, I have no idea what that 'skin' variable is for, in the {db_prefix}themes table. I probably added it at the beginning of my experiments, and forgot to remove it later when I simply had a fallback to the skins (root) folder...
-
- I think the most logical solution would be to keep the situation where the admin can choose a default theme+skin, but outside of this one, if users choose another theme, they'll get the root skin for it (except, of course, if they directly choose another skin within the theme.)
* admin can choose a default theme+skin
* user can choose a theme+skin for themselves (if it's turned on, otherwise they have what the admin says to have) - and this is remembered.
It doesn't really matter so much how it works internally, as long as the user can pick a theme (and a skin within it, if appropriate) and it remembers it. If a user changes to another theme but doesn't pick a specific skin, the default is fine.
Really, we're not talking about anything different to the case of SMF themes + their variants.
-
@above> Uh, I hope this is working by now... :P Haven't looked into the code for a while... And I still have to finish moving the 'change skin' setting to the menu.
Okay, I'm looking into parse_bbc() and I'm micro-optimizing it... It's surprising the number of things that were left hanging, such as "strlen($possible['tag'])" being used a dozen times inside a *loop*. Or "1 + strlen(..) + 1". I understand it's done for clarity, but inside a loop, over time, it still wastes time adding 1 and 1 when it could just be using 2...
Now, I also found a surprising amount of substr($something, $somepos, 1) instead of just $something[$somepos]. It's stunning, really. Now, if substr is overloaded to behave like mb_substr, I can understand the use of the first, but it's never done by SMF so obviously it could simply use the bracket version...
I seem to remember potential problems in future versions of PHP with the bracket version. Do you remember anything about that, Pete?
-
but it's never done by SMF so obviously it could simply use the bracket version...
I seem to remember potential problems in future versions of PHP with the bracket version. Do you remember anything about that, Pete?
-
Just as I thought, thanks. I just couldn't find docs about that. :)
-
yeah i remember fixing the above in smf as we used it in a few places.
-
I was doing some benchmarks on serialize() and json_encode(), and found that json_encode() was about 50% faster... Nice. I was already preparing to use it instead of serialize() in cache_put_data(), but then I benchmarked unserialize() and json_decode(), and this time json_decode is about 40% slower... Duh!
I suppose this puts an end to my little idea, eh? I mean, I suppose it's more vital to have a fast cache decoder than a fast cache encoder. What do you think? (Maybe you have different results?)
-
I have had different results in the past. It really depends on the content type as to whether JSON decoding will be faster.
My test data was 2-3 levels deep of arrays, where the final level would be an array of numbers. It's definitely faster decoding (indexed) arrays of numbers than anything that involves strings, I can definitely tell you that.
Fast decoder is more important than fast encoder, certainly.
-
Cache vars mostly use single-dimensional string arrays so it sounds like json_decode is at a disadvantage here.
Too bad, I liked the fact that it made for such sort cache vars, too :)
-
BTW I totally broke the editor with a last minute change (around the 'last minute header' line, the irony :lol:), it's just missing a parenthesis, I'll commit that next of course, but it'll have to wait until the template code is ready...
Oh, and I've removed support for 'theme_layers'. It's become a non-issue since the introduction of the skeleton. All in all, I think the code overhead is pretty much on par with the template_layer feature.
-
I guess I've never appreciated the difference between your skeleton and template layers.
Now, I see your comment that your skeleton can be multi-branched.
I've recently been arguing that this is a necessity for doing a Portal/CMS type of thing -- you need to go down, come up, close out a "box" start a new "box", and go down layers again....
-
It's a necessity not just for a portal or CMS but for plenty of other things, WedgeDesk already makes use of the earlier partial implementation, after emulating parts of itself before.
-
Very interesting. Does the earlier SimpleDesk do this, as well?
-
Sure, it emulates things with template layers, but WedgeDesk can do bits of it more cleanly, where it can inject blocks into the sidebar, and will do more once the skeleton structure is in place.
-
Layers have always been frustrating... And one-dimensional.
I can't believe SMF got away with it for so many years -- unlimited nested layers, but only one sub-template in the entire page...! It's one of the first things we changed in Wedge -- adding support for multiple sub-templates. Although by now, even that sounds a bit limited, now that the skeleton fixes so many things.
Heck -- I no longer have to rely on a hack to support sidebars! NO HACKS! What do you say :lol:
And skins can remove the sidebar altogether without breaking anything. Haven't tested, but it should be doable... (They can also simply move it to the bottom of the screen and re-style the sidebar area to allow for a horizontal layout, of course. I'd recommend that, because getting rid of the sidebar is okay, but its content...? Not so much.)
BTW, I'm currently pondering whether I should rename some of the things in the template system.
Current: Sub-templates. Suggested: Blocks. Rename loadSubTemplate() to loadBlock().
Current: Blocks. Suggested: Macros, or Snippets. Ultimately, a 'macro' better represents what it does: suppress the need for boring repetition of a more-or-less large part of code, allowing for the dynamic replacement of certain values within it.
Well, at least we call these 'macros' in French. Dunno if it's the same in English but it seems to be the case...
-
I can't believe SMF got away with it for so many years
The group ultimately consists of people who had to know about them to get the job done: themers who do anything of substance, portal authors, and the limited hardcore (people like me, Nao, Live, who can justifiably claim to know SMF at a sufficiently deep level).
Because it's such an elite club, it's practically black magic, that people will take the easier route of, like using file edits instead.
Fun fact: there is a mod out there that adds a footer menu. Nice idea, reasonably well done, and done with a template edit, leading to all kinds of hassle.
I suggested more than once that it could (and should) be done with template layers, because that would instantly remove almost all support queries about installation. But no, template edits are seemingly fine... or at least, the suggestion wasn't even dignified with a reply.And skins can remove the sidebar altogether without breaking anything. Haven't tested, but it should be doable...
One would assume themers would likely keep it or provide a space that can be called 'sidebar', so that content which expects to go into it can be diverted there.Well, at least we call these 'macros' in French. Dunno if it's the same in English but it seems to be the case...
I don't know the history of the term that gives you the derivation of pimp, but macro does have linguistic basis as a prefix for 'widening of range', of sorts, hence macro-management is where you manage the very broadest things (as opposed to micro-management where you manage the tiniest details)
-
Re: elite club, we're in agreement... Considering I never understood layers even when working on AeMe (in which they were used by Dragooon, who certainly understood them :P), I'm sure most modders are like me.
Because I analyzed thoroughly index.template.php when I started working on SMF years ago, I can safely say that if a feature is very prominent there, and documented somewhere, it's bound to be better noticed. Which is why I wanted the index template to have a fallback $context['skeleton'], *not* the Wine skin (which would have made more sense, as it is.) I may change my mind later but that's what I though ;)
And it's documented in Warm/skin.xml (which is where I put all of the comments really...), and in the Load and Subs files (hopefully.)
Re: macros, I made the change this morning -- I'm not surprised it was so quick to do. I still have to start work on converting loadSubTemplate() to loadBlock(), but since I do everything manually to avoid errors, this one will be longer... :P
Re: pimp, actually the French 'official' word for pimp is proxénète, and the common word is maquereau (mackerel -- a pimp woman used to be called 'mère maquerelle' a century ago), often shortened to just 'mac'. 'Maquereau' is pronounced exactly the same as 'macro' (the 'r' is pronounced, of course.)
Okay, another one...
I thought long ago of getting rid of all the sSessionId etc in JavaScript and replacing them with a global variable that we'd set up on every page. I don't see any reason for not doing it -- security-wise, it's exactly the same as putting the variables into a function parameter, really... I just wanted to post about the fact that I'm working on it right now -- if you have any issues with this, please get back to me ASAP so that I can revert my work before I commit it ;)
-
Re: pimp, actually the French 'official' word for pimp is proxénète, and the common word is maquereau (mackerel -- a pimp woman used to be called 'mère maquerelle' a century ago), often shortened to just 'mac'. 'Maquereau' is pronounced exactly the same as 'macro' (the 'r' is pronounced, of course.)
-
Well, any place it's accessible from the script is a problem, of course, and making it directly more accessible from the page if it's compromised isn't particularly clever - but at the same time, it's really not an issue because any place that it's *currently* actually used, you can query for the session ID anyway.
All the objects that currently require a session ID are all fed it, they're passed an object going in, which is stored into the object itself - like when a new instance of weToggle is created, one of the parameters given to it is the session, but it's then stored in this.opt. So when you create a new instance of it, you can refer to that object's .opt and get the session, and since there's a weToggle that uses the session on every page for the header...
There isn't really a good method of avoiding it, unfortunately. Either we don't have it and open ourselves up to CSRF type deals, or we do and risk session stealing.
-
@PantsMan> In oral French, 'que' is pronounced like a 'c' (or 'k'), except for the word 'que' itself, where you pronounce the 'e' (as in 'linger'). It's a mute 'e', basically. So maquereau is pronounced mah-crow. ma-q-ro.
Well, any place it's accessible from the script is a problem, of course, and making it directly more accessible from the page if it's compromised isn't particularly clever - but at the same time, it's really not an issue because any place that it's *currently* actually used, you can query for the session ID anyway.
All the objects that currently require a session ID are all fed it, they're passed an object going in, which is stored into the object itself - like when a new instance of weToggle is created, one of the parameters given to it is the session, but it's then stored in this.opt. So when you create a new instance of it, you can refer to that object's .opt and get the session, and since there's a weToggle that uses the session on every page for the header...
There isn't really a good method of avoiding it, unfortunately. Either we don't have it and open ourselves up to CSRF type deals, or we do and risk session stealing.
What would you rather have? Eh...
-
What would you rather have? Eh...
tl:dr; It's the lesser of two evils, but I think having it in the page less will be beneficial overall, it's certainly no less secure in the long run than where we are now.
-
(Then it's settled.)
An amusing one... (Search2.php)
'age' => '((m.id_msg - t.id_first_msg) / CASE WHEN t.id_last_msg = t.id_first_msg THEN 1 ELSE t.id_last_msg - t.id_first_msg END)',
I know CASE is supposed to be pretty fast, but... Faster than MIN()?!
'age' => '((m.id_msg - t.id_first_msg) / MIN(1, t.id_last_msg - t.id_first_msg))',
Wouldn't that be simpler...?
The wonders of mysql....
(Yeah, I'm trying to make sense out of the search system and understand why the fuck it won't sort posts by date like I asked it to... >_<)
-
I know CASE is supposed to be pretty fast, but... Faster than MIN()?!
(Yeah, I'm trying to make sense out of the search system and understand why the fuck it won't sort posts by date like I asked it to... >_<)
-
Testing for equality plus a CASE is probably faster than MIN when you have to apply to every single row in a virtual table, especially one that's on disk because it's a filesorted table. And, possibly, for PGSQL/SQLite compatibility, who knows.
I'll trust you on that but... It means I have to rewrite all of my MIN() and MAX() calls then :P(Yeah, I'm trying to make sense out of the search system and understand why the fuck it won't sort posts by date like I asked it to... >_<)
-
I don't know if that's the case for sure, but that's the only explanation I can come up with. Benchmark it :P
Remember, certain operations apply in certain ways under certain circumstances. This is about the worse possible circumstance to deal with where the odds are stacked against you: you're doing everything on disk, drawing more file I/O that's blocking other requests and so on.
I can only surmise that it's a performance thing, because if it wasn't, MIN would be much more logical.I'm not trying to worry about it as a regular user. You want to know why it's misbehaving. If you tweak those settings, does it behave as expected?
-
- I don't know and I don't want to know, come to think of it... :lol: Good thing you're our DB specialist here :P
- That's the thing: I shouldn't have to tweak any settings... The search engine offers me to sort by 'most recent topics'. It should return the latest messages in order. Perhaps it actually returns the latest topics in order -- i.e. by topic ID instead of msg_id, I haven't checked, but it doesn't work, that's my point... Weights are totally irrelevant here.
- Okay, SMF bugs... While working on fixing a bug of mine (wrong link for new posts), I noticed a few inconsistencies in SMF:
--- in MessageIndex, the new_href link ends with ";topicseen". In Recent.php, these links don't. This needs to be harmonized...
--- the 'href' link is wrong. It ends with a test which, in one case, adds "new" to the URL... It should be "#new", I reckon. I guess that link was never used anywhere.
Any opinions? I have to go eat...
-
topicseen is mostly a legacy item IIRC, if it doesn't affec behaviour, ditch it.
As for new, that one's required. #new anchors the page in the browser, but it won't get you to the right page of a multipage thread, while topic=x.new will get you to the right page.
-
Doesn't topicseen help with performance...?
-
About new, what I mean is that their code basically ends the page with ";topicseennew" instead of ";topicseen#new". The start page is already accounted for at this point.
Since I've never seen a topicseennew link, means the string is built and never used...
-
Doesn't topicseen help with performance...?
But yeah, that looks like the link is built wrong.
-
You don't know? That's a first 8-)
Well, from what I gathered, it updates your session with a list of unread topics. If all topics in a board are read, it marks the board as read (i.e. saves space in the logs.)
I suppose it doesn't do it automatically because it can be expensive in CPU cycles or something like that...
Ah, long time since I found an option we could remove from Wedge: compactTopicPagesEnable. I don't really see the point in having fully expanded page links...?
Posted: September 9th, 2011, 10:46 PM
Bump for message above.
Also: pm_email_notify -- it's set to 0 by default. It seems that this means "never send an e-mail notification". I thought that SMF's default was to send them...? It makes more sense to have this on by default...
-
My understanding was that topicseen is an older item, legacy from 1.1 or somesuch, but I have no idea offhand if that's still the case or not.
And yeah, I think the option can go, no matter how we change the index, I don't see us having fully expanded page indexes in there.
As for pm_email_notify, be careful with this, because there's a separate set of notification preferences buried in the members table and I'm not sure whether that isn't used in preference or not.
The other thing I'd point out is that there are instances in SMF where 0 is incorrectly used, so it's possible that even if the field is the right one, that 0 is the right value for the job.
-
Re: topicseen, I really don't think it's a legacy thing... Its main use is in Display.php, things like this:
// Have we recently cached the number of new topics in this board, and it's still a lot?
if (isset($_REQUEST['topicseen'], $_SESSION['topicseen_cache'][$board]) && $_SESSION['topicseen_cache'][$board] > 5)
$_SESSION['topicseen_cache'][$board]--;
The idea really seems to be about saving extra work for the server.
Re: the option, it will go away then :) Adding to my to do list.
Re: pm_notify, I'm pretty sure my local install is vanilla with respect to that setting, and I can assure you PM notification is disabled for me. Maybe it's because I don't have a mail server on my machine, and Wedge saw it and disabled the feature...? I don't know.
Ahhh, can't bother to look into it now... :(
Another thing now. While looking into topicseen and other things, I noticed a VERY strange thing on my local install and its single topic (sigh). When posting a new message, I'd be brought to the second-to-last message instead. After looking into it, I found a SMF bug. I can reproduce it here.
One of my posts in the topic is actually unapproved (so I can check on styling unapproved posts.) The COUNT that generates $context[start_from] from start=new takes care of that by removing all unapproved posts from the post count, but then... In the meantime, Wedge meets this piece of nasty code:
// Go to the last message if the given time is beyond the time of the last message.
if (isset($context['start_from']) && $context['start_from'] >= $topicinfo['num_replies'])
$context['start_from'] = $topicinfo['num_replies'];
At this point, $context['start_from'] is 20 (according to COUNT(*)) if I have an unapproved post and 19 if I don't.
And $topicinfo['num_replies'] is 18 if I have an unapproved post, and 19 if I don't.
So, no unapproved post = it works.
Unapproved post(s) = it gets reset to < 19 and voilà, the bug happens.
IIRC, num_replies caches the number of actual visible posts for everyone, so it won't take unapproved posts into account, hence the bug. I unapproved a post of mine here and tried /new/#new and was redirected to the second-to-last post, again.
Any suggestions as to how we should fix this...?
I just tried again (posting 2 messages as an 'approvable' account and then logging in as admin, approving the last one...) Did the /new/, and I got redirected to the second-to-last post, i.e. the unapproved one. So it's definitely something that can be reproduced.
- Oh, and a bonus bug... Apparently, when the very last post in a topic is unapproved, the topic won't show up at all on the Message Index. It just shows nothing... :-/ I have to go to the mod area and then follow the link to the unapproved posts.
Funtastic. Today is bug day -- also found YET another bug in IE with white-space crap... Breaks the entire layout in certain conditions. :-/ Spent an hour on this, couldn't find a way to fix.
-
Fixed, BTW... Replaced $topicinfo['num_replies'] with $context['total_num_replies'] - 1, basically. Tried with various situations and it seems to always work.
Now for the IE bug.
Oh, and micro-optimizing more code, as always...
-
Pete, bed time and I haven't found a suitable way to fix this. Can anyone with svn read access give a look into this post under IE8? Either run it from XP if you have it, or Win7 -> run IE9, F12, choose IE8 browser mode.
Note: the bug doesn't happen in IE6/7 but user boxes are completely broken in them... Meh.
Just quote this post and copy the contents after the hr tag below. The text is random content. It's broken in multiple places (entire post overflowing on the right, code tags having a fixed height...)
Bienvenue dans l'installateur du Forum Simple Machines !
Quote splitter. I see what you mean now I've seen it, very clever[/quote]You bet!
[quote author=Nao link=msg=1 date=1289131411]Bienvenue dans l'installateur du Forum Simple Machines ![/quote]Quote splitter. I see what you mean now I've seen it, very clever
Bienvenue dans l'installateur du Forum Simple Machines !
Long URL:
http://www.sainsburys.co.…&isJavaScriptEnabled=true(http://www.sainsburys.co.uk/sol/storelocator/storelocator_detail_view.jsp?bmForm=store_details&back_page_name=showMoreStores&storeid=4930&latitude=53.9641091272&longitude=-1.0868694519&townName=YORK&isJavaScriptEnabled=true)
-
Pete, bed time and I haven't found a suitable way to fix this. Can anyone with svn read access give a look into this post under IE8? Either run it from XP if you have it, or Win7 -> run IE9, F12, choose IE8 browser mode.
What exactly is the bug with respect to whitespace? I'm presuming it's related to code tags given what you're saying, and I know I altered the code a while ago due to whitespace problems because IE has funny ideas about how it should handle whitespace in code tags.
-
A screenshot is worth a thousand words...
-
So....? :^^;:
Posted: September 17th, 2011, 08:08 AM
If I remove the max-width from the css, Opera will fail too. It doesn't fail in SMF AFAIK so maybe it's due to something else (i.e. not the code tag styling itself), like the use of display:table-cell or some other esoteric CSS...
Posted: September 17th, 2011, 09:43 AM
Fixed.
table-layout: fixed was all I needed... In #forumposts .wrc, FFS. I'll never properly understand the logics of table layouts but at least it's done -- and what led me to the right one was the fact that it was broken in Opera as well when I remove the max-width. Now I don't need the freaking max-width anymore, meaning I'm not tied to a certain width. All is good!
-
Odd little thing I noticed last week... I can't seem to find any use for $context['languages']['english']['selected'].
It's not used anywhere I could find -- and it's not even set, i.e. if I select the English version, 'selected' isn't set to true or whatever.
This should probably go... Can someone look into this?
Posted: September 27th, 2011, 08:17 AM
Up.
Pete, I suspect you still don't have access to the codebase right....?
-
Not right now in a meaningful way. have been busy with family stuff.
-
- aeva_get_num_files() function is seriously awful. It uses scandir() to iterate through the list of files and increment a counter.
There are plenty of ways of doing that in a single instruction -- e.g. the various ones here:
http://stackoverflow.com/questions/224408/return-total-number-of-files-within-a-folder-using-php
I don't know if it's worth it though... But on forums that heavily use the media gallery...
- selected: not only is this never used in Wedge, but it's set twice -- once in Load.php, and once in Register.php. It's set -- and never used after that...
if (!empty($modSettings['userLanguage']))
{
$selectedLanguage = empty($_SESSION['language']) ? $language : $_SESSION['language'];
// Do we have any languages?
if (!isset($context['languages']))
getLanguages();
// Try to find our selected language.
foreach ($context['languages'] as $key => $lang)
{
$context['languages'][$key]['name'] = strtr($lang['name'], array('-utf8' => ''));
// Found it!
if ($selectedLanguage == $lang['filename'])
$context['languages'][$key]['selected'] = true;
}
}
Remove or not...?
- getid3 is now at version 1.9.1, we're still at 1.7.9 (2 years old). I originally took a LOT of time to delete all of the PHP comments from getid3 -- there are so many, and sometimes so awfully indented, it's just a waste of space. I saved at least 20% of space by removing these. Problem is -- if I keep removing the comments manually, I can't update getid3 as easily as one would think... Meh. On the other hand, it's not like it needs to be updated a lot. I don't know.
Opinions welcome...
-
Using iterator_count is fine if you know it only contains images, otherwise you're pretty much implementing the exact same logic in a different method. As for which is fastest, the only way to test that is to get some folders, some purely images, some with half and half, some with mostly non images and benchmark it.
Selected is removable if we never provide any such UI as the language dropdown; using the flags pretty much invalidates that requirement, so yes, it should go. (Is it not even used in ManageServer?)
I feel your pain re external libraries with comments, I'm having similar fun with phpseclib. What's the benefit of updating?
-
We can't really test for images because AeMe can really hold any type of files anyway -- and the file extensions are gone, either way. I'm just trying to get it to be simpler. The problem with glob() is that it's not available on all servers, but OTOH if it's not, then Wedge won't work (Subs-Cache uses it.) I've done too much benchmarking these days, I hardly even trust it anymore... Just doing a long loop will usually not work well, because PHP will cache results internally I believe. For instance, $a[strlen($a)-1] is faster than substr($a, -1) when calling them thousands of times -- but substr is always faster on a single call. (e.g. if you modify the string dynamically...)
No, it's not used in ManageServer... Sigh.
As for getLanguages, I'm tempted to always call it, even with just the English files... lulz.
getid3 changelog:
http://getid3.sourceforge.net/source/changelog.txt
Hmm...
-
So, what exactly does the function do? If it's purely a count of files, the iterator count is exactly what you want.
glob, btw, is available on every system I've ever seen, and given that it's implemented internally for Windows support, it can be assumed to be available on any platform we'd actively be supporting.
If it's not used in ManageServer (and it was a long shot that it would be used in the lang editor, I wasn't really expecting it to be), then it really can go.
As far as getID3, v1.8.0 is worth doing (PHP 5.3+ compat fixes) but the number of bug fix entries would suggest it's beneficial to get to the current version. I should note that I'm in the same boat with keeping up with Bad Behaviour, and if phpseclib can be minified enough to be included, we'll have it there as well. That said, these things are not updated regularly enough for us to be a problem IMO - but if we get up to date with versions, it should be easier to keep up to date.
-
- File counter. Its code was obviously lifted from another, more complicated function, so it was doing unnecessary things in the middle, most notably doing a recursive search... When we really only needed to have the files in the current folder. count(glob()) was the faster solution in the end.
- It can be disabled individually... But then again, why would it?
- Gone.
- Updated to 1.9.1, with a few files removed in the process (never actually got around to using these id3 tags from mp3 files, so we might as well not include the files... Until someone actually wants to implement this.)
Also, the PHP 5.3 compat fixes were long overdue at the time, and obviously Aeva Media shipped with a version of 1.7.9 that was custom-fixed for PHP 5.3.
I'd estimate that around 10 to 20% of all code in getid3 is comments, and it doesn't compress well on top of that. Still, with the files I removed, the additional code and comments aren't too huge...
- Another thing worthy of note.
http://techblog.procurios.nl/k/news/view/34972/14863/Cache-a-large-array-JSON-serialize-or-var_export.html
I was curious about var_export(), because it stores the array in PHP format, so I made my own test...
global $cachedir, $modSettings;
$myDataArray=array_merge($modSettings,$modSettings);
// Store cache
file_put_contents($cachedir.'/test1.php', json_encode($myDataArray));
file_put_contents($cachedir.'/test2.php', serialize($myDataArray));
file_put_contents($cachedir.'/test3.php', "<?php\n\$myDataArray = " . var_export($myDataArray, true) . ";");
file_put_contents($cachedir.'/test4.php', "<?php\nreturn '" . serialize($myDataArray) . "'; ?>");
// Retrieve cache
$a=microtime(true);
$myDataArray = json_decode(file_get_contents($cachedir.'/test1.php'));
echo microtime(true)-$a, ' ';
$a=microtime(true);
$myDataArray = unserialize(file_get_contents($cachedir.'/test2.php'));
echo microtime(true)-$a, ' ';
$a=microtime(true);
include($cachedir.'/test3.php');
echo microtime(true)-$a, ' ';
$a=microtime(true);
$myDataArray = unserialize(include($cachedir.'/test4.php'));
echo microtime(true)-$a;
As a result: (and I'm getting proportionally identical results with just a single string)
0.00023102760314941
0.00013899803161621
0.00025486946105957
0.00014996528625488
i.e. the unserialize solution, as used in SMF/Wedge, is nearly twice as fast as storing an array in PHP format...!
Meaning that if we actually went ahead and turned all of the array declarations to serialized strings in Wedge, it would improve performance :lol:
Well, of course it's hardly doable, if only because some array entries are dynamic, permission-based or similar, so that would require unsetting them after the unserialize which would waste some time, but... well, it's always good to know! :^^;:
-
- Yeah, I've seen enough copied code in my time.
- The only reason a host would disable glob is out of some misguided notion of security, and frankly, if they're doing that, best to move hosts to someone competent.
- Good. Every little thing that isn't needed, should go.
- Sounds like the right decisions have been made. Unfortunately I don't have the luxury of just ripping code out with phpseclib, but I can certainly trim the comments. I did also have to attend to a PHP 5.3.3 backwards-incompatible change while I was at it.
- Hmm, that's interesting! And yeah, that doesn't surprise me, actually, though a goodly number of them are derived from the DB.
-
phpseclib... What does it do?
How would you trim the comments? Through a commandline tool? Some script? Or manually...? I've done some extra comment ripping but it's dull and frankly on the next getid3 update I probably won't bother at all. Oh man, how do I *hate* dirty source code with plenty of commented out functions, things like that... It's definitely not something I'd release, personally. And these pieces of code have been in there for years...!
Okay, a small one now. Does anyone remember any situation where Wedge/SMF might put a slash (/) inside the query string, i.e. after the "?" part of the URL? Any variable values that can contain a slash? I can't think of anything, but if I could be sure that it doesn't happen, I could safely remove a substr and a strpos from the main codepath.
-
phpseclib is the SSH/SFTP library in pure PHP. I figure if I can get it small enough, I can justify including it into the plugin manager for handling permissions changes on hosts where FTP isn't an option. It's 600KB to kick off, I was down to about 400KB without having to trim too many of the comments by general cleanup, and if I strip all the comments, I can get it down to probably 250KB.
I don't really envisage having to update it very often, which is advantageous if it's bundled, and I can fully sympatheise with your issues with getID3.
The old package manager could put slahses into the URL when browsing a package server. The language editor shouldn't but you never know, and I'm not sure about the skin selector. It isn't common, though, not at all - it's sufficiently rare that you could remove it and we'll fix anything that gets broken in consequence.
-
- Oh yeah, I forgot about that one, sorry...
- Well it's in the admin area only then, I guess... Nah, the skin selector base64-encodes all URLs it has in the query string :)
I suppose I could remove that, then, yeah... When you're back, have a look at the index.template.php change in rev 1043. The extra code is after the $qmark test. It's probably not worth removing, though... I mean, one extra substr... it's fast enough.
-
Well, it is a per-page test after all, but since the test is to grab position then look for === false, I'd say it's probably as fast as it's going to get and that it's far from the biggest of the consumers...
-
Yeah... Hence why I posted it on that particular topic :P
-
Was using the main menu in Chrome and... What?! It's glitchy!
I never noticed that until now. Pete, do you remember if this has always been that way, or is it a recent thing?
When hovering a top level item, its menu opens with both a vertical animation, and a fade-in effect. Problem is, once the fade-in is finished, the anti-aliasing value for the text is changed to make it anti-aliased, meaning it's aliased during the animation. This is probably a jQuery problem but... in Chrome, FFS?!
Posted: October 1st, 2011, 03:46 PM
Okay, narrowed it down to -webkit-border-radius... If it's set (to anything), the text inside gets aliased. Uh!
-
I honestly hadn't noticed it before as being a problem. It could be a Chrome bug or a jQuery one, just as easily.
-
Reported bug to the Chrome team... (reproduced on the demo site.)
And it's not jQuery, as it can be triggered by changing the border-radius value on the fly.
-
Heh, reminds me of the hellspawn hasLayout hacks for IE...
-
Oh oh, don't get me started on hasLayout... :P
Last week I was actually trying to *remove* hasLayout from an item. Which turns out to be pretty much impossible! :(
Another, in Class-DB.php:
// A database error is often the sign of a database in need of upgrade. Check forum versions, and if not identical suggest an upgrade... (not for SVN versions!)
if (allowedTo('admin_forum') && defined('WEDGE_VERSION') && WEDGE_VERSION != @$modSettings['weVersion'] && strpos(WEDGE_VERSION, 'SVN') === false)
$context['error_message'] .= '<br><br>' . sprintf($txt['database_error_versions'], WEDGE_VERSION, $modSettings['weVersion']);
$modSettings['weVersion'] isn't defined anywhere by Wedge. It may be some variable we used to set but removed eventually... Since I believe you recently discussed this particular error message, do you remember anything about it?
-
Think you'll find it's in the installer, as the first entry into the wedge_settings table. It certainly was there last time I did a fresh install.
It's really not worth keeping, because it's somewhere between misleading and useless, and frankly unless it's going to be updated by installers/upgraders (which SMF doesn't!) it is only useful for checking fresh install. Since I was doing tech support without even checking that before (since I made sure to keep a note of what versions did what changes) it certainly didn't help me, and I don't think it's helped anyone else much.
I haven't discussed this one recently, though.
-
Think you'll find it's in the installer, as the first entry into the wedge_settings table. It certainly was there last time I did a fresh install.
It's really not worth keeping, because it's somewhere between misleading and useless, and frankly unless it's going to be updated by installers/upgraders (which SMF doesn't!) it is only useful for checking fresh install. Since I was doing tech support without even checking that before (since I made sure to keep a note of what versions did what changes) it certainly didn't help me, and I don't think it's helped anyone else much.
-
In other news, I thought I'd try a new tactic with getting phpseclib down in size. I'm not yet sure whether I'm entirely happy with it, but anyway.
I went through the files, making sure I only had the files I needed, then pushed them all through http://customhost.com.ua/php-minify/ to strip comments. I made sure to leave whitespace in and preserve newlines since I still want readable source, then did some regex magic to convert all the leading 4-spaces to tabs and I'm now down to ~280K with it. My target's always been 250KB to try and slim it down to, since if it's there, I figure it's small enough to justify its inclusion.
On reflection, I realised that I was a bit uptight with my PHP 5.3 compatibility changes, a class having its own name as a function will still be called for a default constructor, provided it's not namespaced, so I don't need to go through and convert the default constructors to __construct, but I now don't have the source I did changes to initially, it still has all the PHP 4 compatibility in it, and more irritatingly I ditched the conversion I did to indicate visibility of variables - they're all declared as var rather than public/private, which means they'll all be technically public.
Here's the thing: do I do it *right* and fix all that, or do I leave it, knowing that it'll work because it's not actually an issue per se and leave it being smaller?
-
Oh, I'm slacking today. Instead of a bunch of var declarations (or a bunch of private declarations, or whatever), I can do simply one big one and make it a long line. Means I get to do it properly *and* save space compared to how it was before!
-
Well... Readability is important -- when you're planning to maintain the thing!
But do you think you're going to?
I was looking for similar software, thanks for pointing to it. I manually passed all of the getid3 files to it, stripping comments and whitespace (but not doc comments because getid3 uses this in its parser... Geeky for sure, but a horrible way of doing things!), and keeping just the header comment.
Normal version: 702kb, zips to 133kb
Minified version: 522kb, zips to 98kb
Not bad...! Although I'll have to test it, I guess... It's an interesting alternative, and it only took 15 minutes or so to convert all of the files. Something I *can* do on each major release for sure...
Okay, speaking about minification. I've been thinking about many things...
- doing on-the-fly minification (i.e. not cached...) on inline JS and CSS. Do you think it's realistic? I'm not sure myself, but I could cook up a simplified minification function, although I wouldn't know how to deal with strings. Hmm. Still, just as an example, if I manually minify the noi_resize() code, I save something like 60 to 80 bytes off the page, and a reasonable ~20 bytes when gzipped. Considered it's to be found on every single page...
- media cache: I'm always tempted to add a htaccess for the media folder, just so I don't get the pagespeed warning when it can't find a far-future expiration date. Problem is -- if you replace the files with a newer version, if the files have the same name, then the generated name has the same name as well. And that's only for thumbnails... Previews and full pics are accessed through PHP, so I can't "regenerate" a new filename for them, it won't help at all.
Need I worry about caching media items at all...?
- considering using YepNope to load jQuery and subsequent code. YepNope is 1.6kb minified and gzipped, so it's not exactly super-light, but at least it would trick pagespeed into thinking no other JS is executed at page load time, so I'd be likelier to get it to a perfect score... Main problem is, I doubt I'll be saving any time here. The only 'big' script we have to load is jQuery, the rest is negligible (except maybe for script+theme). At best, jQuery will load in parallel while YN is loading other JS files, and thus will be able to execute everything at the same time instead of waiting to load script+theme and other scripts after jQ is loaded. Still, if jQ is integrated into the main local file, it's even more pointless. At worst, YN wastes time executing itself when both jQ and local scripts are already cached... :-/
- Considering using "FileETag none" in all htaccess files. I'm not a specialist though... But as soon as we have an expiration date, ETags aren't useful at all. I'm not sure if it should be done for all files.
- IP packets carry the cookie, as everyone knows. My question would be, does it carry it only in the first packet of the page, or on every single freakin' packet? In which case it'd be in our interest to make cookie size as small as possible...
- I noticed that by default, avatars are loaded into the attachment folder. I *know* AeMe will change the entire system, but since I still don't know when I'll deal with this, I'd like us to consider creating a 'custom' folder in /avatars/ and upload all avatars there by default -- and obviously, set Wedge by default to show clear URLs for these avatar images. We save *by default* as many HTTP requests (to PHP FFS!) as there are avatars on the page.
-
Well... Readability is important -- when you're planning to maintain the thing!
But do you think you're going to?
I was looking for similar software, thanks for pointing to it. I manually passed all of the getid3 files to it, stripping comments and whitespace (but not doc comments because getid3 uses this in its parser... Geeky for sure, but a horrible way of doing things!), and keeping just the header comment.
Not bad...! Although I'll have to test it, I guess... It's an interesting alternative, and it only took 15 minutes or so to convert all of the files. Something I *can* do on each major release for sure...
- doing on-the-fly minification (i.e. not cached...) on inline JS and CSS. Do you think it's realistic? I'm not sure myself, but I could cook up a simplified minification function, although I wouldn't know how to deal with strings. Hmm. Still, just as an example, if I manually minify the noi_resize() code, I save something like 60 to 80 bytes off the page, and a reasonable ~20 bytes when gzipped. Considered it's to be found on every single page...
- media cache: I'm always tempted to add a htaccess for the media folder, just so I don't get the pagespeed warning when it can't find a far-future expiration date. Problem is -- if you replace the files with a newer version, if the files have the same name, then the generated name has the same name as well. And that's only for thumbnails... Previews and full pics are accessed through PHP, so I can't "regenerate" a new filename for them, it won't help at all.
Need I worry about caching media items at all...?
- considering using YepNope to load jQuery and subsequent code. YepNope is 1.6kb minified and gzipped, so it's not exactly super-light, but at least it would trick pagespeed into thinking no other JS is executed at page load time, so I'd be likelier to get it to a perfect score... Main problem is, I doubt I'll be saving any time here. The only 'big' script we have to load is jQuery, the rest is negligible (except maybe for script+theme). At best, jQuery will load in parallel while YN is loading other JS files, and thus will be able to execute everything at the same time instead of waiting to load script+theme and other scripts after jQ is loaded. Still, if jQ is integrated into the main local file, it's even more pointless. At worst, YN wastes time executing itself when both jQ and local scripts are already cached... :-/
- Considering using "FileETag none" in all htaccess files. I'm not a specialist though... But as soon as we have an expiration date, ETags aren't useful at all. I'm not sure if it should be done for all files.
- IP packets carry the cookie, as everyone knows. My question would be, does it carry it only in the first packet of the page, or on every single freakin' packet? In which case it'd be in our interest to make cookie size as small as possible...
- I noticed that by default, avatars are loaded into the attachment folder. I *know* AeMe will change the entire system, but since I still don't know when I'll deal with this, I'd like us to consider creating a 'custom' folder in /avatars/ and upload all avatars there by default -- and obviously, set Wedge by default to show clear URLs for these avatar images. We save *by default* as many HTTP requests (to PHP FFS!) as there are avatars on the page.
-
I want to know, why are you guys putting in so much effort for a server side script? I can understand for a JS library but why for a script in which reducing the size doesn't actually matter in terms of speed or anything else?
-
I can't speak for getID3, but a script that's 600KB (including comments) that will all be loaded at once, because that 600KB is all interdependent. That, and the fact that I'm not too thrilled about the size increase that will necessarily result from it (but that, at the same time, I can't really make it a plugin either)
-
Download size and time to upload for users... Enough of a reason for me.
-
When packed as a .zip (less efficient than .tar.gz), this weighs in at 169KB.
-
It's not much but it adds up.
-
Though removing the calendar to a plugin would help ;)
-
Btw 280kb should pack to 50kb or so. Any binary data in your files...?
-
Nope. It's all pure PHP. Lots of big numbers expressed in 0x0000 format, but that's about it. Though, I suspect I'd rather not mess about to keep reminifying if possible.
-
In the code tags above, The "\" in "\n" seems to be supressed on display. The serialize line looks like this:
file_put_contents($cachedir.'/test4.php', "<?phpnreturn '" . serialize($myDataArray) . "'; ?>");
-
How quaint, an old SMF bug back to strike again. I thought that had long since been fixed (because it is an SMF bug originally)
-
Is this on Wedge, or Wedge.org...?
Wedge.org is running SMF2 RC4, not Wedge.
-
Is this on Wedge, or Wedge.org...?
Wedge.org is running SMF2 RC4, not Wedge.
It's originally an SMF bug around how it does the post split to push things to the highlighter but I thought it was long since (pre RC2!) fixed.
-
Maybe I just didn't port that bug fix into my copy of Noisen/Wedge.org...? I mean, originally Noisen runs on SMF 2.0 Beta 1 (the September 2007 release), and I applied all subsequent updates manually...
Therein lies the issue. I don't really expect to do much maintenance, even less than with BB.
Anyone can re-download them from the relevant website (getid3 or libsecsomething) and replace their minified files with the originals...
The comments aren't needed for phpseclib and with the header that retains the copyright and so on, I spent 15 minutes on it and got it down to 280KB or so, then just spent time faffing about cleaning the code, didn't really change the size but it did make it tidier. It'll zip fairly well, I think, haven't tested it.
Oh, speaking about zipping... I made a few tests with a Sep. 15 revision of Wedge.
I didn't test with WinRK (it's not free), but I think it wouldn't be (much) better than PAQ...
Also, please remember that the Wedge package is currently 50% bigger than SMF's -- add 1.5MB for AeMe, 500KB for /other/stupid-sub-folders/*, and the rest is mainly new features, new code etc...
ZIP: 3653kb (by comparison, SMF = 2610kb)
ZIP (best): 3642kb
tar.gz (best): 3132kb (85% of the zip file) (by comparison, SMF = 1941kb, i.e. 74% of the zip file)
RAR (best): 3006kb
tar.bz2 (best): 2734kb (75% of the zip file) (by comparison, SMF = 1598kb, i.e. 61% of the zip file)
7z SFX LZMA (ultra): 2688kb
RAR (solid best): 2464kb
7z SFX PPMd (ultra): 2450kb (67% of the zip file)
ZPAQ: 1983kb
PAQ8o: 1828kb (50% of the zip file)
So... PAQ does twice better than ZIP, but it's not very realistic to use it (too long to compress, too much Ram needed....), so 7z SFX PPMd (which doesn't require any decompression program per se) would be a good alternative for offering a downloading to non-techies. (Okay, Mac users may be non-techies as well but I'm catering only to Windows users for now...)
I'm not exactly sure, though, why bz2 is less efficient on Wedge than on SMF... Do we have that many extra image files in it, for instance...?
Oh, and where are you now, regarding the SMF 2.0.1 patch?How important is it to keep the download size small vs readable? I'm not actually that fussed myself.
(Then maybe we should have some kind of system that automatically sends the updated files to the server.)- doing on-the-fly minification (i.e. not cached...) on inline JS and CSS. Do you think it's realistic? I'm not sure myself, but I could cook up a simplified minification function, although I wouldn't know how to deal with strings. Hmm. Still, just as an example, if I manually minify the noi_resize() code, I save something like 60 to 80 bytes off the page, and a reasonable ~20 bytes when gzipped. Considered it's to be found on every single page...
Can be compressed manually, yeah. But I figured I'd rather have it done logically -- if one part of the inline code is compressed, then all of it should be compressed. And I'm not sure what to use to minify JS when it comes to something that has to be done on-the-fly for everyone, on every page, instead of done once and cached...Aren't the timestamps included in the filename? They are for avatars.
Which is a bit of a bummer...
Oh, and I'd love us to consider showing preview & full sizes in plain view as well. As long as the filenames can't be 'found out' by analyzing the thumbnail URL...I wouldn't worry about YepNope, because you're still doing more work that doesn't - ultimately - benefit the user. It just fools a score.
- Considering using "FileETag none" in all htaccess files. I'm not a specialist though... But as soon as we have an expiration date, ETags aren't useful at all. I'm not sure if it should be done for all files.
Hmm, seems like YSlow doesn't recognize my FileETag query. Maybe I should also do 'Header unset ETag'... And any removed header means more space for pure data...
Does Chrome have an extension to help view request headers?It's embedded into the HTTP request, which is only sent once for the request,
even if the header is split across multiple packets because of lots of extra headers. It's still worth keeping it as small as possible (though, frankly, I don't see how else we can!) simply to hope we can keep it into as few packets as possible.
http://tracker.wedge.org/?sa=ticket;ticket=28 ;) Yes, we save multiple PHP/DB requests *per page load*.
Then I guess we agree on this, eheh.
Do you want to implement the change?
-
Maybe I just didn't port that bug fix into my copy of Noisen/Wedge.org...? I mean, originally Noisen runs on SMF 2.0 Beta 1 (the September 2007 release), and I applied all subsequent updates manually...
Then, you may easily compress the files.
Anyone can re-download them from the relevant website (getid3 or libsecsomething) and replace their minified files with the originals...
If I were to leave it as multiple files, I would at least have to fix the source loading, but that's a very small price to pay.Oh, speaking about zipping... I made a few tests with a Sep. 15 revision of Wedge.
I didn't test with WinRK (it's not free), but I think it wouldn't be (much) better than PAQ...
Also, please remember that the Wedge package is currently 50% bigger than SMF's -- add 1.5MB for AeMe, 500KB for /other/stupid-sub-folders/*, and the rest is mainly new features, new code etc...
So... PAQ does twice better than ZIP, but it's not very realistic to use it (too long to compress, too much Ram needed....), so 7z SFX PPMd (which doesn't require any decompression program per se) would be a good alternative for offering a downloading to non-techies. (Okay, Mac users may be non-techies as well but I'm catering only to Windows users for now...)
I'm really not sure that offering self-extracting archives is really that useful.I'm not exactly sure, though, why bz2 is less efficient on Wedge than on SMF... Do we have that many extra image files in it, for instance...?
Oh, and where are you now, regarding the SMF 2.0.1 patch?
Anything we maintain should be readable. Anything else we use, the smaller the better. We don't want a big download size, not because it's "big", but because it costs money to cover for the bandwidth -- although we can probably share the files via Mediafire and so on... Or just extra mirrors... And because I'm not sure people would like to download and reupload a big file 10 times a year just because we release early and often. I know I wouldn't...
(Then maybe we should have some kind of system that automatically sends the updated files to the server.)
It's inlined because I need to execute it ASAP. Waiting for jQuery to run is out of the question. It would save probably a hundred bytes, but would create a very noticeable delay when loading a page that doesn't match the expected viewport width. Then again, onresize() doesn't execute when using the Back button (at least in Opera), so it's not exactly a 'perfect' solution anyway. Doing my best...
No, I don't think they are (for media files). If you update the file with the same file, it gets the same filename.
Which is a bit of a bummer...
Oh, and I'd love us to consider showing preview & full sizes in plain view as well. As long as the filenames can't be 'found out' by analyzing the thumbnail URL...
Yeah, I suppose so... And even YSlow doesn't care about jQuery being there. Only Google PageSpeed does. And it would only save at BEST 2% because I get a maximum score of 98%, even with jQuery loaded normally.
But technically it's not used at all because the browser will no longer request the resource (as long as it caches it, of course.)
Hmm, seems like YSlow doesn't recognize my FileETag query. Maybe I should also do 'Header unset ETag'... And any removed header means more space for pure data...
Does Chrome have an extension to help view request headers?
Yeah, well, I suppose it's not as scary if the cookie is loaded sent once. The first packet will be shortened a lot, but not the rest.
Ah, I forgot about that ticket...
Then I guess we agree on this, eheh.
Do you want to implement the change?
Considering that SMF can do this already, I was only originally planning to make use of the existing code, but strip out the other stuff of serving avatar files through dlattach. I hadn't factored in working with Aeva at that point.
-
Need to answer post above...
A quick one though.
The index template declares this in the header: <meta charset="utf-8">
However, SMF/Wedge already specifies the charset in the *HTTP headers*. So I boldly tried to remove the line and... It worked. However, when validating the page, while it's seen as valid, it adds a warning that I should be specifying the charset in the document itself, to help people view the files offline (save to disk).
It absolutely makes sense, I'd say. But I still don't see the point in having the charset specified twice.
So I'm wondering... Wouldn't it make sense to just skip specifying the charset in the http headers, and focus on the document itself?
The only drawback, AFAIK, is that anything before the charset declaration might be seen as ISO, but then again, I used to have '©' in the copyright line, and it wasn't correctly output, even though the headers declared the charset correctly. This is why I rewrote it to use (c) instead. So at this point, I'm not sure declaring charsets in http headers has any point... (?)
-
Can we rely or otherwise ensure that the file headers are sent correctly? If we can rely on the header being correct (like we set it ourselves, for example) then we can strip it from the file, at least in theory.
-
(Crap, I'm unable to find in the admin area where I can set up, locally, the need to confirm my password when accessing the admin area... I tried to search for 'admin', but it didn't find anything...)
My understanding was that topicseen is an older item, legacy from 1.1 or somesuch, but I have no idea offhand if that's still the case or not.
Here's a little anecdote of what I had today.
A two-page topic on my local install, all posts marked as unread. Back to the parent board. Clicking the New icon. Getting to the page. Notice that the URL doesn't have "?seen" in it (unlike the homepage stuff). Reload page: the first post still gets the 'new' icon... (As long as I refresh the page.) It doesn't happen here, it's probably due to a stat bug in the database. I just did a recount operation and now it works as expected. Still, that's interesting: there's a minor bug in Wedge that causes num_replies to be wrong (possibly when using post moderation or ignoring users or reverse order for posts), and having num_replies wrong will break a lot of things... (including hiding any posts that are after the recorder number of replies...)
Anyway, that's not what my post was about.
Whether I use the messageindex link or the homepage link, the results are the same. Internally, it acts as if it had a 'seen' variable in the URL. So, then, what's the point in indicating the variable at all...? It's a waste of space...
Perhaps it's just the same with boardseen, I don't know.
We certainly should consider accessing the boardseen cache thoroughly when posting. We've been discussing this yesterday somewhere else -- it just doesn't make sense at all, this feature in SMF... And if the Wedge authors don't understand it, maybe it needs some more work.
-
Also... Woohoo, bug?
Found this in the post below the one I just replied...
It doesn't have the single quotes. But they're definitely in there internally. It also shows that way in Preview mode...Bienvenue dans l'installateur du Forum Simple Machines !
-
(Crap, I'm unable to find in the admin area where I can set up, locally, the need to confirm my password when accessing the admin area... I tried to search for 'admin', but it didn't find anything...)
We certainly should consider accessing the boardseen cache thoroughly when posting. We've been discussing this yesterday somewhere else -- it just doesn't make sense at all, this feature in SMF... And if the Wedge authors don't understand it, maybe it needs some more work.
I agree that the board-is-read stuff should be better cached, but I'm not entirely clear right now exactly best to achieve that.
At what point does a board become entirely read? When there are no topics with unread items in?Also... Woohoo, bug?
Found this in the post below the one I just replied...
It doesn't have the single quotes. But they're definitely in there internally. It also shows that way in Preview mode...