Wedge

Wedgey, Wedgey!

That, and other things for me, I think! (Well, it's a matter for another day, possibly another blog post...)

Happy new year everyone, and at last the year ending in 13 is over... :niark:

[byebye-themes-part-deux 2711527]
 10 files changed, 564 insertions(+), 611 deletions(-), 5.14 KiB

* Replaced $helptxt['*'] with $txt['help_*'], which was unused across the entire codebase. It's an absolute waste of time and resources to use a different array for these, really... Especially when it came to caching. Another 50 lines saved in Load.php, it's now below 90KB, having lost nearly 10KB since the theme removal process was started. 10KB of PHP your server won't have to load on every page, and I mean it. (Admin.php, Help.php, Load.php, ManageServer.php, Subs-Template.php, Help.language.php)

* valid_filename() provides a better solution (IMHO) than md5() when it comes to handling the language cache filenames. If I find any issues with it later, it's only a matter of changing two lines. (Load.php, Subs.php)

@ There are more files related to this change, but they're planned for a later commit. I don't think not committing them now will break Wedge, though. Also, Help.language.php changes about 170 lines per file, but it's all about the variables being renamed, nothing else, so don't bother.

rev 94 -- probably the last commit rev number, too.
[byebye-themes 8086c79][1]
 8 files changed, 104 insertions(+), 104 deletions(-)
 rewrite skin_selector/SkinSelector.php (62%)

* Skin selector now uses cached skin data. (SkinSelector.php)

! Skin selector was (still) breaking the Manage Boards page. I'm not sure why Pete had originally decided to call the select tag 'boardtheme' instead of 'themeselector', but I played along with that, and shouldn't have. (SkinSelector.php)

* create_function() to lambda functions. (ManageCalendar.php, Subs-Calendar.php, MaxSmileys.php, PostsPerDay.php, WordLimits.php)

* Theme code removal. (SkinSelector.php, WedgeDesk-Profile.php)

* theme_dir removal. (WedgeDesk.template.php)

1.

Not sure why this commit created a new branch on its own. To be clear, my Plugins repo is exactly inside the Wedge repo, so that I can do my search & replace processes on it at the same time. Does this mean that msysgit's branch switcher on the Wedge repo also 'forced' a new branch on its child repos..? If yes, it's not good news for me, because it means having to check whether or not my stuff is committed to the right branch...

[byebye-themes-part-deux 7f58d5b]
 27 files changed, 383 insertions(+), 618 deletions(-)

- Started removing id_theme and we::$user['theme'] from Wedge, and turning theme previews into skin previews, things like that. The loadTheme function has a much simpler intro now, being 54 lines shorter. Still need to turn themes into skins entirely, notably all of the edit/copy/install code, but it's not as urgent, and I might remove them entirely and rely on FTP exclusively. (Most of the files in this commit are concerned by this, so I won't list them. I only need to list files when I need to quickly find a specific change I made in a large commit, really.)

* Rewrote the skin selector (both the plugin and Themes.php versions) to get rid of all theme code. Also used the opportunity to cache the results, so it'll save quite a bit of parsing on every page if you're using the SkinSelector plugin, really. Also, skin previews are no longer stored in the session variable, because if you can navigate your way through the skin selector in a preview state, then I'm sure you can make your decision immediately, without needing to browse the forum. I'm even considering removing the feature altogether, but as of now it's only using a couple of lines, so it's alright. (Load.php, Themes.php, Themes.template.php)

+ Proper support for choosing the 'default skin' from within the skin selectors, rather than just the currently default skin. e.g., choosing 'default skin' will reset your choice to what a guest would see, and if the admin changes the default skin, your skin will follow that choice. (Many files.)

! loadLanguage() no longer takes '+' separated strings as arguments. Oops. (Load.php)

- A very, very old bug: $file[3] was never used in loadLanguage(), meaning the last param was always declared for nothing. (Load.php)

- Removed id_theme from language_changes table. This is only half-done, I have yet to commit ManageLanguages with which I've been having problems. So, basically, the language editor won't work in the current commit. Sorry about that. (Load.php, install.sql)

* Moved issue_http_header() to Errors, the only place where it was used. (Subs.php, Errors.php)

* Note: $ssi_theme is now $ssi_skin, as could be expected. (SSI.php, Load.php)

@ Note: there's a bit of a hack in the skin code update. As of now, default skin = '', root skin = '/' and non-root skin = 'folder'. The slash in root skin doesn't match the non-root folder structure, but this is because I didn't want the extra slash to be stored in all non-root skin choices. That's probably a bad idea, but I'd still rather not have unneeded bytes in skin names, because of their varchar nature within database keys. If I can't live with that hack, I'll restore the starting slash on skin names.

@ Note: $context['skin'] is still being filled in, and represents the folder of your current skin, relative to the skin folder. The new $context['skin_actual'] is also interesting, as it holds your skin choice, which can include 'default', and is used internally in more places.

@ Note: listing here all database changes that need to be made by anyone who currently has Wedge installed. Remove boards:id_theme, add boards:skin_mobile based on boards:skin (haven't yet written this feature, though), remove language_changes:id_theme and update the associated keys, remove members:id_theme and members:id_theme_mobile, add a skin(20) key to members, and remove themes:id_theme. Also, you may want to go to your admin panel, and update the default skins, because the format has changed. You should also reset everyone's skins, for the same reason, or update them manually with phpMyAdmin.

TBH, I'm not 'familiar' enough with PHP's OOP to be able to tell what a closure is, compared to a lambda function. Closure means so much in different areas (to me, it's Google's equivalent of Packer or UglifyJS, for instance...), I just consider the word 'closure' to mean 'self-enclosed function', and that's it. As for OOP, I know the basics (static vs dynamic, private vs protected vs public, singleton vs real class), but I have no reason to explore it further. I could even have converted more callbacks into lambdas, as I found online benchmarks that said lambdas were 10 times faster than create_function and a bit faster than named functions, but from what I could gather with my own benchmarks, it's actually slower than create_function by a few percents, and much slower than named functions. Why? I don't know... All I know is, if it's only used a couple of times at most in the page flow, I'll put my eggs into a lambda function. If I'm adamant about getting the best performance, then I'll go for a named function. create_function() can go entirely though (I think I've removed them all), because the performance makes no difference, and there's no reason to live with the joke that is an eval with escaped quotes.

5.4's array system is something that bothers me right now. My first thought was, "I want that for PHP", because it's how it's done in JS, and I love JS. However, after converting a few calls, I realized it was probably a bit over-hyped. I can live with doing wetem::add(array('my_layer', 'sidebar', ''), 'my_block') instead of wetem::add(['my_layer', 'sidebar', ''], 'my_block'), I suppose. I may revisit that later, especially if I can get my PHP cache to work flawlessly, but for now... I'll postpone it for later.

Apart from /images/cyna, there's nothing of immediate use to anyone, and this might even confuse some (e.g. I used git filter-branch to split this folder from the original repo, and as a result the commit messages still retain references to it, even though these files are not in the new repo itself), but I really, really need to get more comfortable with github, and this is one of the steps to it... (Hopefully, someone will make some pull request for whatever reason.)

So... Hope you all had a nice Christmas! I, for one, had a lovely couple of days back in my family. As a late present (although it can be argued that interest around it will be limited), I felt I needed to point out that I've just pushed the very first Wedge public repo to Github.

This isn't the forum software itself (you bet! But I'm doing my best to put it online next month, fingers crossed!), but it contains some actual code that belonged in Wedge at one point or another, as well as a hopefully interesting view into variable names, programming techniques and other things that might give you an idea of how I do things generally.
This repo is called stash, and previously shelf and attic, to give you a generic idea. You guessed it, it's the place where I shelved any code that I liked but didn't want/couldn't afford to have in the Wedge codebase, such as outdated hacks, or bits of code that were no longer relevant to the current state of affairs. You might also be interested (a bit less, though!) in files that belonged to the original SMF SVN repo, and that I'm very unlikely to use in Wedge, but you never know.

You'll also find PNG-24 versions of all of the new icons that are included as PNG-8 (or GIF) in Wedge, in an effort to save as much space and bandwidth as possible. I use these files to rebuild the PNG-8 versions from the best possible source when I need to make a change to them.
A final freebie is in the form of the Cyna smiley set, which I built for Noisen.com and currently use on Wedge.org as well. And yes, you can re-use it on your own forum if you like.

Have fun, then! :)

https://github.com/Wedge/stash