Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Nao
31
The Pub / Repository name poll! Yayer!!
« on January 15th, 2014, 01:59 PM »
Advantages of wedge/forum: better URL, and if you fork the project, your repo's description has 'forked from Wedge/forum' in it. It's descriptive.
Drawbacks: if someone forks your fork, nowhere can you see that it's a fork of Wedge.

Advantages of wedge/wedge: see above. Drawbacks: it's repetitive, repetitive. But it's the convention around software built from an organization repo (phpbb/phpbb, mybb/mybb...)

Advantages of wedge over Wedge: none, it's just a matter of taste.

Choosing one of these isn't a big deal, but once it's chosen, I can't change it anymore. (Except for the casing in the organization name. But that's all.)
32
Features / Language revs
« on January 14th, 2014, 06:57 PM »
I'll be using this topic to 'tip' translators that some updated files are available on the languages repo. I may not do it all the time, though. For safety, just read through all New Revs posts, and see if I mention any language modifications. ;)

* Reflect folder structure changes. (Home, Install, ManageSettings)
33
The Pub / Name poll! For something useless! Yay!
« on January 14th, 2014, 09:38 AM »
They need to follow each other alphabetically.
34
The Pub / git rebase is a joke...
« on January 11th, 2014, 06:18 PM »
Okay, so this git rebase feature is a joke...
IIRC, the Wedge repo was built using svn-git, and then fully converted to git. It's got, due to its SVN background, a fully linear history (except at the end, when I was experiencing with branches.)

Yesterday, I decided to go ahead and do the full rebase I wanted to do, to fix these problems:
- Many CRLF fixes in the first commits, which should be concatenated to their parent commit, so that the CRLF problems fix themselves.
- One more CRLF fix in late 2012. This one's been bothering me for a while, because it adds two useless steps to most Git Blame operations.
- An empty commit (entirely empty, really.)
- An empty commit message (this is a wrong manipulation, but the message exists in the New Revs topic, it's rev 142.)

That was more than enough to justify the rebase.
So, I started off by rebasing the CRLF stuff early in the history. As a result, I kept getting 3-way merge errors, insisting that some files were missing, or other silly things. Given that it's a LINEAR history, and that the only work was done was to cancel CRLF line endings, there's absolutely no reason for these.
Any ideas?

After several hours of failures, I decided to give it up, and instead start fixing from the most recent commits, and then work my way up.
I got rid of the empty commit easily (all it took was git filter-branch --prune-empty), then did a rebase on the 2012 bug, which seems to be fixed. Okay, all good...

Now, onto that empty commit message. What I did was retrieve the SHA1 of the grandfather commit, do git rebase -i on that SHA1, then when the list shows up, change 'pick' to 'reword' in the empty commit message line. Then I save, it shows me a commit window, I paste my rev 142 content, quit, and it starts rebasing. Until the end. ALL GOOD.

Then I right-clicked the Wedge repo, Show Log, and... Funny. You can see the error message below.
It still shows me the master and all commits, but I can't access the branch list, and switch to any of them.
I then restarted from scratch (well, before the last rebase), and I still got the same. That reword rebase totally breaks my refs.

From what I could gather, between my broken Wedge's .git folder and the last valid one, there are a few differences. Broken has an empty refs folder, except for the 'stash' file. All its subfolders are there, but empty. In Working, all subfolders have a list of files corresponding to the expected refs (master, other branches, etc.)
OTOH, Working has an info folder with just an 'exclude' file, while Broken has an extra file in it, called 'refs', and which holds a list of all my branches, like this:

9c63905a2072705aaf93d12866e3f81890f5fc39   refs/heads/master

So, basically, I'm thinking I could just re-create the files manually in /refs/, but (1) it's taxing, (2) I'm never gonna know if I forgot to fix something else, (2) I'll probably have the same problem again when I try another rebase, (3) I don't even know why git (command line) doesn't complain (if I type git status, I get a list of branches), and TortoiseGit is complaining.

Can anyone help..? (ema? :sob:)
35
Development blog / You're talkin' to me?
« on January 10th, 2014, 04:16 PM »
Happy new year, then!

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:

https://github.com/Wedge/languages

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.
36
Development blog / Humble beginnings.
« on December 29th, 2013, 10:10 PM »
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
37
The Pub / Minimum PHP version?
« on December 21st, 2013, 02:20 PM »
I figured I could ask that.

I've often met situations where I wanted to turn silly create_function() calls into closures, but this morning -- more frustration for me. I figured I could rewrite the cache handler to basically link cache_get_data and cache_put_data together by putting the regeneration code into a closure, which would then allow me to easily benchmark regeneration times, instead of just cache storage times.

So, this just means-- "I'd really like to use PHP 5.3 in Wedge."
But then, it also means that a third of all servers won't be able to install Wedge. IIRC, Wedge.org runs on PHP 5.5 or something, and my Wampserver has PHP 5.3, so it's not a problem for me, and generally speaking I think that the '5.2 third' portion is likely to be a portion of servers that have either been abandoned, or just not maintained very often, and thus more likely to cause configuration problems when using Wedge.

In short:
- 5.2 is the current version required by Wedge. PHP 5.2 is great.
- 5.3 is a bit better, not THAT much better, but I've been wanting to do closures for years, just like I'm doing in JavaScript. Going for PHP 5.3 won't make my life much easier, and won't make Wedge better. But still, I'd like to look into it.

The competition usually has a required PHP version < 5.3: xenForo has 5.2 IIRC, SMF has something like 4.0 (lulz, but they're trying to account for website upgrades, while I'm betting on website importing), even newer software like esoTalk only requires 'PHP 5'. Vanilla, I think has a requirement of 5.1. The only 'popular' PHP package I know of that requires PHP 5.3 is Laravel, and it's a framework, not a forum package. So, both logic and statistics tell me to keep using 5.2, although maybe, well... Maybe it's okay, hence this poll.

Remember, Wedge is striving to remain compatible with as many browsers as possible; but when it comes to the server behind it, this is usually something that most serious webmasters CAN control, and personally, I like being in charge!
38
Development blog / Merry news and happy short delay!
« on December 18th, 2013, 11:30 AM »
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 everyone


New & 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.

Performance and tweaks

- Regular popups are now hardware accelerated. They look fantastic on mobile devices now.

- 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.

Ich bin ein Berliner

- Added full German translation, courtesy of Pandos.

Bug fixin' for the masses

- Fixed spoiler tags to properly accept spaces in their button descriptions.

- 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.

- Wess (CSS) files now accept the use of $txt, $settings, $context etc. variables directly in the code. Rewrote variable handling code for much better flexibility in @if tests (same for we::is PHP tests). Overall, this allowed me to remove a lot of CSS for non-members. Rewrote color functions to harmonize them. Rewrote math() function to allow a clear indication of variable types (int, float, boolean) and handle recursive brackets.

- 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]
 1. And also a good opportunity to celebrate wedge.org's 2001st topic?
 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!
39
The Pub / More constant names to consider.
« on December 13th, 2013, 12:33 PM »
After the ASSETS/IMAGES thing (which is yet undetermined, I'm waiting for a few more votes), I'd like to ask whether you think my terminology for new constants is all right...

'theme_url' => TEMPLATES (because eventually, the folder will only have templates in it)
'theme_dir' => TEMPLATES_DIR
'images_url' => IMAGES or ASSETS (see other topic)
'images_dir' => IMAGES_DIR or ASSETS_DIR (the variable doesn't actually exist, it's for consistency reasons.)
$scripturl => SCRIPT[1]
$boardurl => BOARD (this might be a problem, as $board is already a global var, and unrelated to it...)
$boarddir => BOARD_DIR (underscore might be a problem..? ElkArte uses BOARDDIR)
$sourcedir => SOURCES_DIR (again, underscore, too much?)[2]
$pluginsdir => PLUGINS_DIR
$pluginsurl => PLUGINS
$cachedir => CACHE_DIR (I'd like CACHEDIR better, honestly, but I can't fathom a TEMPLATESDIR either, and I want to harmonize everything...)

Also, $cssdir => CSS_DIR and $jsdir => JS_DIR, but these are not used in a lot of places ($jsdir is really only used in Subs-Cache), so I'm thinking maybe I'll just pass on the constants. Or maybe later.

I'm not going to put these for a vote (too complicated), but I'd like opinions on the naming scheme. Should I do with or without the underscore? Maybe go for a lowercase version of constants? (Nah, it's actually parsed faster with uppercase, yes I did benchmarks.) Maybe move 'DIR' at the beginning of the constant names? Maybe force adding '_URL' on $...url variables?

$boarddir, $boardurl and $sourcedir are all used between 170 and 250 times across the entire codebase, so it makes a lot of sense to use constants for these, so I don't have to global these. $scripturl is still used 500+ times, and that's even after turning hundreds of these into <URL> HTML. Wow... Well, this one definitely warrants a constant, once I can ensure the variable is not changed during the page's lifetime.

Opinions welcome -- really! Even if you're not a programmer.
 1. Also, there's the alternative of using <URL> in your HTML. Should I then name the constant URL..?
 2. I think the plural is important because the folder is named that way.
40
The Pub / Need opinions on a variable name...
« on December 12th, 2013, 01:30 PM »
This is about the variable that gives you a link to the images folder.
In SMF and Wedge, that's in mysite/Themes/default/images/
Wedge will shortly move that folder to just mysite/assets/ or mysite/images/ (haven't decided yet, but I'm leaning towards /assets/ because it'll also have /fonts/ font files, and /aeva/ SWF files in it. Basically, anything that's not a program should be in there.)
The folder name is important (and directly related to the constant name), because it WILL show up in the links in your HTML.

What should I call the variable..?
I'll also rename $settings['theme_url'] to just TEMPLATES. The name is not up for a vote here (unless I keep the $settings thing), because that's just what the folder will have -- templates. Well, I could possibly keep all files in the /Themes/ folder and have this structure: mysite/Themes/images/, mysite/Themes/scripts/, mysite/Themes/languages/, etc, but at this point, I'm not sure it really matters a lot... (Given the lack of participation on the website these days, I have a feeling the public release will be kinda underwhelming. I guess I have Pete to thank for that.)
41
Features: Miscellaneous / Cool stats!
« on November 26th, 2013, 07:21 PM »
Feature: Statistics charts
Developer: Nao
Target: everyone
Status: 90% (stats page believed complete; planning to implement on other stats, but not right now.)

http://wedge.org/do/stats/

Look at that... :)

Needs some work, most notably I'll implement some select boxes to automatically refresh data (or Ajaxively refresh it), so you can get a 'range' of your choice, and/or disable the entries that you're not interested in (new members, etc.)
But this is what I managed to cook up after a few hours of work, and I'm very happy with it. Great plugin, really! It only had a bug which prevented the tooltips from working, so I fixed that, and I may start contributing to the project, because I'm thinking of adding more details in tooltips, etc.

Feedback welcome, as always!

:edit: Read following posts to view progress on implementation, which is now 100% on the main stats page.
:edit: Moved the topic to public!
42
The Pub / Is the admin area in urgent need of an overhaul?
« on November 20th, 2013, 11:21 PM »
This was Pete's domain. I barely ever touched it in the 3 years I worked on Wedge.

Ever since I decided to remove theme support, I've had to cope with admin. It's just horrible.

Perhaps the worst offender is the 'general settings' page, which uses a completely different format for option lists. As far as I can tell, the ONLY reason for this difference is that these settings can either be saved to the database (as usual), or to a 'file' (i.e. Settings.php), but I don't really see why this can't be put into a special setting in prepareDBSettingContext, e.g. array('check', 'my_variable', 'where' => 'file'),... And voilà, the setting is going to be saved to the file instead.

What do you think? Can anyone think of a reason why it would fail?

Also, this special list has up to FIVE different non-keyed items. That's madness. name, label, target (file/db), type, size and help. It also accepts a keyed item, 'subtext'. It really, really doesn't make sense. The regular system has type, name/label/help (they're all linked together), and size/select-box content (depending on whether it's an int or an array.) It's much simpler to me, because usually all of these variables use the same $txt, $helptxt etc. for their descriptions.

Pages that use the 'weird' system:
- General settings
- Mail settings (webmaster e-mail goes to file)
- Server settings (maintenance status goes to file)
- Database settings (obviously)
- Cookie settings (cookie name goes to file)
- Debug settings (db_show_debug goes to file)

Apart from these, the rest uses prepareDBSettingContext, which is simpler.

Example:

array('autoFixDatabase', $txt['autoFixDatabase'], 'db', 'check', false, 'autoFixDatabase'),

Would become:

array('check', 'autoFixDatabase'),

Well, sure. That's a bit better...



Also, on another note. I'm currently in the mood for getting rid of 'small' admin pages with a reduced number of settings. The 'thing' with SMF 2.0 was to split long pages of settings to multiple pages. As a result, I tend to take some time looking for an option, when I could just hit the general settings page and hope that the option is in there (ctrl+F on the page). I've never been into the custom search engine for the admin area.
One thing that I like about FluxBB is that its entire admin area is split over a limited number of pages; it doesn't have a LOT of options of course, but I appreciated that my test setup of FluxBB was done by simply going to the admin area, looking at the general settings page, going through each option, and selecting what I wanted. In SMF 2.0/Wedge, I have to specifically click to multiple pages just to get the thing started (e.g. instead of general settings > minify JS/CSS, I have to also go to server settings...)
I took the Likes page (2 settings!) and moved it to general settings. I also took general member settings (enable contact lists, etc.), and moved them to the general settings as well.

I'm aware that it's a question of method. There are people who'll prefer the SMF 2 way, and others who'll prefer to have a long page with everything in it, as long as sections are clearly separated (in Wedge, I'm adding headers and big icons next to these headers, that should be more than enough.)
I'm interested in seeing who are the most vocal, though. Personally, I'll be vocal about avoiding multiple pages when they could be merged together. ;)
43
Off-topic / TV & movies
« on November 18th, 2013, 08:03 PM »
Just thought I should create a generic topic to discuss TV shows and movies as you like.
Because, well, there's already a Doctor Who topic for instance, but AFAIK it's on the Private area, and, well, it's only talk about the new episodes, so why bother with privacy...

Feel free to use this topic, or not, or just create other topics, I don't mind. Just thought it'd be nice to have a generic one. Maybe it'd be best to have a TV topic and a movie topic, I dunno.

I'll just pull a Shawn™ trick, and start with... "What did you think of yesterday's shows? Homeland/OUAT/The Walking Dead/etc."

PS: this is my 300th topic, apparently... :P
Well, that's one "Top poster" stat that I won't have for another few years, if not forever, because I usually prefer to re-use existing topics... ;)
44
Off-topic / A short script to remove unused, useless globals in PHP.
« on November 16th, 2013, 01:03 AM »
As mentioned in the thoughts area, I quickly wrote a script to find unused variables declared with the global keyword in your PHP scripts.

Just copy this into any PHP file, drop it at the root of your website install, and have fun! It's not 100% tested, but it seems to be working fine, so I thought I'd share it, if only because SMF needs to do something about their 1600+ unused globals. I know they don't take much processing power or anything, but it just sounds lazy to me to leave globals that are unused.

Feel free to improve it as you like!
I'm releasing this under the WTF Public License, for what it's worth. It's not long enough to even bother with a MIT license, although I dream of using that one in the future... :P

Code: [Select]
<?php

find_unused_globals
(dirname(__FILE__));

function 
find_unused_globals($dir)
{
$i 0;
$files scandir($dir);
foreach ($files as $file)
{
if ($file == '.' || $file == '..' || $file == '.git' || $file == 'other')
continue;
if (is_dir($dir '/' $file))
{
find_unused_globals($dir '/' $file);
continue;
}
if (substr($file, -4) != '.php')
continue;
$php file_get_contents($dir '/' $file);
preg_match_all('~\n(\t*)function ([\w]+)[^}\n]+\n\1(.*?)\n\1}~s'$php$matches);
foreach ($matches[3] as $key => $val)
{
preg_match_all('~global (\$[^;]+);~'$val$globs);
$globs[1] = isset($globs[1]) ? $globs[1] : array();

foreach ($globs[1] as $find_dupes)
{
$dupes array_map('trim'explode(','$find_dupes));
if (count($dupes) > count(array_flip(array_flip($dupes))))
echo 'Found duplicate globals in '$file':'$matches[2][$key], ' -- '$find_dupes"\n";
}

preg_match_all('~\$[a-zA-Z_]+~'implode(', '$globs[1]), $there_we_are);
$val str_replace($globs[0], ''$val);
if (isset($there_we_are[0]))
foreach ($there_we_are[0] as $test_me)
if (strpos($val$test_me) === false)
echo 'Unused global in '$file':'$matches[2][$key], ' -- '$test_me"\n";
}
}
}

To do the opposite operation (i.e. finding globals that weren't declared in a global keyword) isn't going to work with a short script -- unless you only look for the 'usual culprits' ($context, $txt, etc), in which case, yes, a short script is doable, I guess. But for that, I'm using HHVM. It's working fine, and is very smart about it. Only problem, it only works on Linux, so I had to install a VM to run that VM. Amusing. And install tons of dependencies. And go through many more steps of the program not wanting to run (the joys of permissions), then not wanting to start operating (the joys of parameters), then not wanting to complete (the joys of JSON bugs in Ubuntu.)
It took me several hours to go through it, but I found over 400 documented 'bugs' in Wedge, some of which I believe are in SMF/Elk as well, not that many though, but I'll try to document those I find important for them to fix.

:edit:
- Fixed most single-line function declarations.
- Added a 'duplicate global definitions' part. If you have a line that says global $txt, $context, $txt, the script will now tell you about it.
45
The Pub / git problems for non-gits.
« on November 12th, 2013, 08:02 PM »
Okay, maybe in the public area there are people who might know much more about git than I can... ;)
So this is a 'generic' topic for git-related issues. Feel free to use it for you, too.

I did my folder moves (for the theme removal stuff)[1], through a series of git mv old_long_folder/* new_short_folder/ commands, and it's working.

Now, when I right click Load.php (or any other file, really) and click Blame, TortoiseGit shows me a history of the file. I can click anywhere and go back to any old commits, so it's definitely doing git blame --follow. However, when I right-click a line and ask for 'Blame previous revision', it gives me this error:

Blame error
fatal: no such path sources/Load.php in (old commit ID)

Yes, of course that file wasn't there. But, Blame tool, you KNEW that, since you're listing all revisions of the file across renames! Git being able to find renames and code moves with needing to specifically track them is supposedly one of its biggest assets!
So, why do I have to go through that..?!
Am I condemned to go through filter-branch and tree-filter, and rename all files manually in the entire history...?! That would be an awful thing to do.

PS: I tested with Git Extensions and SmartGit, the first doesn't even react when I ask for an earlier commit, while the second one will show me earlier commits, so that's great, but the tool itself, I'm not really convinced by it, and I'm definitely sticking with TortoiseGit.
 1. BTW, I'm unsure whether I'll keep both 'scripts' and 'sources' folders side to side in the root. I tend to click on 'scripts' when wanting to view PHP files, and 'sources' when wanting to see JS files, so... Maybe it's just me, but if any of you has a suggestion on renaming the 'scripts' folder to something short and sweet and understandable, knowing that the name 'js' is already taken by the JS cache, I'm very open about this.