How to add a new menu item in Sidebar on Manage domain

[Thembi]

would like to add a new menu item on a sidebar menu when a user is managing a domain

below is the side bar i would like to add new child on:

 

 

 

I have tried the following code as an action hook:

 

<?php

use WHMCS\View\Menu\Item as MenuItem;
add_hook('ClientAreaSecondarySidebar', 1, function($secondarySidebar) {
   /** @var \WHMCS\View\Menu\Item $secondarySidebar */
if (!is_null($secondarySidebar->getChild('Manage'))) {
	$secondarySidebar->getChild('Manage')
	->addChild('Mailing List Subscription Prefs')
	->setLabel('Subscription Preferences')
	->setUri('subscriptionprefs.php')
	->setOrder(100);
}


});

 

 

Thank you guys in Advance

[brian!]

it's a primary sidebar and you got it's name wrong - the following should work...

 

<?php

use WHMCS\View\Menu\Item as MenuItem;

add_hook('ClientAreaPrimarySidebar', 1, function (MenuItem $primarySidebar) {

   if (!is_null($primarySidebar->getChild('Domain Details Management'))) {
       $primarySidebar->getChild('Domain Details Management')
       ->addChild('Mailing List Subscription Prefs')
       ->setLabel('Subscription Preferences')
       ->setUri('subscriptionprefs.php')
       ->setOrder(100);
   }
});

[Thembi]

Great stuff Brian works like magic

[yggdrasil]

Very nice Brian. Just take into account there is a problem with this hook approach on WHMCS sidebars. It is harder to add dynamic actions to the menu that change based on users/product conditions since you are adding this in a hook instead of the using the logic in your custom file/template.

 

Example, if a domain is expired or not active, WHMCS will gray out all the options in that particular sidebar menu (Domain Details Management), but your custom option will still be active. Probably something you don't want if this involves something related to a domain that needs to be in an active state and not pending, expired, canceled, other.

[AffordableDomainsCanada]

Very nice Brian. Just take into account there is a problem with this hook approach on WHMCS sidebars. It is harder to add dynamic actions to the menu that change based on users/product conditions since you are adding this in a hook instead of the using the logic in your custom file/template.

 

Example, if a domain is expired or not active, WHMCS will gray out all the options in that particular sidebar menu (Domain Details Management), but your custom option will still be active. Probably something you don't want if this involves something related to a domain that needs to be in an active state and not pending, expired, canceled, other.

 

Had this previous problem, added

panel-default panel-actions view-filter-btns

to some of the code so the color wasnt effecting the sidebars in the hook.

 

- - - Updated - - -

 

would it be a simple fix? like adding

      ->setClass('panel-default panel-actions view-filter-btns');

[bear]

there is a problem with this hook approach on WHMCS sidebars

Honestly that's not the only problem with the menu system in general.

Extremely complicated over all, requiring us to learn the required coding it takes.

 

Frustrating doesn't begin to state it.

[yggdrasil]

Had this previous problem, added

panel-default panel-actions view-filter-btns

to some of the code so the color wasnt effecting the sidebars in the hook.

 

- - - Updated - - -

 

would it be a simple fix? like adding

      ->setClass('panel-default panel-actions view-filter-btns');

 

To the hook? I'm not sure what you are saying but it's not just a color change (grayed out), the options in the menu are actually disabled and not clickable.

 

- - - Updated - - -

 

Honestly that's not the only problem with the menu system in general.

Extremely complicated over all, requiring us to learn the required coding it takes.

 

Frustrating doesn't begin to state it.

 

I'm ok with some coding. I'm a bit annoyed if it's to achieve simple tasks, as it's time-consuming and time equals costs but still at least doable.

 

 

What I'm not ok is having to learn specific tweaks or hacks for a specific system that are not widely used anywhere else. One of the things I dislike about WHMCS is how restrictive it is when it comes to PHP, probably a smarty thing. You need to pull data from here, then convert it back, process it and convert it back...

 

 

A dumb example of this is just simple language tags, which need to be extracted from smarty, passed to the PHP code, and then once executed, passed again to the smarty code to be rendered to the user to display the text. All in the same page !!!

 

 

And if you are going to do it properly, you should only use PHP in hooks and not in templates which is a nightmare regarding execution orders once you have a lot of hooks. I had big developer companies like Modules Garden telling they don't know which order some things are executed and I personally also reported more than one bug to WHMCS because a hook was blocking something in WHMCS or not executing in the proper order. I try to avoid hooks unless they are necessary.

 

 

I would prefer if they stick to just letting us do things in 1 file instead of having to do things in so many different parts or injecting things because we cannot touch encoded files directly. I had to literally hack WHMCS in order to get access to the menu links in the sidebar as they are encoded. You would assume everything displayed to the user side templates is not encoded, but that is not really the same. Some logic is encoded which affects how you render things. I'm ok if they encode server/logic part, but never should be done for rendering or visual stuff.

[bear]

What I'm not ok is having to learn specific tweaks or hacks for a specific system that are not widely used anywhere else.

Pretty much nails it. When I've had to I've learned PHP, mySQLI and PDO, knowing that code language evolves over time. If you don't keep up you have failures and compromises. Got that, no worries. To have to use a hook to call a menu and make changes to it, well, that's silly and cumbersome. There's an addon that behaves like Wordpress to deal with menus, so it's possible without all the extra work on our end...how come they can't implement something like that themselves and end all the frustration?

I would prefer if they stick to just letting us do things in 1 file instead of having to do things in so many different parts or injecting things because we cannot touch encoded files directly. I had to literally hack WHMCS in order to get access to the menu links in the sidebar as they are encoded.

I'd never do that, but totally understand the frustration that leads to it. Extremely off putting, all of it.

[brian!]

Very nice Brian. Just take into account there is a problem with this hook approach on WHMCS sidebars. It is harder to add dynamic actions to the menu that change based on users/product conditions since you are adding this in a hook instead of the using the logic in your custom file/template.

harder, but not impossible... besides in the above hook, I was just fixing the code to work - not coding it for all eventualities!

 

Example, if a domain is expired or not active, WHMCS will gray out all the options in that particular sidebar menu (Domain Details Management), but your custom option will still be active. Probably something you don't want if this involves something related to a domain that needs to be in an active state and not pending, expired, cancelled, other.

then you wrap the sidebar creation in an if statement that checks the domain status and reacts accordingly.

 

Honestly that's not the only problem with the menu system in general.

Extremely complicated over all, requiring us to learn the required coding it takes.

Frustrating doesn't begin to state it.

there were always 3 fundamental problems with the menu system...

 

1. it should have been launched with a menu manager built into the admin area - it's criminal that it wasn't and users (who may not be coders) should be expected to learn (or buy addons) to modify menus/sidebars.

2. the documentation was, and still is, shockingly poor - for a commercial product, the documentation should both cover the basics and detailed examples too... with an explanation of every option.... much like the class docs does (in a limited way)... at least the menu code isn't written by WHMCS (like a lot of WHMCS), it's a third-party product, so there is limited documentation elsewhere.... and don't get me started on the v6 documentation disappearing!

3. the code for existing navbar/sidebar/panels should be publicly visible/available... seriously, if you want to change one minor thing, why should it be easier (almost necessary) to recreate the hook from scratch... usually by trying to reverse engineer the output into code... ridiculous.

 

I dread to think how much support time has been wasted by this nonsense over the last 2 years.

 

What I'm not ok is having to learn specific tweaks or hacks for a specific system that are not widely used anywhere else. One of the things I dislike about WHMCS is how restrictive it is when it comes to PHP, probably a smarty thing. You need to pull data from here, then convert it back, process it and convert it back...

I doubt it's to do with Smarty... though I won't have a bad word said against Smarty - it was one of the first things I completely understood when I first started using WHMCS.

 

A dumb example of this is just simple language tags, which need to be extracted from smarty, passed to the PHP code, and then once executed, passed again to the smarty code to be rendered to the user to display the text. All in the same page !!!

i'd like to see an example of that, because your explanation of that process sounds bizarre.

 

And if you are going to do it properly, you should only use PHP in hooks and not in templates which is a nightmare regarding execution orders once you have a lot of hooks. I had big developer companies like Modules Garden telling they don't know which order some things are executed and I personally also reported more than one bug to WHMCS because a hook was blocking something in WHMCS or not executing in the proper order.

again, that comes down to poor documentation - I wish WHMCS would understand that if you made the documentation better, you'd generate more developers - and that can only be good for the product.

 

I would prefer if they stick to just letting us do things in 1 file instead of having to do things in so many different parts or injecting things because we cannot touch encoded files directly. I had to literally hack WHMCS in order to get access to the menu links in the sidebar as they are encoded. You would assume everything displayed to the user side templates is not encoded, but that is not really the same. Some logic is encoded which affects how you render things. I'm ok if they encode server/logic part, but never should be done for rendering or visual stuff.

the logic of the encoding, from what I was told by someone @ WHMCS, was to (among other reasons) prevent users from editing core functions and causing bugs... which has some merit, but I don't see the need to hide the code used to generate existing naviagtion output... it's a complete pain.

[yggdrasil]

harder, but not impossible... besides in the above hook, I was just fixing the code to work - not coding it for all eventualities!

 

 

Of course, I understand, the thing is that eventually, the person will realize all those kinds of small things, that is what I pointed out that all other menu options will be disabled on an expired domain except your custom hook which not only will look bad and unprofessional but also probably not what the user wants (letting him click that option on a disabled domain).

then you wrap the sidebar creation in an if statement that checks the domain status and reacts accordingly.

 

 

 

You mean the hook file/code you posted?

 

there were always 3 fundamental problems with the menu system...

 

1. it should have been launched with a menu manager built into the admin area - it's criminal that it wasn't and users (who may not be coders) should be expected to learn (or buy addons) to modify menus/sidebars.

2. the documentation was, and still is, shockingly poor - for a commercial product, the documentation should both cover the basics and detailed examples too... with an explanation of every option.... much like the class docs does (in a limited way)... at least the menu code isn't written by WHMCS (like a lot of WHMCS), it's a third-party product, so there is limited documentation elsewhere.... and don't get me started on the v6 documentation disappearing!

3. the code for existing navbar/sidebar/panels should be publicly visible/available... seriously, if you want to change one minor thing, why should it be easier (almost necessary) to recreate the hook from scratch... usually by trying to reverse engineer the output into code... ridiculous.

 

I dread to think how much support time has been wasted by this nonsense over the last 2 years

 

 

Well, sure I agree on that. I can't account the time I wasted this year trying to do to things on the menu that would take me exactly 1 hour in HTML, and it took me days with WHMCS as I had to figure out how to properly do it with a hook code. While I understand this approach is excellent for developers and modules, you can install a module without having to do edit template files to insert the new options, I don't understand why they didn't use both approaches. Let users still edit directly the menu's code like in older WHMCS versions but also let them do them with hooks. If they give users both options, you can modify them directly or use a hook if you want and you have the best of both worlds.

 

 

Right now, they encoded them and you can only tap on some of them with hooks (sidebars, etc.). I consider this a downgrade vs v5 where the code was also in the template files. Some things are tough and messy to do with a hook and were incredibly dumb easy by just having access to the code directly. This is not only true for menu's, there are other things encoded that are output to the client area like modules that you can't even edit the text or insert something in between if you want.

 

i'd like to see an example of that, because your explanation of that process sounds bizarre.

 

 

Sure. Some of this is even based on your own suggestions.

 

 

Example:

 

 

You need to manipulate some logic with PHP (not smarty) in a template. Before you say that PHP should never go into a template, I agree but I was not able to have the same result in a hook because the code is displayed based on the execution order in the same and a hook is executed once as far as I know.

 

 

What do I mean? That the page code changes output depending on what you did on the page, like sending a POST to the same page or similar. Those things I'm not sure you can do with a hook which is only executed once, because the user is sending data to the same template file and it changes based on that. Assuming you need to use it in different languages, it means you need to tap into the WHMCS language file.

 

 

So, in your PHP code to access smarty variables (you could tap into the DB but lets make it simple)

 

 

# Get smarty vars
$myphpvar = $smartyvars['LANG']['customstring'];

 

 

Now you can use the variable data inside your PHP code. This can be anything, user logged, product info, but in that example its just locale text. Since you cannot use smarty inside PHP directly, you need to get data this way in order to display a message or similar with PHP echo to the user side.

 

 

Then based on what you do, you probably need to convert some PHP vars back to smarty:

Probably your code results or similar that needs to be output to the user.

# Convert vars to smarty
$template->assign('var', $phpvar);

 

 

Now, in the template, you can output the result with smarty:

 

{$phpvar}

 

See what I did? You need to get smarty vars, turn them into PHP, then you need to turn them back to smarty.

 

 

the logic of the encoding, from what I was told by someone @ WHMCS, was to (among other reasons) prevent users from editing core functions and causing bugs... which has some merit, but I don't see the need to hide the code used to generate existing naviagtion output... it's a complete pain.

 

 

I'm not sure if it has some merit. A hook is more likely to crash your WHMCS installation completely. If there is something wrong with the hook code, WHMCS will not load anymore, or you are welcomed with a blank page. If you made a mistake in the HTML code in a template, at least it would still work partially. A newbie user will surely not touch code, and if he has to do so, it is more likely he knows basic HTML or some PHP and the hook would be harder to learn. I also agree that this has probably caused them terrible amount of support tickets which leads to increased WHMCS costs. I do think the WHMCS documentation is decent, but I wish they had more ready made examples when it comes to hooking and other things.

[brian!]

Of course, I understand, the thing is that eventually, the person will realize all those kinds of small things, that is what I pointed out that all other menu options will be disabled on an expired domain except your custom hook which not only will look bad and unprofessional but also probably not what the user wants (letting him click that option on a disabled domain).

who knows what the user wants... I usually work on the principle of them telling me - if I have to second guess, then that's wasting everyones time.

besides in the above example, even with a cancelled domain, the overview link will still be active - so you can't necessarily assume that he would want an inactive link.

 

You mean the hook file/code you posted?

yes - off the top of my head I can think of half a dozen ways to do it with an action hook - and maybe a couple to do it 100% using Smarty in the template without any PHP code or hook... but i'll give you a simple hook-based method that uses a value that will already exist in Smarty... if the domain status is anything other than"Active", the link will be disabled.

<?php

use WHMCS\View\Menu\Item as MenuItem;

add_hook('ClientAreaPrimarySidebar', 1, function (MenuItem $primarySidebar) {

   GLOBAL $smarty;
   $status = $smarty->getVariable('status');

   if ($status != "Active") { $setclass = "disabled"; }

   if (!is_null($primarySidebar->getChild('Domain Details Management'))) {
       $primarySidebar->getChild('Domain Details Management')
       ->addChild('Mailing List Subscription Prefs')
       ->setLabel('Subscription Preferences')
       ->setUri('subscriptionprefs.php')
       ->setClass($setclass)
       ->setOrder(100);
   }
});

 

if the "status" value didn't already exist in Smarty, then you could easily find it's value through the class docs, querying the database etc.

 

Right now, they encoded them and you can only tap on some of them with hooks (sidebars, etc.). I consider this a downgrade vs v5 where the code was also in the template files. Some things are tough and messy to do with a hook and were incredibly dumb easy by just having access to the code directly.

I wouldn't argue with that - they were easier... which is why the (lack of) documentation is of more importance with these menus... when you can see the code, the documentation is less relevant... when you've got encrypted code, few practical examples and useless documentation, then you're up the proverbial creek.

 

Sure. Some of this is even based on your own suggestions.

well there's your biggest mistake!

 

See what I did? You need to get smarty vars, turn them into PHP, then you need to turn them back to smarty.

all I will say is that, in 4+ years of using WHMCS, i've never had to (or felt the need) to do that (use Smarty in and out of PHP the way you seem to)... nor can I remember any poster asking about it.

 

I'm not sure if it has some merit. A hook is more likely to crash your WHMCS installation completely. If there is something wrong with the hook code, WHMCS will not load anymore, or you are welcomed with a blank page. If you made a mistake in the HTML code in a template, at least it would still work partially. A newbie user will surely not touch code, and if he has to do so, it is more likely he knows basic HTML or some PHP and the hook would be harder to learn. I also agree that this has probably caused them terrible amount of support tickets which leads to increased WHMCS costs. I do think the WHMCS documentation is decent, but I wish they had more ready made examples when it comes to hooking and other things.

even if they aren't used by the code, i'd have put the sidebar/navbar hooks in a subfolder of 'hooks' - if only so we can see how they're generated... instead, they're probably all created inside clientarea.php - and that has subsequently doubled in size from v5 to v7.

 

surely there are zero security implications in knowing that code, yet they protect it like it's some sort of genius programming - I daresay you could learn all sorts of tricks/methods with a decrypted version of clientarea.php, but i'm not going to download one - nor am I willing to pay WHMCS for one either.

[yggdrasil]

all I will say is that, in 4+ years of using WHMCS, i've never had to (or felt the need) to do that (use Smarty in and out of PHP the way you seem to)... nor can I remember any poster asking about it.

 

Because most people probably stick with one single language only. This is why you don't see other people complaining that tags in KB articles are not multi language, or payment gateways can't be translated, or that security questions are not multi language either. While you can do that with hacking the code, by default its missing yet in years, WHMCS does not bother to fix that. The reason you don't see someone doing what I posted is because most people (even reputable developers) hard code output text into their PHP code or templates since It's the most simple solution. Most modules/code don't even take into account anything else besides English, this is why some modules are not even multi language either (more simple).

 

 

If you are using PHP, and you need to output messages, like error or status to the user, how else would you do that if not tapping into the smarty variables to the proper language vars?

 

 

If you are correctly using the language file from WHMCS and you are coding for users in more than language, you need to get the variables from the language files. If you hard code the text into PHP, then you would need to add extra logic to detect the user language and output based on that. I prefer to put the text correctly into the correct language files that WHMCS uses. That means you have to do it that way. While maybe there are other ways, I found that to be the cleanest one.

[brian!]

If you are using PHP, and you need to output messages, like error or status to the user, how else would you do that if not tapping into the smarty variables to the proper language vars?

there are ways.

 

If you are correctly using the language file from WHMCS and you are coding for users in more than language, you need to get the variables from the language files. If you hard code the text into PHP, then you would need to add extra logic to detect the user language and output based on that. I prefer to put the text correctly into the correct language files that WHMCS uses. That means you have to do it that way. While maybe there are other ways, I found that to be the cleanest one.

well i've been involved in enough of your thread replies to leave you to it.

[ptomter]

Hi @brian!

Can you please advice on following (as this is an old post) but same topic regarding this.

 Show item in menu only if domainstatus = active and domain .tld is com