Please define $actionArray earlier on in index.php

[SoLoGHoST]

Ok, this is becomming a huge nuisance for me within Dream Portal layouts specifically (but also has come up before, in my other mods and customizations, bothering the hell out of me).  The SMF $actionArray variable doesn't get defined until everything else has been checked.  And since this returns during those checks, the $actionArray doesn't even get defined if it returns out of it earlier (which really isn't that important to begin with for the most part).  But, what is important is...  handling actions that aren't defined within the $actionArray could be done much easier if it were defined earlier.  Among many other reasons for defining the $actionArray earlier, within the smf_main function, of index.php, could be beneficial to SMF in that, portals would be able to call 1 function to handle actions that aren't defined in this array, but also so that SMF can handle this much easier as well, in just 1 stroke.

Falling through after everything else has been checked (and possibly returned before ever getting to the $actionArray), to me, is not exactly the best approach for this when you can check it all at once and only call the BoardIndex once for all of these situations (instead of having to call it multiple times within index.php).  Why not just check it all at once and do what needs to be done.  Because honestly, urls like so:  http://yoursitedomain.com/smf/index.php?action=blahblahblah loads up the Board Index because the blahblahblah action isn't defined within the $actionArray, yet it checks a ton of nonsense that isn't even needed for this.  And portals have no way of knowing that this action isn't even defined within the array until it is already too late (therego the $actionArray being defined at the very end of everything in index.php).  Instead, just define the $actionArray earlier in index.php (instead of at the end of the file), and than have the other statements follow.  That, to me, makes more sense.  And if isset($_REQUEST['action']), check the $actionArray variable to be sure it is within this, than this can go to the BoardIndex only 1 time.

This also helps portals to properly identify with the page that is being loaded, with only 1 function call, that will be able to handle situations such as:  action=blahblahblah (where the action isn't defined within the $actionArray variable).

Just my 2 cents on that!  Am interested in what others think as well...

If you guys don't know what I'm talking about, or want to see for yourself, just go here:

http://simpleportal.net/index.php?action=blahblahblah

You will notice that the Home Button is active, but the BoardIndex is showing, not Home.  This is a problem in MOST PORTALS that I know of, because of the SMF $actionArray being defined too late within index.php and portals are unable to know if the action is defined within the $actionArray or not, until it is already too late!!  Ofcourse, we could call a function that helps with this, but than we'd have to call this function numerous times, as well, for all cases, would be redundant and messy to say the least.  Best way to fix this, is for SMF to define the $actionArray earlier on within the smf_main function, possibly after loadPermissions(); or after is_not_banned();.  Than we can find out if it's an action, if so, than check for it within the $actionArray and if found return the proper function, if not, BoardIndex.  And than portals will be able to handle this properly as well, by setting a default page to load for all instances of:  index.php?action=, index.php?action=blahblahblah, index.php?, index.php?action, etc. etc..

Easy peezy, lemon squeezy!

Basically, in short, IMHO, all of the $_REQUEST['action'], $_REQUEST['board'], $_REQUEST['topic'], and anything else that handles page loads, being checked for in the smf_main function that are above the definition of the $actionArray currently should be combined together in 1, MAIN, if... else statement that uses the $actionArray within those statements to be sure the action exists.  This would make it easier to set a default Home Page for situations where an action isn't defined within the $actionArray, and only have to call this function 1 time.  Currently, in order to do this, because the actionArray is defined way too late, you'd either have to call a function for every if... else statement or call the function more than once, both of which are undesirable.  But also, this is a more sensible approach as well when compared to what is currently being done in index.php.

Well, anyways, just a suggestion that I think would help to improve, not only SMF, but the extension of it for either portals, or other modifications that need to be able to catch the Home Page.

[feline]

If you guys don't know what I'm talking about, or want to see for yourself, just go here:

http://simpleportal.net/index.php?action=blahblahblah

You will notice that the Home Button is active, but the BoardIndex is showing, not Home.  This is a problem in MOST PORTALS that I know of, because of the SMF $actionArray being defined too late within index.php and portals are unable to know if the action is defined within the $actionArray or not, until it is already too late!!

That you can simple make with small patch in the index.php

Code Select Expand


// Fall through to the board index then...
require_once($sourcedir . '/BoardIndex.php');
$_REQUEST['action'] = 'community';
return 'BoardIndex';

You can see that on our site 

[Oldiesmann]

I'm not sure exactly what the problem is here. There's really no point in defining that array until we're ready for it - after we've verified that the user can see the board index, after we've verified that they aren't viewing a topic/board or the board index, etc. Why go to all the trouble of defining that array unless it's actually going to be needed?

It's really quite easy to change the default action. This line in Subs.php is what causes the "home" button to show up for undefined actions:

Code Select Expand

$current_action = 'home';

You can change that, or you can just change what happens when an action isn't defined, which is handled by this code in index.php:

Code Select Expand

// Get the function and file to include - if it's not there, do the board index.
if (!isset($_REQUEST['action']) || !isset($actionArray[$_REQUEST['action']]))
{
// Catch the action with the theme?
if (!empty($settings['catch_action']))
{
require_once($sourcedir . '/Themes.php');
return 'WrapAction';
}

// Fall through to the board index then...
require_once($sourcedir . '/BoardIndex.php');
return 'BoardIndex';
}

Problem solved.

[SoLoGHoST]

Yeah, I see what you both are talking about completely.  The problem I'm having is that I'm calling a function way before any of this code is defined within index.php.  And this is because it returns out of here several times before it even reaches the definition of the $actionArray, so putting that line in there, as feline suggested (which is a clever approach I might add), is still going to need to call the function multiple times...

It's not as simple as you folks have pointed out.  Take a deeper look into index.php and see it return out of index.php several times before it even reaches the $actionArray.  Calling a function to handle all instances of this would not be able to be done within index.php because of the returning out of here, unless it is called multiple times because it will be called before the $actionArray is even defined (in my case, before it returns out of anything).

Anyways, I have fixed this myself, it's not the best approach (which I'm unable to think of atm), but works flawlessly nonetheless!

And thanks for your suggestions on this as well.

@ Oldiesmann...

I'm not sure exactly what the problem is here. There's really no point in defining that array until we're ready for it - after we've verified that the user can see the board index, after we've verified that they aren't viewing a topic/board or the board index, etc.

Sure that is all fine and dandy when it comes to viewing the SMF software, but when mods add things that further expand it, based on actions, $_GETS, $_REQUESTS, etc., and don't need to check for all of the things that SMF is checking for (perhaps because a mod might use a different criteria that handles this) this becomes a problem.

Why go to all the trouble of defining that array unless it's actually going to be needed?

What's the harm in defining it earlier also?  Not like any security issue will arise from this that I can see.  Also, in my situation, it is very much needed, but instead I had to do a bit of a sloppy work-around in order to accomplish this.

[emanuele]

Why are you defining the action outside the actions array?
If the action is added to the array it is handled properly, if you are using another (custom) method then probably you have to deal with it entirely.

Or am I missing something?

[SoLoGHoST]

Your completely missing the point here.  If an action is not defined within the actions array, it loads up the board index, if action is not empty.  Just read my first post, it explains it all.  In all honesty, the index.php code is thrown together in a sloppy way, which makes it difficult for portals and other mods to attach to!

[SoLoGHoST]

Sorry, for the double post, but all I'm really saying is, that you can combine all of the checks into 1 or 2 if... else... statement(s) and still not define the $actionsArray until it is needed.  The main problem here is that board index is being loaded SEVERAL TIMES in if... else... statements before the $actionsArray is even defined causing portals not to be able to react to all possible times when the board index is being pushed onto the page, unless the portal calls the function multiple times, or handles its function within all of the if... else... statements, which would be ridiculous.

That is all.  Do what you will with that.

Cheers

[feline]

I don't understand, what the Action array have to do with a Portal ..
All what it's necessary can be handled by the Portal itself if it's load BEFORE SMF start his work.. note the hook integrate_pre_include  
From here YOU can controll what works and what not ...

[SoLoGHoST]

Haven't explored that possibility, but in any case, will still need to know if an action actually exists within the $actionArray.  Perhaps a combination of using the hook and in the index.php file, might actually work somehow.  Will take a look.  Thanks

[emanuele]

* emanuele points SoLoGHoST at WrapAction() too.

[bloc]

I did not have that problem with TinyPortal either. As feline suggest you simply rewrite the criteria for which the topic, board and "no action" are defined. Also, adding for example a "action=forum" to $actionArray - which goes to Boardindex - solves that problem.

SMF is always going to be a bit clunky with portals and new "homepages", because it assumes(and rightfully so) that "home" IS the boardindex, not anything else.

Wrapaction works fine for custom actions. Not sure how a home/frontpage is going to work there though lol, not if you want to use the root url, and not an action url.

[live627]

WrapAction is primarily for custom themes to define their own actions. Mods should use the hook.

[emanuele]

I know WrapAction is for themes, but (apart that I don't think it's so used and let a theme handle actions...dunno, doesn't sound "so" correct), you can always hook integrate_actions and then use something like that:

Code Select Expand

global $settings, $sourcedir;

if (empty($settings['catch_action']))
$settings['catch_action']['action'] = 'myDefaultAction';

A bit on the hackish side, but it should work.

The other option (probably more elegant) would be to always hook integrate_actions, then:

Code Select Expand

function my_hooked_action($actionArray)
{
global $modSettings;

if (!empty($modSettings['integrate_actions']))
$currentActions = array_merge($actionArray, explode(',', $modSettings['integrate_actions']));
else
$currentActions = $actionArray;

if (!isset($_REQUEST['action']) || !isset($currentActions[$_REQUEST['action']]))
return myCustomNonAction();
}


[bloc]

I've used Wrapaction in themes for years lol..but it does require a few bits inside the theme to actually work correctly: defining the wrapaction's theme layers + adding a extra layer that looks only inside a special folder inside the theme, rather than anywhere else.