Fixed this huge installer bug that caused all paths to be wrong; it was simply due to a function being called too late in the process. Apologies to those affected. I guess a lot of support topics can be closed now, yay. (install.php)

Removed some very, very old leftover code. If it makes you feel better (or me?), it's also still in SMF and Elk. Nobody seemed to bother that infile_css is just not used anywhere else in their codebase, so it happily lives on here, unaware that it's wasting your time on each install. (install.php)

I don't underestimate your skills. To be specific, I underestimated your skills for a long time because you didn't show them off, but you've seen proved that you can be very dedicated to your current task (if anything, the German translation is nothing short of impressive -- you pulled it off from scratch in a couple of weeks, IIRC..?), I just wasn't aware until recently that you had programming skills. Just call it 'ignorance' from me, I think it's neither more nor less than that. ;)

As for the ad management plugin, perhaps we could both work on it, under the Wedge Team flag. (i.e., a 'wedge:ads' plugin.) Maintain it on Bitbucket together in a private repo, and then when we're happy with it, either release it for free, or do something related to member groups.

Re: your PMs, I'm just at a loss right now... :whistle: I need some time to answer them. (Plus all of the other outstanding PMs I have.)

And here it is. I wanted to postpone it even more... But you don't deserve it. If anything goes wrong, I'll deserve it. In the meantime, please enjoy this; some of you have been waiting over three years for this moment.

This is the official plugin repository. Most of these were written by Pete, John and Shitiz. The current license for them is the Wedge license; eventually, though, my goal is to make it clear which plugins are under more permissive licenses. Perhaps I'll even be able to make them all MIT, or something. If you write a plugin and don't want to share it under the MIT license, you can always push it elsewhere.

This one isn't a new repo, I introduced it recently on this blog, but what's new is that all of its files are now governed by the MIT license.

Lastly, if you're planning to make the switch to Wedge from an active SMF forum, please remember this:

There is currently no 'proper' importer available. Pandos confirmed to me that the official importer is broken, so I'll look into it ASAP.

Said official importer will be pushed to the Wedge/tools repo (or its own repo) when available. I'm planning to have it around by next weekend at the latest.

If Thorsten looks into it before I do (I know he loves this kind of thing), then he may fix the importer before I do. See? A programmer's logic is no more complex than yours.

It's still an alpha, even three years in. Meaning nothing is set in stone, and if a change I make breaks your forum, you can't complain to me. And if it makes it better, then you can't complain either. That was the whole point, after all.

Now, please allow me for a short break, before I jump into new adventures with you all.

My vote goes to github.com/Wedge/wedge. I like the professionalism in the name of the repo and the base address. The name wedge/forum should have been good if there are other software like /forum /blog/ ...

I'm pleased to announce that the Wedge codebase will soon make it to the public. I'm nearly finished with the whole theme removal thing (which took me weeks to fine-tune), and while I'm sure you will find tons of bugs in the public repo (most of which I'm aware of), it *will* be usable, and will become even more usable as others volunteer to help. I still can't give you a date, it could be today, or in a week. But definitely this month.In the meantime, here's my last present before (hopefully) the Wedge public repo:

This is the long-awaited repo for the Wedge language files.You can technically clone this repo into your /core/ folder (which is what I'll be doing), and then you get the English and French translations without any other manipulations (except flushing the language cache, of course. I really need to do that automatically.)

As explained in the readme, if you're going to start a new translation, create a new folder in a new branch of your local repo, don't forget to sign-off any commits you do (otherwise I won't be able to accept them), and then do pull requests whenever you like.I'd also recommend that you create a new topic somewhere to announce your plans, so that you don't get into conflicts with other potential translators.

Note: you must be acquainted with the git system if you want to get into this. I won't hold you by the hand, although someone else on the forum might.

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.

[php-5.3 2fe90ec] -- how many branches can I live with before I start merging them...? :P 12 files changed, 291 insertions(+), 339 deletions(-), 6.11 KiB

* Wedge now requires PHP 5.3+, which allows me to use closures instead of create_function or other ugly callbacks. I'm not going to use these everywhere (it's a manual conversion), but I'm definitely excited to use it everywhere I can from now on. Also, using const keywords where possible -- it should be faster over define() calls. (index.php, Class-CSS.php, Class-String.php, Class-System.php, Profile-Modify.php, QueryString.php, Profile.template.php)

Just to keep you posted on the latest news[1], I'll try to keep doing what Arantor used to do at Facebook. So, this is a follow-up to that news post from August 23. With a few differences, which are in line with my way of doing it: while he used to post more regular updates, his changelogs were a bit too exhaustive, and lacked any sorting. I'd rather just mention what really makes the user tick, and that is, the really nice additions to Wedge. If you'd rather have a full list, the New Revs topic is waiting for you, like it's always been.

:cool: » For everyoneNew & overhauled features

- Quick Edit was completely overhauled. The textarea's height will now adjust to the original post height, making it easier to hit that 'Cancel' button if you change your mind. Also, the height expands or shrinks to follow the cursor when you're editing a post. Seriously, that's wicked. What? Facebook already does it? Oh, bugger...

- Relative dates on topic posts. Some people like seeing "5 hours ago" better than an actual date, so... That's for them! I started liking this, too, but I'm not using it everywhere. For now.

- PM menu is now a notification area in the header. It's clickable, and brings up a menu where you can preview your new PMs, or open your inbox. This was Arantor's final contribution to Wedge. Oddly, I never got used to it, and will probably add a link to your inbox in the profile menu, but I'm keeping the notification menu as it, out of respect. Also, I modified the system so that previewed PMs don't get marked read, so that you can preview a PM on a mobile device, and still be reminded to answer it when you're back on a desktop machine.

- New Stats template for daily/monthly stats. Instead of tabular data with a bunch of numbers, you now get a pretty little line chart (custom JS library based on another one), animated and all, and you can even zoom through parts of it, and choose any time span you want to analyze. I spent a week on this one; while it may take you some time to get used to it, eventually you'll have to recognize it's a real improvement.

Usability

- After marking a topic as unread, next time you visit that topic, you'll now be brought to the last page you were on.

- Previous/next topic links now properly lead you to the first unread post, if it's not in the first page.

- Now showing language flags in a select box, to avoid breaking layouts when adding or removing language packs.

Privacy & contacts

- I haven't done much on privacy, but I did some work in late October, and managed to get privacy running (when it didn't really work when I wrote the blog post), especially on thoughts. The code was simplified (a lot), and thus it should be easy for any plugins to add privacy to their own settings. I still need to fix privacy on 'children' of items that are using a contact list for privacy. Privacy options include: everyone, members, specific membergroup, specific contact list.

- Worked on contact lists at the same time as privacy, so it's in the same situation: working, but very basic for now. Your old buddy lists are now imported. You can put members into multiple contact lists (it took me some time to determine what to include, and the result is very close to Facebook's list types, so I guess they got that one pretty much right), and create custom lists. I have yet to write the UI for handling these lists, though, but it's a good start. The rest is just boring work that could be done by anyone, not just me.

- Contact lists include a 'restricted list' that acts as a 'cancel' (I wouldn't say 'ban') list for any other list, i.e. if someone is put there, they won't benefit from any access rights given by other lists they might also be in.

Skins

- Added a new skin, Wilde, which has proved so popular that it's now the default skin in Wedge.

- Zoomedia (the light and efficient JavaScript library that I wrote to replace Highslide in media embedding) is now fully hardware-accelerated, Retina/HD-friendly, and rewritten to better handle item descriptions.

- Improved (and fixed) homepage view in blogs, such as this one, notably in mobile devices.

- Improved the follow_me code to be pixel-perfect. You know, the trick that makes avatars stay on screen when scrolling through a long post. I'm planning to add support for a pure CSS technique that will save the JavaScript calls on each scroll event, but as it's not supported anywhere until it's a candidate recommendation, there's no hurry in doing that. Follow_me works right now, and on every (good) browser.

- Also overhauled infinite scrolling for a more 'expectable' approach and better performance.

- Fixed a long-lasting bug where quick editing a message you'd just posted would mark this message as unread.

8-) » For admins/webmasters- Rewrote admin area's setting page generators. They're now all unified under one function, and it's seriously for the best. Default member options are now developed by default, which is easier to handle.

- The sendmail() function now saves more bandwidth when sending e-mails, and properly does HTML and raw handling.

- You can now simply debug junk and only show SQL queries if you're not interested in getting template block lists. Saves some bandwidth for admins, so why not!

- Overhaul of the caching code for cache libraries such as memcached and Zend SHM.

- Tweaked board and topic permissions to make better sense out of some actions.

- Themes: turned all 'general' theme options into basic settings.

:geek: » For developers- Development workflow is now based on git, as you may have already noticed from the numerous topics about it. I'm getting better at handling this every day, but I have to say, it's really, really not user-friendly, especially for those coming from Subversion, which is so much simpler. If I had the time, I'd make a fork of git that acts exactly like SVN in every aspect.

- This just in: PHP source file caching and minifying. It doesn't save a lot of time, but I'm not against a 0.01s improvement in page load, especially across many page loads. Your server will thank you for that. Also, it paves the way for the return of source file patching through plugins, but in a more secure way, as you'll be able to update your Wedge source files and still have your plugins running fine. That's called the future.

Skins

- Skins now allow you to override any template function without the need for a file edit. A serious milestone for me.

- Official support for IE 11 (although I've since uninstalled it), and interestingly, added a converter to automatically turn modern CSS flexbox into IE 10-compatible syntax (on IE 10 only, of course.)

- Skin options and actions can now be limited to a specific page, page type (board?) or action on the website. They can also be limited to a specific browser or anything accessed through we::is(). Finally, script and css tags allow including an external JS/CSS file in any of your targeted pages.

- And, best of all... Themes are now GONE. Well, almost. Removed thousands of lines of code pertaining to this outdated, horribly complicated system. More still to come. Skins in Wedge are powerful enough to replace 100% of a theme's capabilities, so it shouldn't be a problem -- just requires learning how to write a skin, which is just a matter of reading through a commented XML file!

Bug fixin'

- Removed hundreds of unneeded globals, and added many globals that were needed, but undeclared (I'm surprised I could find so many). This is all thanks to the fix-globals.php tool script I wrote for this very task. It's much, much easier than installing HHVM on a Linux VM, and running it on my site. Seriously.

- Fixed many old SMF bugs. And old Arantor bugs, too. And a few of mine, of course.

:ph34r: » Things left to do- Remove themes entirely. Working on it.

- Modify folder structure. I'll move all non-code elements to a root /assets/ folder, and probably move the /skins/ folder to the root, too, although maybe under the '/themes/' name -- I'll decide when it comes up, it all depends on whether templates go to /themes/ or /templates/. Obviously.

- Flatten skin folder structure (as indicated in the previous blog post; the code for this is already written, I need to rewrite it a bit though, before I can commit.) This will allow you to have sub-folders in your skins, where you can put your assets, or even replacement templates.

- Moving AeMe comments to topics, and topic attachments to AeMe items: there's a very small chance it'll be in v1.0, though I certainly won't postpone it for these features. I put them aside for too long, I'll have to deal with writing an automatic import session, like I did for buddy lists.

- New personal target for first public alpha: January or February 2014. I could have said "late December", by giving up on visiting my family, watching new Doctor Who and Sherlock episodes, and having a life more generally. It was a tough choice.

So... What do you think about the post-Arantor era? Is it the same Wedge you've known all along, moving fast and in interesting directions?[2]

Apparently, generic stupid questions that you already know the answer to are a must at the end of a blog post, as they're supposed to increase user engagement. Don't make me say I said it, though. Because I didn't! Do you think I did? Feel free to say it!

rev 2345 -- this huge commit is NOT pushed to master yet; I'm pushing it to the byebye-themes branch, mainly to test branching. I may rebase my stuff, although I'll try to avoid that. 185 files changed, 1939 insertions(+), 2828 deletions(-), 169.14 KiB (record beaten! And unlikely to be beaten again :P The actual diff patch size is 717KB, and I'm going to go through it again, yay.)

@ The previous commit, despite its size, was a joke compared to this one. Removing theme support (while keeping support for 99% of its features with intelligent skinning) saves a surprising amount of code. Most files get a few kilobytes shaved off their size. Everything done by hand (and triple-checked!), but I'm still expecting many things to be broken for a few days/weeks. I'll fix as bug reports come.

* Renamed all $theme variables to $settings equivalents. $theme, the equivalent of SMF's $settings, is gone. Forever. (There are 120 files or something in this commit, I'm not going to list them all.)

* Replaced $scripturl with SCRIPT and 'theme_url/theme_dir' with TEMPLATES/TEMPLATES_DIR everywhere. Lots of fun. Same with images_url/dir and ASSETS/ASSETS_DIR.

* And more importantly, renamed we::$id to MID most everywhere. This is about twice faster, and, I guess, easier to type and remember.

- Removed theme support from a lot of places. Again-- not listing these all. Basically, many areas will now consider there's only one theme, and that's all there is to say. They'll usually accept multiple skins, of course.

- Removed unused globals as found by the new version of my fix-globals script. (Class-Skeleton.php, Class-String.php, Notifications.php, and maybe a couple others.)

- This $theme['smileys_url'] alias hadn't been used for years. (Class-Editor.php)

- THEMEURL and DEFAULT_THEMEURL have never been used as variables in email templates. Time to go. (Subs-Post.php)

* Replaced $settings['images_aeva'] with just a hardlink to the /aeva assets folder.

* Renamed show_avatars and show_signatures user options to hide_* equivalents, as it used to be in SMF; this was partly motivated by the fact that most user options have a more sensible 'off' default (except for return to post and quick reply, where it makes more sense to enable these), but mostly because it was buggy and I had to fix it.

* Renamed reloadSettings() to loadSettings(). It's never called more than once... (index.php, Load.php)

* Renamed a few variables to use $context instead of a setting. For instance, if you want to play with templates to be loaded, you should now do it with $context['theme_templates']. Although this one will probably go at some point, too. Or be renamed. Or whatever. Also, $theme['output_buffers'] is now in $context. (Load.php, Subs-Template.php)

* Moved path settings from Server to basic settings. Seriously, this never had anything to do with 'database settings', why mix them up together..? (Admin.php, ManageServer.php, ManageSettings.php)

* Rewrote the $boardurl hack for url_parts(). Thus making $boardurl non-changing across the page lifetime. (Subs-Auth.php)

! Fixed a Pete bug in loadEssentialThemeData stuff. Then removed all code related to the bug, including the fix. Because if you've been reading this changelog, I'm sure you won't mind reading an extra useless line. (ScheduledTasks.php)

* Harmonized member table column lists in loadMemberData; this saves something like 3KB, which is that less data the PHP parser has to load every page load. (Load.php)

* Slightly faster JS/CSS cache purging. (Subs-Cache.php)

Now, go ahead, Like like you've never liked a commit before!! Because that means I'm getting closer to a public release :P