Wedge

The way I'm going..? Well, I think I explained enough of it on the blog, didn't I..?
- I'm keeping most of the stuff that Pete developed for Wedge; I may remove some of his stuff at my own discretion. (Right now, I'm only considering removing the admin homepage, I'm just trying to get the thing right in my mind before I get started on it; also, I'm removing some changes he made to the theme system and related satellites, considering I'm removing theme support altogether.)
- I'm finishing (or rather, trying to finish) the things I've been working on this year, such as privacy settings, and contact lists. (Both of these are suspended right now, as theme removal is taking more time than I'd have wanted; it affects a lot of features, and I just don't want to work on several things at the same time, my hands are full already.)
- And I'm giving up on trying to appeal to noobs, instead I want to focus on people like me who are power users and want the best product for them. Some of the changes Pete and I did, though, are definitely more noob-friendly than in SMF, but that doesn't mean Wedge is noob-friendly per se. It's just trying to help regular users, and dedicated admins, but the one area that I'm not going to focus on, is making everything 'easy' (I'd say 'cheesy') to any admin. For instance, SMF's way of doing things since SMF 2.0 has been to multiply option pages. My way of doing it, is grouping everything that matters in single pages, so if you're afraid of long pages with many options (even though there aren't more options than in SMF per se), Wedge is not for you.So many? I don't know... Notifications need some work, that's for certain. Board types, too. And I still don't know what to do with the BBCode rewrite that pushed everything into the database. I'm not thrilled about making some UI for them, and I'm strongly considering restoring them to PHP code that people can modify/extend through plugins. In fact, it doesn't even stop the possibility of modifying them through the admin area: you can just load them from source, then check the database to retrieve any modified code. Honestly, I don't know why Pete didn't do it that way, because modifying BBCode has been a nightmare for me. (He never really touched BBCode after he made the transition, so he probably won't remember.)The problem with you (well, not with you, but in your situation) is that you're a collateral victim of Bitbucket problems. And, the fact that I'm only a Git rookie, and I still haven't found out how to best handle collaboration on git. I'd appreciate help from Wedge contributors who have experience with git, but right now they don't seem to be interested in contributing. (John, Shitiz, Thorsten..?)
Not a biggie, but that could have helped transition, I suppose.I'm betting on the fact that it won't. People just won't know.
Seriously, while I haven't been advertising it, I've been giving Git access to the repo to every single person who asked me for it -- that is, just you. I tried to give it to more people, including people who work on the competition and whom I trust enough (ema, Suki...), but they wouldn't want it; which I understand, but the fact is, right now, 'regular users' don't seem to be interested in Wedge.

The only reason the code isn't public right now, is that I want to be done with the folder structure change because I release it. I already have, written down, a list of 'steps' to go through to make the transition from old codebase to new codebase, and it's not pretty. If you don't have to go through it and you can start anew, then it's all for the best. But if someone's foolish enough to want to run Wedge Alpha on their live forums (which is doable, after all I'm doing it here), then I don't want them to feel overwhelmed by regular changes in the folder structure or something, which is why I'm doing things like this poll. (Which, oddly, is all about a 'variable name', when it really is about a folder name.) (And, not in the poll, but determining whether languages+scripts should be root or not, is also important to me. I'll go for root if nobody is against it, BTW.)Well, there's always the 'New revs' topic, for that... Isn't here? I know some people read it, since I regularly get new 'likes' on these. (And I'm thankful for it; it helps me go on, because I really appreciate feedback, even if it's just a Like. I'm not adding support for Dislikes because frankly, a dislike should be supported with a written opinion, and people can do that by themselves on another topic. :P)My to-do list is ever-increasing. It's frightening. The principle of a to-do list is that you put things in there that you want to 'defer'. I'd call it 'wish list' if I could afford it, rather than 'to-do list', because every time I read through the list, I keep finding features I think will be great, but that I don't want to write right now.
Heck, I should probably maintain a wish list AND a to-do list. That is, if I'm out of inspiration, I can get quick things to do from the to-do list, and if I'm done with a release, I can go through the wish list.

I posted my to-do list by PM to Arantor several times; there are a few features he said were good ideas, but I don't remember him ever implementing anything from that list. (Which was the original goal, right..?)

So, yeah, I could post my to-do list here, but I know myself, I'll just remove any items that may seem 'dirty', and end up making a poll of whatever feature you want me to work on, and I already know what features I want to finish first, so it's not going to be very helpful.What's 'Share this topic'..? The sendtopic action? Yeah, I don't know... I've never even used it, but I think it makes admins feel better if the option is there, see..? So I don't think it'd be a good idea to remove it. Maybe more it removable from the admin panel, I don't know.
(What 'did' I think? Is it something that was discussed before?)Well, AFAIK your own e-mail address is used as the source, so you can't accuse the forum itself of spamming you, just the user...

---- A pretty fine update for this script! For whoever's interested, it's now finding 180 matches in Wedge (it used to be at zero, excluding unprocessed false positives.)

[master a98b243]
 1 file changed, 55 insertions(+), 10 deletions(-), 2.98 KiB
 rename unused-globals.php => fix-globals.php (52%)

+ New feature: searches for undeclared globals. Doesn't attempt to fix them yet, but will detect false positives inside comments. You have to provide a list of common globals, I used a selection of Wedge globals, do as you like with your version of the script.

+ Added support for class methods.

+ More color codes, and a subtle gradient background for differentiating between error types.

* Renamed script to 'fix-globals.php', considering that it's been some time since it was limited to just finding unused globals.

rev 2344 -- FREE, AT LAST!!!
 39 files changed, 155 insertions(+), 269 deletions(-), 59.72 KiB
 delete mode 100644 Themes/default/Settings.template.php

@ Okay, so this one's a pretty big commit that consists of the bulk of my work on progressively removing $theme variables, and replacing them with either $settings or $options (mostly $settings), or just removing them. I tried listing all files related to respective changes, but honestly, there are so many, I tried twice and failed to gather everything, and I doubt anyone reads through my file lists anyway. Suffice to say, there are tons of stuff.

* Moved show_board_desc and show_children from user options to settings, and show_stats_index, show_latest_member, gender, avatars and blurbs from theme settings to regular settings. I can't think of a single board where I've seen these settings modified anyway, and worse, can't think of a single reason why I would have overridden them. No need to clutter user space with that. (ManageMemberOptions.php, ManageSettings.php, Boards.template.php, Display.template.php, InfoCenter.template.php, Admin.language.php, ManageSettings.language.php, Profile.language.php, install.sql, updgrade.php, upgrade.sql

- Removed setting for warning on new replies. It's on, by default, forever. Live with it. I know that people will ultimately be thankful their new posts aren't ignored by you. (ManageMemberOptions.php, Post.php, Post2.php..)

* Renamed $theme['require_theme_strings'] to $context. Still settable through plugins or templating. I don't remember adding support for extra language strings into skins, so that'll stay for now, but as soon as that is done, you're gone baby, gone. (Load.php)

* Started to merge $theme['default_theme/images*'] variables with the regular non-default ones. (Load.php, Subs-Template.php)

- Removed $context['show_login_bar'], which was an alias to two variable tests, except that all further uses of show_login_bar would systematically reproduce one of these tests, so that's one waste of a test. (Load.php, index.template.php)

- Removed $theme['use_image_buttons'] and $theme['use_buttons'], which were barely used anywhere anyway. (index.template.php, ManageMembergroups.template.php, Memberlist.template.php, ModerationCenter.template.php, Profile.template.php, Search.template.php, Who.template.php)

* $context['menu_separator'] was barely used. Renamed to 'page_separator', and allowing skins to override that. It's probably never going to be used, but at least you can use it to insert extra data in that place through a plugin... Whatever. (Load.php, Display.template.php, MessageIndex.template.php, PersonalMessage.template.php)

* Renaming German language to remove the two-letter code. Basically: if a language is seen as the de-facto 'default' variation, then it doesn't need the code. 'French' and 'German' are exempted. UK English is used by less people than US English, so it's hard to pick a de-facto default here, and thus they both get a code. (index.german.php)

! Wrong function name. (Profile-Modify.php)

- The rest of my uncommitted unnused globals cleanup. (Stats.php, Display.template.php, Msg.template.php, etc.)

* Oh, bugger... That border-box revert isn't going to be so smooth, I forgot one file in the list. (sections.css)

* Moved unread post count to a more proper place in blog homepages. (MessageIndex.template.php)

- Removed Cuil from the list of search engines. It died just two weeks after I started work on Wedge. How amusing. (install.sql)

- Removed unused theme variables, linktree_link and show_bbc. (install.sql)

@ I'll deal with the removal of Settings.template.php later, if you'll allow me.

rev 2343
 7 files changed, 17 insertions(+), 7 deletions(-), 1.60 KiB

- Reverting the universal border-box. I was happy with the results, but then I remembered that IE6/IE7 didn't support it, and would be systematically broken. I won't add more hacks for these, and I still want to retain at least a bit of usability for these silly browsers, and reverting only adds a dozen bytes to the final gzipped file, so... What the hell. I'll look into this again in a few years, if it keeps bugging me. Border-box is an excellent universal selector to use, better than the content-box default if you're starting a new project. Fixing a large, complex older one..? Probably not so much. (editor.css, index.css, index.member.css, mana.css, media.css, sections.css, zoom.css, Wireless/extra.css)

@ Note: I committed too much of index.css, so I forced a reset of the remote and amended my commit to only have what it needed. (If I ever need to unrevert this... :lol:) --> so, if you updated your repo during these two minutes, it's now broken.

rev 2342 -- this has been a bit of a nightmare, but the result is quite good.
 6 files changed, 595 insertions(+), 449 deletions(-), 7.04 KiB

* More work on the stat charts. (Stats.php, Stats.language.php, stats.js, wraph.js)

  + Added the ability to zoom into a specific area of a chart when it's got more data available (e.g. on the 'Lifetime' chart.) Just drag around the area you want to zoom into.
  + Added pseudo-separators, i.e. when the chart reaches a new month or year, it shows the label in bold. If this step is skipped, then the next available step will be bolded.
  ! Fixed hovering and clicking on mobile devices.
  + The range select box will be updated to show all ranges accessed within this page load.
  * Optimized speed of tooltip renderer. Shouldn't be noticeable, though, but still...
  * Tweaked number of steps to avoid being overwhelmed by useless details.
  * Tons of spacinazi and related changes to the Wraph library, to make it fit the Wedge coding guidelines.
  * Ajax indicator.

@ Need to implement a button to 'cancel' a zoom. I'm not sure about the UI for that, so it's postponed for now.
@ Known issue in mobile: tapping an empty area with a tooltip opened somewhere else will not hide the tooltip if you're on a daily chart. I know why it happens, just can't bother to add more code to 'fix' that.

My zoom feature is 90% done. I'm currently able to select a range, although I'm not doing anything with it (for now.)Yup, and I think I improved (a bit) on the original script, when it comes to visuals. Just little details. The bulk of my rewrite, though, was in adding many, many more features that I think are useful in daily use...With my new technique, I could effectively go up to about 50 years, so maybe it just makes more sense to say 'lifetime'.
I'm renaming the 'last_decade' variable to 'all'. That should do. 50 years, in Internet time, is like 2 millennia... (Hmm, Chrome insists on saying that's a typo. No, it's not..?! Or maybe it doesn't agree with my comparison, I don't know...)
So, considering Wedge is unlikely to be used in 50 years, and even if it is, it'll only make the charts very ugly (rather than 'simply' break), I'm okay with not having a limit/range on these queries.Well, if you're talking about Page Hits (which is as close as you'll get to Topic Views, since that particular stat isn't tracked in {db_prefix}log_activity, just like in SMF or other forks, but theoretically could be added through plugins), it's also trending down. But it only makes sense, because if you're replying to a topic, chances are, you're viewing it first...Well, duly appreciated!

Keep me posted!