Wedge

I tried using the pull request workflow from Github on my fix-globals tool.

What a complicated task, if you'll ask me... :-/

- Clicked Fork on the Wedge/tools repo
- Updated my local repo to add an origin remote to my Nao/tools repo, rename the Wedge/tools repo to upstream.
- Made my local commit. (Forgot to make it to a new branch... Oh well, whatever. One day, I'll remember.)
- Pushed to origin. By default, it wanted me to push to upstream.. Well, no.
- Went back to the website. Clicked Pull Request. Filled in the details, then realized I'd made a typo...
- Went back to local, 'amend last commit', fixed changelog, committed, pushed (again, to origin).
- Went back to website, pull request, submitted.
- Went to the upstream repo pull request page, commented (I have to say, the design is really confusing, compared to Bitbucket.)
- Clicked Merge Pull Request.
- Went back to origin repo, it said the repo was up to date. Eh, really..? But it doesn't have the merge commit?!
- Went back to local, pulled from upstream, it added the merge commit. Then pushed to origin.
- Went back to origin repo, and now it has the proper history.

So, that means:
- I didn't have to play with rebase at any point. Does that mean I'm free from it, or not? Is rebasing needed only when committing from another branch...?
- There's an AWFUL LOT of going back and forth between my local repo and my two remote repos.

I was thinking of using that system for Wedge commits in the future (once it's on github)[1], but I don't know if I'm willing to bother, really. Basically, if I consider my local repo to be the 'official' one, then I guess the workflow is completely different, and I'll have to learn it (again).

What do you think, guys..? Anyone experienced enough to tell whether it's 'proper', or there's an easier way to do things, or it just gets easy once you do it enough times?

Why the hell does the 'Signed-off' mention only show up in the extended log (i.e. I have to click the '...'), meaning that if I want to check for sign-off status, I have to click Commits, then for each commit open the ..., and pray that it's there..? Why can't github 'simply' add a 'signed-off' *icon* next to the commit entry, so I can immediately tell if it's okay..?

1.	Maybe with the hope that I can use Nao/Wedge as my proper work place, and Wedge/Wedge as the place for stable code to be moved to, so that I can afford messing up my pushes and force-pushing them again, with the hope that no one will be forking my own work repo..????

No more poll votes since yesterday, so I'll be going for assets in both folder name and constant name! With, as promised, an alias to images.

The goal with we::$id was to avoid globaling $user_info. (Also, I wanted to harmonize $user_info and $context['user'], which were a real mess to begin with!)
However, testings at the time showed that calling a static class variable was approx. twice slower than calling a simple globaled variable. I could have done $GLOBALS['user_info']['id'] which is only ~10% slower than using the global, but that's ridiculous.
I looked into constants at the time, but had too many issues with redefined variables, and didn't want to look into it, so I went for the object thing. I'm glad I did, but still, wasn't happy with the performance impact.
This came back to me when I got rid of themes and decided to directly go for constants for the newly created path pointers.
And then I came to we::$id, looked into it again, much harder this time, and as you see... It's very doable, really. In fact, I'd be hard-pressed to find any plausible reason not to do it right now. Yes, sure, we::$id is going to co-exist with MID, but you know what..? That's fine. Because no one but me ever complained about $context['user'] being a duplicate subset of $user_info, I see no reason why people should complain that there's a duplicate variable in memory. I'll probably even give up on it; after all, the only issue I could find was with the use of we::$id once in ob_sessrewrite, and that use is particular to linking to one's own profile. This only comes up if a particular setting is enabled in the forum, AND you're banned. And you know what..? If you're fully banned, and you can't access your own profile, then what does it matter that it's properly linked to, since all SMF (mainline and forks) will always link to it anyway, but prevent you from accessing it after the click? Wedge prevents that, but in the case of a full ban, it won't do it for your own profile. Which, really, would be AFAIK the only issue that happens if I immediately removed we::$id altogether.
There are battles to be fought, and wars to be won. This? It's not even a quarrel.It only has two reasons to change AFAIK, and it's (1) logging in, (2) being banned. Being banned is easy. Logging in, it shouldn't matter either, because you're being redirected anyway (so that you can take full benefit of your logged status from the beginning of the page load process), and you're only benefiting the user ID from the moment logged status is accepted, to the moment you're being redirected. I'm sure I can follow the entire code path in five minutes, and determine that the user ID is never actually used once in that path, and setting it was useless to begin with.

And then off we go, bye bye $user_info['id']. It's valid for ElkArte just the same as Wedge, really.

Regarding MID, I looked into something I feared -- the possibility that we::$id was being reset after being set once.

It happens, AFAIK, at least twice:

- DoLogin function sets it after you're logged in. My gut feeling is that at the very worst, I could add an extra redirection to ensure MID is set up properly from the database.

- Security code: the ban code ends its run by stripping the user of any rights they have, AND their we::$id variable (it's set up that way in Elk and SMF: $user_info['id'] = 0). I'm thinking that it could be possible to just leave that aside -- we::$is_guest should be enough to guarantee that a page will become inaccessible to the user, and if some page 'only' does a test on we::$id/MID to give access or not to a feature, then it's doing things wrongly, and should be fixed.

What do you think..? Worth it or not?
we::$id is used about 750 times across the entire codebase. I don't want to use a $mid global as replacement, either. And $user_info['id'], ah ah, no thank you, been there done that...

I wasn't about determining if member or user should be used, more about MID or UID, that's all. ;) Member, in SMF terminology, is a logged in user. And a user is either a guest, or a member. $user_info['id'] determines its status, but it's still a 'user'.
I guess MID works because I can always do if (!MID) to determine if the user is a guest -- it's less self-explained than if (we::$is_guest), but it's also a bit faster to execute.

One of my harmonization problems with these constant names is really SOURCES_DIR. Considering that there's no matching SOURCES (you don't need to access that folder by URL), it would make more sense to use SOURCES for the path, but then it's in conflict with all other constants, which use _DIR to denote a path. This is really the only reason stopping me from adopting that naming scheme, although I could also just as well keep using $sourcedir everywhere. I don't know. It's still used 231 times in Wedge, but mostly in non-Sources and non-Templates files.

Bit do they have non-images in these?

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.

I'm taking note!
vote leaning towards either images or assets.