Ive been writing some code for a mod and have contained all my menu functions in a modify file seperate to the SMF install so it just calls that file for the settings ect. The problem ive got is in admin.php where a mod writer is supposed to add the code we have this message:
Quote// Mod Authors for a "ADD AFTER" on this line. Ensure you end your change with a comma. For example:
// 'shout' => array($txt['shout']),
// Note the comma!! The setting with automatically appear with the first mod to be added.
Further down we have:
Quote// Mod authors if you want to be "real freaking good" then add any setting pages for your mod BELOW this line!
Now ive been able to add my block of code which gives me the right admin menu change and an icon but isnt there a way for this code to be in my file and just hooked into the admin menu?
Im looking at this because I want to get the full menu and settings standalone so it doesnt get trouble from themes and the likes. Technically isnt there a way to add admin menu items purely on hooks alone? Im not sure how its called if it doesnt actually modify the file to begin if that makes sense.
Quote// Mod authors if you want to be "real freaking good" then add any setting pages for your mod BELOW this line!
Just a few lines below is a hook for that
Quoteintegrate_admin_search
/me thinks we should remove the "Mod authors" reference as we will be forcing the usage of hooks more and more...
That depends if you're planning on encouraging the use of 2.0 mods on 2.1 where they still depend on such things.
This im doing is from the ground up and has no code prior. The menu works fine but ive had to add an array to the admin.php because I dont know how im supposed to place it in my file instead and call it using the hook.
Have we got any 2.1 examples about ?
Considering that there are 2.0 examples of using hooks and have been for years? Nothing 2.1 specific required here.
Quote from: margarett on December 22, 2014, 07:42:32 PM
/me thinks we should remove the "Mod authors" reference as we will be forcing the usage of hooks more and more...
and break tons of mods? Bad idea.
I wasnt sure if there was 2.1 specific changes tbh.
Ive just been reading over some older topics on the subject and it appeared that there was debate over what will and wont work.
Quote from: live627 on December 22, 2014, 07:56:07 PM
Quote from: margarett on December 22, 2014, 07:42:32 PM
/me thinks we should remove the "Mod authors" reference as we will be forcing the usage of hooks more and more...
and break tons of mods? Bad idea.
Agree. In the end that just causes people to leave. As developer I like backwards compatibility is less work to maintain... Why keep rewriting code over again I really dislike it when changes are made for no good reason. Part of the reason why windows was successful is for the most part had a stable api. New companies like facebook like changing their api all the times and results in people less likely to keep going which is part of the reason why SMF doesn't have social logins.
QuoteAs developer I like backwards compatibility is less work to maintain...
Only if actually used properly in the first place.
QuoteWhy keep rewriting code over again I really dislike it when changes are made for no good reason.
The changes were always made with good reason, just because you don't necessarily know or understand the reason does not mean it wasn't a good one.
QuotePart of the reason why windows was successful is for the most part had a stable api
You are clearly joking. WinAPI has had many changes under the hood and more than once did not function as described in MSDN documentation. To the point where compilers include compatibility code specifically for different versions of Windows precisely because the API differs from version to version.
I can take an application written in the 1980s in windows and it sill works today on windows.
No a lot of the changes are made for dumb reasons mainly deprecating functions when there is no real good reason all it does end up breaking code which used to work and now in the end doesn't work and is just a waste of developers time.
QuoteI can take an application written in the 1980s in windows and it sill works today on windows.
Nope, but thanks for playing. Nothing built for Win3.1 or lower will work on current Windows unless built for Win32s since the 16 bit functionality has been phased out.
I also have applications I wrote that followed the API as laid down in Windows 98 that behave differently on more recent versions - and some API functions which didn't behave as per documentation in Win98 but did in XP.
QuoteNo a lot of the changes are made for dumb reasons mainly deprecating functions when there is no real good reason
Like I said, just because you don't know *their* reasons for it does not make them inherently bad reasons.
I suspect you're part of the group that feels EOLing SMF 1.1 is for no good reason, for example, when I can give you a ton of them.
Forgot that 16bit was dead I have not tired in a couple years but I do remember downloading apps on Windows xp that at least that were made in the 1980's that still worked which was awesome. Amazing that you can remember all that even Win32s that was a very small subset.
Honestly yeah SMF 1.1.x shouldn't be EOL it still works and should have at least security updates. if I had my say I would have updated but people didn't like me adding/updating to it at the time... 2.1 is the future just we need to be very careful...each new version lately we loose people it seems either forum owners/modders/themers. We need to do a better job on making people feel welcome otherwise they won't come around....
QuoteAmazing that you can remember all that even Win32s that was a very small subset.
It's been a while since I did the WinAPI coding thing, I stopped in 2001 when I started getting into the web thing but even then the desktop API was starting to really be fragmented; though XP harmonising everything under one kernel (also meaning the whole needing pairs of functions for anything, one for ASCII, one for Unicode, could safely FOAD) would certainly have started to deal with the frustration I was having. Vista chopping the old security model and driver model is another of those 'seems to have been bad' moves but actually wasn't because it is what made 7 that much stronger, even though it might not seem like it.
QuoteHonestly yeah SMF 1.1.x shouldn't be EOL it still works and should have at least security updates.
Even though it is massively impractical to do so since almost every mod will also need some kind of updates?
With PHP 5.5, ext/mysql is being phased out meaning that all the mysql_fetch_assoc calls throughout SMF will need replacing, and putting in something like this is not actually workable in practice:
if (!function_exists('mysql_fetch_assoc'))
{
function mysql_fetch_assoc($resource)
{
return mysqli_fetch_assoc($resource);
}
}(and fixing db_query to return mysqli_result objects instead of classic resources, of course)
As for phasing out ext/mysql, it might sound like it's a bad move because backwards compatibility. Except there are reasons MySQLi was introduced - the whole GPL licensing crap with PHP and MySQL aside, there are features in MySQLi that cannot be introduced into the ext/mysql branch simply because it would have to be ground-up rewritten to do it like supporting unbuffered queries (which for some stuff is fantastic to be able to do). Like I said, just because the reasons are not apparent or well understood does not necessarily follow that the reasons are bad.
It is not possible nor practical to maintain things forever. Sometimes things just have to be replaced. By your logic, all the code in 2.0 that makes it hard to theme should *also* be kept for future versions, despite better alternatives being available.
One cannot make use of new features and new opportunities without removing some of the cruft from time to time.
This is however massively off the original topic :P
Quote from: live627 on December 22, 2014, 07:56:07 PM
Quote from: margarett on December 22, 2014, 07:42:32 PM
/me thinks we should remove the "Mod authors" reference as we will be forcing the usage of hooks more and more...
and break tons of mods? Bad idea.
I actually think so. Most mods will not work in 2.1 except if using hooks already... So if we could help ourselves, it would be nice ;)
Nope... Removing that for 2.1 goes contrary to the plan. :P
What plan? :P
The secret illuminati plan
Ah, that one ;D
I have to be honest while I can see the argument in favour of not breaking back-compat for the sake of it, I'm inclined to be... encouraging... of mod authors looking back over their mods and not doing the least possible work to provide something for 2.1.
Certain people will know *exactly* what I have in mind like doing what looks like find/replace on db_query to get to $smcFunc['db_query'] and not making use of the features in $smcFunc['db_query'] put there for security.
Back-compat is mostly broken already! ...
Whatever theme edits existed, puff, gone
Most changes to Load.php will probably be different. Same for Subs.php
Sooooooo.... ;)
Indeed... but I'm a big fan of encouraging this stuff to be reviewed properly rather than doing the bare minimum ;)
Quote from: margarett on December 22, 2014, 09:39:20 PM
Quote from: live627 on December 22, 2014, 07:56:07 PM
Quote from: margarett on December 22, 2014, 07:42:32 PM
/me thinks we should remove the "Mod authors" reference as we will be forcing the usage of hooks more and more...
and break tons of mods? Bad idea.
I actually think so. Most mods will not work in 2.1 except if using hooks already... So if we could help ourselves, it would be nice ;)
Those lines help curb conflicts, however weak the argument may be.
Here's the thing: if I saw a mass adaption of hooks, I'd be in favor.
Well, we can't do much about already-approved mods but, as long as I have anything to say about new approvals, we will be requiring the use of hooks ;)
If it weren't such a time sink I'd be encouraging old mods to be reviewed again.
yeah... I would as well... but we don't currently have the team to do it. :(
Either that or write new versions of old mods, like galleries ;D
For me, just classify the mods into three category: Fully hook, partially hook and manual mod. Let everybody makes whatever type of mods they want. Let everybody learns. When somebody ask for hook tutorials, nobody really cares. So, why must be so strict or serious about this? What would that benefits anyway? To whom? Enough said with regards of the above. I don't see that being enforced and I personally vote for it not to be enforced. (Yeah, I know. Nobody will care about any votes either.)
people can do whatever they want with mods that they write.
However, going forward, if the mod is to be accepted on our customization site, here, then the authors will be requested to use hooks whenever possible.
If a code edit is needed, because there is no hook to use, then fine... but hooks are to be used whenever possible.
Quote from: Kindred on December 23, 2014, 08:13:38 AM
people can do whatever they want with mods that they write.
However, going forward, if the mod is to be accepted on our customization site, here, then the authors will be requested to use hooks whenever possible.
If a code edit is needed, because there is no hook to use, then fine... but hooks are to be used whenever possible.
True, but you are missing a point that Hook related tutorials are really lacking. So you can't actually expect people to learn things on wild-guesses.
@ahrasis But we still in early stages of release "first beta", I'm sure developers will come with something to help mod authors to upgrade their mods to hook-only (if possible) version and write some guides to teach newcomers how to code with Hook system.
no. I am not missing the point at all...
Someone should WRITE the tutorials -- and what better way to learn what is needed and what can be done that doing it and documenting? :P
Hooks are nice cause removing some file edits.
I have some concerns though on how it scales when every single mod starts using hooks since from my understanding each will add a file in "integrate_pre_include" so that includes more files in memory for each page load.
Some hooks need to be improved some as menu level hooks right now it seems I have to order the array myself in order to insert the exact spot of where I want a menu
Some current things I don't like about the mod site approvals
The mod site is way too strict, never been a big fan.
It just turns off developers for a couple reasons: The mod site is geared for simple mods, very few large scale mods go though the mod site now. Takes months to review a modification unless it is simple that's why you mostly see BBC code mods now. For me personally that's why I rather submit something very basic has a better chance of getting approved then making some that is huge when I know it will take much longer to get approved.
It's better to have a mod then none at all in most cases. Requirements should be does the mod install/uninstall cleanly, works as stated, use smf functions, security checks and that is about it. That's how it was in the past and we had a ton of developers.
The customize team should be either more focused on updating the customize site,maintaining official smf mods/themes and writing tutorials/documents on how to code. Instead of approvals that is boring work and no one likes doing it. I kind of regret giving some mods back to customize team because now they just are not maintained at all.
Another thing you can't easily see what mods you have pending approval not visible in an easy place. only area is latest submissions
Don't get me wrong. I am not against the hook thingy. I am all towards it. Mods under me are mostly set to be upgraded to hook version slowly but surely. Some are even ready for 2.1. I did write and when I am freer, will continue to write tutorial about the mods.
I also read your post about using hook vbgamer. Even a simple css hook for SMF2.1 is being debated when you can either use the context html or css to do it with integrate menu buttons to change menu image. For me it is simple, whatever hook is in there, it can be used.
And I do agree with your above comments and suggestions. The mod site should be simpler.
P/S: I don't simply sit and wait for the biggest delicious cake when plenty of other cookies are just as good and very much available. ;D
I continue to be amazed at the lack of understanding of hooks.
I continue to be amazed that there are no good guides you pretty much have to go by what other people have done and that hooks are not the answer to everything.
yes. the mod site should be ALOT of things... and plans for the mod site redesign have been around almost since the release of 2.0, but we have a limited team who have limited time.. :P
Quote from: vbgamer45 on December 23, 2014, 09:58:53 AM
I continue to be amazed that there are no good guides you pretty much have to go by what other people have done and that hooks are not the answer to everything.
Because http://wiki.simplemachines.org/smf/Integration_hooks is not a thing or anything.
Hooks aren't the answer to everything but more use can be made than people are making. I mean, my gallery is hooks only - and that includes its own gallery-specific pretty URLs. Oh, and making hooks in places where there aren't hooks, *without* file edits.
The problem is, few people care enough to really bother making use of the things available because file edits are easier (and less reliable)
Quote
I have some concerns though on how it scales when every single mod starts using hooks since from my understanding each will add a file in "integrate_pre_include" so that includes more files in memory for each page load.
This is not the case on 2.1. Yes, each mod will add 1 or more files but only when necessary/requested and is up to the mod author to decide how/what to include.
Quote
Some hooks need to be improved some as menu level hooks right now it seems I have to order the array myself in order to insert the exact spot of where I want a menu
The whole point of having a hook somewhere is that you can manipulate the passed var(s), you can manipulate every single var in global scope available at the moment that particular hook is been called and not only that, you can do pretty much anything you want, you have a function/method called exactly at one point in the process, the rest is up to you.
Quote
I continue to be amazed that there are no good guides you pretty much have to go by what other people have done and that hooks are not the answer to everything.
There is no guides mostly because there cannot be any guides on "how to use them", it really is up to you and your understanding of PHP.
True, hooks aren't a panacea but they really, really help.
- Support issues, I get none, the only support requests I answer are feature request or install/uninstall issues.
- Easy to maintain/upgrade. I got my whole code in 1 single file or files, combing that with the most basic level of MVC and you have nothing to worry about.
Yes, not everything can be done with hooks and file edits are still necessary, fine, for that I would strongly suggest to keep your code logic completely separated from SMF, it is somehow difficult to explain.
Quote from: Kindred on December 23, 2014, 10:10:56 AMwe have a limited team who have limited time..
People have reasons when they shy away...
I am using hooks for most things in 2.1 based on what I can understand. I do agree less support requests most of my mods I avoid doing edits as much as possible for this reason.
I think some more hook helper functions need to be added mainly when dealing with arrays been using stuff like this
function articles_menu_buttons(&$menu_buttons)
{
global $txt, $user_info, $context, $modSettings, $scripturl;
#You can use these settings to move the button around or even disable the button and use a sub button
#Main menu button options
#Where the button will be shown on the menu
$button_insert = 'mlist';
#before or after the above
$button_pos = 'before';
#default is before the memberlist
articles_array_insert($menu_buttons, $button_insert,
array(
'articles' => array(
'title' => $txt['smfarticles_menu'],
'href' => $scripturl . '?action=articles',
'show' => allowedTo('view_articles'),
'icon' => '',
)
)
,$button_pos);
}
function articles_array_insert(&$input, $key, $insert, $where = 'before', $strict = false)
{
$position = array_search($key, array_keys($input), $strict);
// Key not found -> insert as last
if ($position === false)
{
$input = array_merge($input, $insert);
return;
}
if ($where === 'after')
$position += 1;
// Insert as first
if ($position === 0)
$input = array_merge($insert, $input);
else
$input = array_merge(
array_slice($input, 0, $position),
$insert,
array_slice($input, $position)
);
}
But that depends on what you need to do, a hook not only can be used to add more buttons, for example, I pretty often use the menu hook to replace existing buttons and on my site I used it to remove the help and some other buttons I don't really need.
To insert a button on x place I often just copy/paste some code from another mod of mine, I know it works so I don't have to worry about it.
As for helper functions, yeah, I'm currently on that path but then again, it all depends on my needs and how I code, the current class I use for my mods is hardly an efficient one or even helpful but it does help me to normalize all my code between mods which in the end allows me to code mods faster and keep em fully maintained.
Yeah I have helper libraries in my code some functions that use over and over again just thinking some probably should be added to SMF itself to make hooks easier. Arrays can be tricky for people to work with.
We wouldn't be able to add support to everything a mod author can do with an array though.
Ok so I made a script to run some hook installs but when I run it the hook function page in admin dies and will not show hooks. I remove a hook and the page reappears. Its not simply telling me the hooks broken it cant access the page. It defaults back to 'Routine' until the hook is removed then can access the hooks page again.
I may have a dodgy hook but is it normal for the page to be inaccessable if it doesnt like the hook applied? I thought it would just show the hooks but flag anything it knows is wrong.
That shows some code are broken and needs fixing. If you are using subs.yourmod.php, simply open it, fix the code and save. No need install and uninstall during testing. Install only once. Unless you are trying another integrate hook. Then, you may need to reinstall. If you are not sure, the trick is, put several hook until you decide which one you want to really use or which one is really working. Well, at least that is how I do it.
I tried to add two. One works and shows a function name and the file path but the second one trying to call the function is where it goes wrong. Im not sure if what im doing is right. I have a sub menu and associated arrays contained in my subs file. Does the menu function need to be in a seperate file or can I contain all the information as functions within one file?
I didnt write any hook based mods for 2.0 so have been playing catchup tbh so I am sorry if im missing something, the guides are all as old as noahs ark. ;)
PS The hook says its active that works.
instead of us guessing what you may be doing. can you post the code so that someone that understands can help you with the exact example you are using?
Night09 check out SMF Gallery or SMF Articles I have updated them to use hooks for 2.1
Quote from: Illori on December 24, 2014, 09:14:22 AM
instead of us guessing what you may be doing. can you post the code so that someone that understands can help you with the exact example you are using?
This is the exact piece of code adding the hooks used last.
<?php
// If SSI.php is in the same place as this file, and SMF isn't defined, this is being run standalone.
if (file_exists(dirname(__FILE__) . '/SSI.php') && !defined('SMF'))
require_once(dirname(__FILE__) . '/SSI.php');
// Hmm... no SSI.php and no SMF?
elseif (!defined('SMF'))
die('<b>Error:</b> Cannot install - please verify you put this in the same place as SMF\'s index.php.');
add_integration_function('integrate_pre_include', '$sourcedir/Subs-Managewowsettings.php');
add_integration_function('integrate_admin_areas', 'Managewowsettings');
?>After applying it the hooks menu fails to show. If I remove one the menu works again.
Quote from: vbgamer45 on December 24, 2014, 10:06:54 AM
Night09 check out SMF Gallery or SMF Articles I have updated them to use hooks for 2.1
Thanks, ive been looking on the mod site for a few working examples. ;)
If you're using that file only in admin, might I suggest using integrate_admin_include instead of integrate_pre_include; no need to load the settings code every single page load.
Anyway, if it's breaking, that's implying it's set up properly at the hook level because the hook won't be called if the function doesn't exist, so presumably it must exist.
The real question: what's Subs-Managewowsettings.php looking like?
Quote from: Arantor on December 24, 2014, 11:09:02 AM
The real question: what's Subs-Managewowsettings.php looking like?
The Subs file is this:
<?php
if (!defined('SMF'))
die('No direct access...');
function Managewowsettings()
{
global $context, $txt;
// Make sure you can be here.
isAllowedTo('admin_forum');
$subActions = array(
'char_settings' => 'char_settings',
'trade_settings' => 'trade_settings',
'achi_settings' => 'achi_settings',
'config_settings' => 'config_settings',
);
// Default the sub-action to 'char_settings'.
$_REQUEST['sa'] = isset($_REQUEST['sa']) && isset($subActions[$_REQUEST['sa']]) ? $_REQUEST['sa'] : 'char_settings';
$context['page_title'] = $txt['wowchar'];
// Tabs for browsing the different Warcraft functions.
$context[$context['admin_menu_name']]['tab_data'] = array(
'title' => $txt['wowchar'],
'help' => $txt['wowchar_help'],
'description' => $txt['wowchar'],
'tabs' => array(
'char_settings' => array(
'description' => $txt['char_settings'],
),
'trade_settings' => array(
'description' => $txt['trade_settings'],
),
'achi_settings' => array(
'description' => $txt['achi_settings'],
),
'config_settings' => array(
'description' => $txt['config_settings'],
),
),
);
// Call the right function for this sub-action.
call_helper($subActions[$_REQUEST['sa']]);
}
function char_settings($return_config = false)
{
global $context, $txt, $sourcedir, $scripturl;
// Here are all the wowcharacter settings.
$config_vars = array(
// Are characters allowed?.
array('check', 'char_active'),
array('int', 'char_maxlevel', 'postinput' => $txt['char_maxlevel'], 'subtext' => $txt['char_maxlevel2']),
'',
// Are all character stats allowed?.
array('check', 'char_race'),
array('check', 'char_level'),
array('check', 'char_guild'),
array('check', 'char_class'),
array('check', 'char_server'),
array('check', 'char_gender'),
'',
// Updating Characters.
array('check', 'char_update'),
array('check', 'char_user_update'),
array('int', 'char_update2', 'postinput' => $txt['char_update2'], 'subtext' => $txt['char_update3']),
);
if ($return_config)
return $config_vars;
// Get the settings template ready.
require_once($sourcedir . '/ManageServer.php');
// Setup the template.
$context['page_title'] = $txt['char_settings'];
$context['sub_template'] = 'show_settings';
// Are we saving them - are we??
if (isset($_GET['save']))
{
checkSession();
call_integration_hook('char_settings');
saveDBSettings($config_vars);
$_SESSION['adm-save'] = true;
redirectexit('action=admin;area=wowchar;sa=char_settings');
}
// Final settings...
$context['post_url'] = $scripturl . '?action=admin;area=wowchar;save;sa=char_settings';
$context['settings_title'] = $txt['char_settings'];
// Prepare the settings...
prepareDBSettingContext($config_vars);
}
function trade_settings($return_config = false)
{
global $context, $txt, $sourcedir, $scripturl;
// Here are all the wowtrade settings.
$config_vars = array(
// Are characters allowed?.
array('check', 'show_trades'),
array('int', 'max_trades', 'postinput' => $txt['max_trades'], 'subtext' => $txt['max_trades']),
'',
// Are all character stats allowed?.
array('check', 'secondary_trades'),
'',
// Updating Characters.
array('check', 'update_trades'),
array('check', 'user_update_trades'),
array('int', 'trade_update', 'postinput' => $txt['trade_update'], 'subtext' => $txt['char_update3']),
);
if ($return_config)
return $config_vars;
// Get the settings template ready.
require_once($sourcedir . '/ManageServer.php');
// Setup the template.
$context['page_title'] = $txt['trade_settings'];
$context['sub_template'] = 'show_settings';
// Are we saving them - are we??
if (isset($_GET['save']))
{
checkSession();
saveDBSettings($config_vars);
$_SESSION['adm-save'] = true;
redirectexit('action=admin;area=wowchar;sa=trade_settings');
}
// Final settings...
$context['post_url'] = $scripturl . '?action=admin;area=wowchar;save;sa=trade_settings';
$context['settings_title'] = $txt['trade_settings'];
// Prepare the settings...
prepareDBSettingContext($config_vars);
}
//achi settings
function achi_settings($return_config = false)
{
global $context, $txt, $sourcedir, $scripturl;
// Here are all the wowcharacter settings.
$config_vars = array(
// Are achhievments allowed?.
array('check', 'show_achi'),
'',
// Are all achievment stats allowed?.
array('check', 'Total_Completed_achi'),
array('check', 'General_achi'),
array('check', 'Quests_achi'),
array('check', 'Exploration_achi'),
array('check', 'Player_vs._Player_achi'),
array('check', 'Dungeons_&_Raids_achi'),
array('check', 'Professions_achi'),
array('check', 'Reputation_achi'),
array('check', 'Scenarios_achi'),
array('check', 'World_Events_achi'),
array('check', 'Pet_Battles_achi'),
array('check', 'Collections_achi'),
array('check', 'Garrisons_achi'),
array('check', 'Legacy_achi'),
array('check', 'Feats_of_Strength_achi'),
'',
// Updating acheivments.
array('check', 'achi_update'),
array('check', 'char_achi_update'),
array('int', 'achi_update2', 'postinput' => $txt['achi_update2'], 'subtext' => $txt['char_update3']),
);
if ($return_config)
return $config_vars;
// Get the settings template ready.
require_once($sourcedir . '/ManageServer.php');
// Setup the template.
$context['page_title'] = $txt['achi_settings'];
$context['sub_template'] = 'show_settings';
// Are we saving them - are we??
if (isset($_GET['save']))
{
checkSession();
saveDBSettings($config_vars);
$_SESSION['adm-save'] = true;
redirectexit('action=admin;area=wowchar;sa=achi_settings');
}
// Final settings...
$context['post_url'] = $scripturl . '?action=admin;area=wowchar;save;sa=achi_settings';
$context['settings_title'] = $txt['achi_settings'];
// Prepare the settings...
prepareDBSettingContext($config_vars);
}
//General settings
function config_settings($return_config = false)
{
global $context, $txt, $sourcedir, $scripturl;
// Here are all the wowcharacter settings.
$config_vars = array(
// Main settings
array('text', 'wowchar_defaultRealmName', '35'),
array('check', 'wowchar_allowCustomRealm'),
array('check', 'wowchar_europeanRealm'),
);
if ($return_config)
return $config_vars;
// Get the settings template ready.
require_once($sourcedir . '/ManageServer.php');
// Setup the template.
$context['page_title'] = $txt['config_settings'];
$context['sub_template'] = 'show_settings';
// Are we saving them - are we??
if (isset($_GET['save']))
{
checkSession();
saveDBSettings($config_vars);
$_SESSION['adm-save'] = true;
redirectexit('action=admin;area=wowchar;sa=config_settings');
}
// Final settings...
$context['post_url'] = $scripturl . '?action=admin;area=wowchar;save;sa=config_settings';
$context['settings_title'] = $txt['config_settings'];
// Prepare the settings...
prepareDBSettingContext($config_vars);
}
?>If I add the menu block directly to the admin template it works ok. The menu block is this:
// Warcraft Modification Settings Menu Array
'wowchar' => array(
'label' => ($txt['wowchar']),
'file' => 'Subs-Managewowsettings.php',
'function' => 'Managewowsettings',
'icon' => 'wowicon',
'subsections' => array(
'char_settings' => array($txt['char_settings']),
'trade_settings' => array($txt['trade_settings']),
'achi_settings' => array($txt['achi_settings']),
'config_settings' => array($txt['config_settings']),
),
), That placed under the modify message gives me full menu function, icon and links to each of the four sections correctly. It goes wrong when I remove the menu section and try to use a hook instead to place it in the admin menu. I get no menu and the hook issues posted above.
Well, the function called directly from the hook is only supposed to deal with changing the menu structure - and NOT any of the other stuff, those should be a separate function... and it's supposed to receive &$admin_areas to modify it.
Should I contain the menu in a seperate file and call to that instead? I dont get how to make it appear in the correct place though.
Ive been going off this http://wiki.simplemachines.org/smf/Integration_hooks#integrate_admin_areas and http://wiki.simplemachines.org/smf/Add_a_custom_action_using_integration_hooks to get the idea so maybe I need to look again.
It's... complicated as to whether it should be a separate file or not.
The way this part must work on some level:
* integrate_admin_include specifies a file that contains a function to extend the menu
* said function accepts the menu array via &$admin_areas (the & indicates 'this function is going to change this variable') and adds to it, indicating another function to be called if the user goes to that section
* this extra function can live in the same file as the menu-changing function if it's small but if it's big or there's a lot of it, it generally should be another file (which you load with the 'file' parameter when extending the menu)
I did something similar in AlternativeMenu Mod. You can take a look on how admin button is added here in its subs file. I reproduce it here:
function AlternativeMenu_Admin(&$admin_areas)
{
global $txt;
// Load the AlternativeMenu language
loadLanguage('AlternativeMenu');
// Add our menu item
$admin_areas['config']['areas']['modsettings']['subsections']['alternativemenu'] = array($txt['AlternativeMenu'],);
}
function AlternativeMenu_Settings(&$subActions)
{
global $txt, $scripturl, $context, $modSettings, $settings;
// Load the AlternativeMenu language
loadLanguage('AlternativeMenu');
// Add AlternativeMenu Settings
$subActions['alternativemenu'] = 'AlternativeMenu';
}
function AlternativeMenu($return_config = false)
{
global $txt, $scripturl, $context, $settings, $sc, $modSettings;
$config_vars = array(
// Mod authors, feel free to modify this alternative menu but don't remove this statement and basic menu!!
array('check', 'alternativemenu'),
'',
array('check', 'altmenu_remove_help'),
array('check', 'altmenu_remove_search'),
array('check', 'altmenu_remove_profile'),
array('check', 'altmenu_remove_pm'),
array('check', 'altmenu_remove_calendar'),
array('check', 'altmenu_remove_mlist'),
array('check', 'altmenu_remove_register'),
'',
array('check', 'altmenu_replace_with_icon'),
);
// Make it even easier to add new settings.
call_integration_hook('integrate_alternative_menu_settings', array(&$config_vars));
if ($return_config)
return $config_vars;
$context['post_url'] = $scripturl . '?action=admin;area=modsettings;save;sa=alternativemenu';
$context['settings_title'] = $txt['altmenu_description'];
// Saving?
if (isset($_GET['save']))
{
checkSession();
$save_vars = $config_vars;
// This line is to help mod authors do a search/add after if you want to add something here. Keyword: FOOT TAPPING SUCKS!
saveDBSettings($save_vars);
// This line is to help mod authors do a search/add after if you want to add something here. Keyword: I LOVE TEA!
redirectexit('action=admin;area=modsettings;sa=alternativemenu');
}
// This line is to help mod authors do a search/add after if you want to add something here. Keyword: RED INK IS FOR TEACHERS AND THOSE WHO LIKE PAIN!
prepareDBSettingContext($config_vars);
}
And for the hook:
'integrate_pre_include' => '$sourcedir/AlternativeMenu.subs.php',
'integrate_menu_buttons' => 'AlternativeMenu_Buttons',
'integrate_admin_areas' => 'AlternativeMenu_Admin',
'integrate_modify_modifications' => 'AlternativeMenu_Settings',
Some globals are actually not needed. This is far from perfect but others can guide you more.
Thanks for the help guys I think I get what is supposed to be happening now. I will do some testing and let you know how it goes. :)
Its a strange thing setting this up I must say. Ive had a few drinks so likely gonna kick myself when I find whats up!
I have an admin menu hooked in and it shows the admin button in the right place but no subsections show. If I name an admin template function the same as in the subsection file it throws an error and says already declared. So if it knows to look there and sees the error why isnt the menu showing? Does the format (subsection code a few posts up)ive used above not work as I figured I should be able to just call the function from the admin file.
How I see it is the admin file shows the menu then the subsections file shows the rest. If the admin menu is hardcoded into the admin template the subsection file works perfectly. Anyway thats where im at for the moment. Ive looked at the other mods files for ideas and dont see any major differences.
What is the exact code you are using?
This code makes the Admin Menu main Menu title appear in the right place. When its clicked though it just gives 'the template cannot be loaded'
<?php
require_once($sourcedir . '/Subs-Managewowsettings.php');
function Managewowsettings_Admin(&$admin_areas)
{
global $txt, $modSettings, $scripturl;
// Load the wow language
loadLanguage('Admin');
// Add our menu item
$admin_areas['config']['areas']['wowchar'] = array($txt['wowchar'],);
}
function Managewowsettings_Settings(&$subActions)
{
global $txt, $scripturl, $context, $modSettings, $settings;
// Load the wow language
loadLanguage('Admin');
// Add wow Settings
$subActions['Managewowsettings'] = 'Managewowsettings';
}
?>
So, what's the require statement actually doing? Surely, the file should be being loaded by the hook and not explicitly at that point?
Additionally your problem is that you don't set it up correctly in any case.
You're declaring config->areas->wowchar (which would manifest itself as action=admin;area=wowchar) but missing all the stuff you actually need for a first level item like Core Features or Modification Settings.
In fact, if I look back to your previous code... what you actually need is:
function Managewowsettings_Admin(&$admin_areas)
{
global $txt, $modSettings, $scripturl;
// Load the wow language
loadLanguage('Admin');
// Add our menu item
$admin_areas['config']['areas']['wowchar'] = array(
'label' => $txt['wowchar'],
'file' => 'Subs-Managewowsettings.php', // this will load the file if not already loaded
'function' => 'Managewowsettings', // this is the function that will be called to carry out the dreaded deed itself
'icon' => 'wowicon',
'subsections' => array(
'char_settings' => array($txt['char_settings']),
'trade_settings' => array($txt['trade_settings']),
'achi_settings' => array($txt['achi_settings']),
'config_settings' => array($txt['config_settings']),
),
),
);
And don't forget, you have several sub actions compared to mine which is just one. So define each of them as well.
Thanks for the code block Arantor, I made a few minor changes and some changes to the main settings template and now have the menu fully working.
Ive got two Hooks to make it work, an integrate_pre_include and an integrate_admin_areas.
I can clean it all up now and reinstall 2.1 fresh and test it all works as intended before moving forward. :)
Quote from: Antes on December 23, 2014, 08:19:56 AM
True, but you are missing a point that Hook related tutorials are really lacking. So you can't actually expect people to learn things on wild-guesses.
Quote from: Arantor on December 23, 2014, 09:49:26 AM
I continue to be amazed at the lack of understanding of hooks.
In the past I had to work things out the hard way just so I would be among the first to release a mod for the new version of SMF. I think I will sit back and wait for the dust to settle this time around.
Quote from: Night09 on December 28, 2014, 07:03:18 PM
Ive got two Hooks to make it work, an integrate_pre_include and an integrate_admin_areas.
I supposed integrate_pre_include would include the file in all page load. If what you need with the file is just an integration with admin mod settings, then integrate_admin_include for the said file would do just fine.
Quote from: ahrasis on December 29, 2014, 11:59:20 AM
Quote from: Night09 on December 28, 2014, 07:03:18 PM
Ive got two Hooks to make it work, an integrate_pre_include and an integrate_admin_areas.
I supposed integrate_pre_include would include the file in all page load. If what you need with the file is just an integration with admin mod settings, then integrate_admin_include for the said file would do just fine.
Ive switched the hook and it does work correctly so will use that instead of the pre to reduce loads. TBH I hadnt thought of using that hook.
*whistle*
Quote from: Arantor on December 24, 2014, 11:09:02 AM
If you're using that file only in admin, might I suggest using integrate_admin_include instead of integrate_pre_include; no need to load the settings code every single page load.
Quote from: Arantor on December 30, 2014, 11:43:01 AM
*whistle*
Quote from: Arantor on December 24, 2014, 11:09:02 AM
If you're using that file only in admin, might I suggest using integrate_admin_include instead of integrate_pre_include; no need to load the settings code every single page load.
Im going to blame it on the 'Glen Moray' the night I got it working. I do hold my hand up though and realise you did tell me that! ;)
It was Christmas, it's all good :)
Just for reference the admin menu code installs into 2.0.9 with no issues.