Wedge

Heh, yeah, I can see the logic. Just that people do ask quite a bit how to enable it because it is generally considered to be conducive to getting people to post.

And I'd never heard of Machinae Supremacy before...

OK, neither of those changes were supposed to be committed. I have to use 127.0.0.1 instead of localhost to avoid a 1 second lookup on every single page to resolve the domain name in MySQL. Never understood why, just that since using WampServer, that's been the case.

As for smf/wedge, that is my boardurl, and when I was messing around trying to debug the above, I set that and forgot to revert it.

The main reason for ucfirst, as far as I can tell, is simply to indicate importance on folders that shouldn't be writable by defaults (notice that avatars and attachments are, but everything else isn't) but I have no reason to leave it as is, it's cool to change it.

This isn't finished, btw. It's a milestone that I consider practical for committing, as in the first usable version. There's plenty more to do but it is usable for activating add-ons even in its present form, and the bulk of add-ons shouldn't need much more than this anyway.

As I suspected.But why in other/Settings.php and not your own Settings.php file...?I'd really like to change it. Anyone else?
The only issue is really with the Themes folder. But then again we could use the opportunity to rename 'default' to something shorter or just delete it...Okay.

Now for something completely stunning...

HO-LY-FUCK.

Really.

This is what happened to me today.
This morning I was looking at my Wedge.org import running Wedge, and was thinking that I really should get started on converting the homepage. But since I don't want to do any changes to the main codebase (so that I can easily update it later), I decided to go ahead and implement custom homepages. Are you following me.....? :whistle:

I was working on changelogging my new commit when you did yours. I mentioned I couldn't look into it because I was finishing up my feature.
Then I committed.
And it failed.
Oh, I have a conflict in index.php?!

Launching index.php...
OMG.
First line of the conflict, yours:

"      // Some add-ons may want to specify default "front page" behavior. If they do, they will return the name of the function they want to call."

Re-OMG.

This is the first time it happens to us. It happened that we had conflicts because we worked on the same 'generic' file at the same time. But it's the first time we both decide to implement the exact same feature on the exact same day and end up getting a conflict.
Heck, I hadn't thought of the homepage stuff for months...!!

Now to analyze this conflict and try to find if we can find a common ground...

Okay, I'm looking into it...

- I like your version because add-ons can specify where to go by themselves. However, what if two add-ons want to redirect the index..? I'd rather have them add layers/blocks to the index, instead. Also, I have to admit I'm not used to your add-on system yet -- meaning that other SMF admins may not want to look into it, i.e. why should they develop an add-on just to add a homepage to their forum...? I was considering instead posting somewhere a documentation about adding a Homepage.template.php file and doing everything there.

- I like my version (:P) because it allows the admin to specify a board as the default entry point. I renamed all boardindex entries to 'action=boards' to make it sound less like an 'homepage' and more like just what it is -- the board list. Your version doesn't allow a board as an entry point because it's called after the loadBoard function.

- Your version allows to specify a function name in addition to a file name. I simply have a single string for now, allowing to choose your action, ultimately I wanted to simply load the related file and run the function with the same name, as is the case in almost every single action in Wedge.

- I don't understand the difference between default_action and fallback_action. My version actually calls a short extra function, index_action(), which first looks for the value of $modSettings['default_index'], and if the file doesn't exist, it redirects to 'Boards' (i.e. 'BoardIndex').

I'd be tempted to say I like my implementation better, if only because it can ultimately be modified easily by the admin from the admin area, choosing a default board or a file from the available list. However yours seems more streamlined than mine. I'd like to know your opinion on this. Do you want me to send you my file?

It is pretty funny, actually, though we had briefly mentioned the idea before.

OK, so what's the difference between the two hooks? It's really for portals more than anything. One path is what to do if no action is specified (check for board and topic, and indeed anything else that might be specified by URL without expressly being action=something, like SP does with pages)

The second path is for actions that are requested but don't exist, so that you always get back to *something*. WedgeDesk expressly uses both hooks, though it runs the same function either way, because of its standalone mode that removes actions.

My version wasn't really designed with the goal of allowing a board to be loaded by default, it was designed so that any add-on that could override the default action can actually do so.

Pushing the board index to its own action is a good idea (though that does mean other things do have to be fixed, I have a list somewhere of URLs that expect index.php to be the board index) and I think it would be nice for admins to be able to set a default action, so ultimately from mu POV, having both would be great, provided that add-ons can if necessary override that behaviour, which is what the hooks allow for.

You mention doing it through blocks but for the specific uses I have (and I can find other more general cases), this isn't enough. WD's case is unusual but follows the pattern of all the portals where it replaces the board index entirely under some circumstances, in particular standalone mode which means to disable the forum entirely and just use WD code - having the board index is not merely inaccurate and superfluous, it's completely undesirable.

I also doubt that most admins will develop add-ons, but that one will exist that they'll use to perform that task, and I'll likely write it...

As far as conflicts go in terms of which add-on gets priority, I'm not expecting that to be a huge problem in most cases, simply because most of the time it actually won't matter. But a priority value might make sense to implement to deal with that, though that also has implications, e.g. authors blilndy setting max priority all the time. That part is still a WIP really.

Thing is. Addons can already override the default action (provided we send $action to them or globalize it), through 'behavior' for instance. They just add their action to the action list and rewrite the action or even manually modify the query string. I'm not sure adding more options would help anyone here.

As for urls the only ones I can think of have #category in them and yes I was planning to fix them in the following commit ;)

Let's say we want to offer page= as an option in the URL, like topic and board. Ae you saying that during the behaviour hook, they should just proceed to make the test and force it to their action if found? Seems a bit ugly to me, though it's the most workable compromise.

The fallback action really should be left though, otherwise if an invalid action is specified, you are doomed to go to the board index. Assuming your default will be applied in both places, I guess that's OK, but it does mean that an add-on actually has to do some work if it actually wants to be the front page, because it has no other way of overriding the admin's choice other than fudging the modSettings value softly, as opposed to setting up a hook. (And the same issue about contention applies, only worse because there's more places that add-ons can affect that value rather than centrally)

I don't know, we can still work it out later. Right now I'd just like to commit my stuff because my copy is broken otherwise ;)

BTW I managed to mix both of our implementations together. Your hook is called first, so it gets priority, and then my own code is implemented. However, my default board code is run before any of the two hooks, so it gets the top priority, but on top of that, the behavior hook now gets to manipulate $action so it can override the default board. Hopefully I managed to find the best logical balance here.Yup. Don't worry, I kept it in.Well, that was how I was envisioning the idea. Add-ons are great and everything, but we shouldn't consider they're not able to modify any setting in Wedge, because they can, plain and simple ;)

BTW, in reloadSettings() there's some long code related to the hook system... I haven't looked into the rest, but is it needed? Didn't Wedge already load the hook list somewhere else..? Or is it related to some design issue we hadn't seen before?I don't see how, though. At least as a humble mod author. (Oops, I said "mod"! ::))

Okay for add-ons... I'd just like to make sure we're not wasting time (CPU cycles) on something that'll never happen.

Well, categories are what I was working on right now...
The URL I chose for now is action=boards;cat=1
I could use action=boards;c=1, though, because some items in Boards.php use 'c' instead.
Anyway that can be renamed easily later...

I'm not sure about index.php?cat=1, though. That would imply, again, extra CPU cycles in the index file.

Disable hostname lookups (or reverse DNS, I forget what the exact setting is called) in MySQL itself. That should solve it.

No, it's likely it will be used in the manner I describe. I did, before, get into the realm of physically registering hooks but I found cases where it could go badly wrong if something was set to disable and it actually didn't.

I take your point about categories, I just think it would be more consistent as cat= rather than an action, but that it would have an impact on index, even though it can be downplayed to check if action is unspecified and only after board and topic have been tested for.


@Aaron, I tried to do that but was not having a lot of luck with it.