Where are the HomePanels?

[yggdrasil]

For the sake of me I cannot find where the templates or code is for the {outputHomePanels} which are displayed in the customer home page or template file clientareahome.tpl

Where is this? This is the front end home are for customers after they log in.

[brian!]

the code is in clientareahome.tpl and is basically ~line 73 onwards...

<div class="client-home-panels">

 

[yggdrasil]

19 minutes ago, brian! said:

the code is in clientareahome.tpl and is basically ~line 73 onwards...

<div class="client-home-panels">

 

That is the code? Ok so where is then getExtra items or hasBadge, HasIcon, getLabel, getBodyHtml? From where is it getting the information to output the data? The database?

I need to edit the HTML output.

Edited August 23, 2018 by yggdrasil

[brian!]

9 hours ago, yggdrasil said:

That is the code?

as I told you in another thread, the menus, sidebar and panel contents are just arrays... and that's the code that loops through the array and outputs them as 2 columns.

9 hours ago, yggdrasil said:

Ok so where is then getExtra items or hasBadge, HasIcon, getLabel?

they're just tags you can use in the templates to determine certain things about the arrays.

https://docs.whmcs.com/classes/7.6/WHMCS/View/Menu/Item.html

9 hours ago, yggdrasil said:

From where is it getting the information to output the data?

from the arrays... and to answer your subliminal question - yes, those arrays are created within the encoded files.

9 hours ago, yggdrasil said:

The database?

you can query the db to get info to be used as content, but there isn't a specific table that is used for these panels... e.g there's no panel table in the database.

[yggdrasil]

So those classes are also encoded?

https://docs.whmcs.com/classes/7.6/WHMCS/View/Menu/Item.html

I need to change the colors and as well links that comes out for the news articles.

Edited August 23, 2018 by yggdrasil

[brian!]

2 minutes ago, yggdrasil said:

So those classes are also encoded?

off-hand, I don't know... actually, i've never thought about it.... I wouldn't rule out them being somewhere in vendor, but no idea if they're encoded.... nor frankly, would I care if they were.

[brian!]

39 minutes ago, yggdrasil said:

I need to change the colors

of the panels? that's a simple hook that i've probably posted previously many times before...

40 minutes ago, yggdrasil said:

as well links that comes out for the news articles

you could use a tweaked version of the hook below - it all depends on how you want to change those URLs...

 

[yggdrasil]

Another PHP hook to generate static HTML. Great 🤮. I guess I will end up with 300 hooks with WHMCS version 10. Assuming a website even works at that point since hooks are not catched as opposed to smarty templates. I guess websites using WHMCS will be just a nightmare to browse in the future. Slow, slow, slow. That is the new WHMCS motto. Make things harder, complicated and horrible slow.

I think I will just do a completely new front end. No hooks, no smarty, no theme, no templates and the best, no WHMCS. It will talk directly to the database and I will not have to deal with this anymore. I'm moderately happy with the back end (since I don't change that) so I guess I will keep it. The front end modifications are a nightmare now, it started with v6 and is getting worse. I want seriously someone to test a website using WHMCS with 100 hooks that change different things and tell me how that works for them....!!! Because this is where its moving...

Edited August 24, 2018 by yggdrasil

[brian!]

10 hours ago, yggdrasil said:

So those classes are also encoded?

curiosity got the better of me - they're not encoded.... actually, there are some functions listed there that aren't in the docs...

10 hours ago, yggdrasil said:

I need to change the colors.

run for your life - it's another hook... 😱

<?php

use WHMCS\View\Menu\Item;

add_hook('ClientAreaHomepagePanels', 1, function (Item $homePagePanels)
{
	if (!is_null($homePagePanels->getChild('Domains Expiring Soon'))) {
				$homePagePanels->getChild('Domains Expiring Soon')
				->setExtra('color','purple');
	}
});

8 hours ago, yggdrasil said:

Another PHP hook to generate static HTML. Great

no it's another hook to manipulate an array before it gets outputted by the template.

8 hours ago, yggdrasil said:

I guess I will end up with 300 hooks with WHMCS version 10.

will any of us still be here by v10 ?

properly organised (e.g consolidated) it's only 5 hooks (2 for the sidebars, 2 for the navbars and 1 for the panels) - now if you're making extensive changes, they'll be large files but you could code each change to run only when required.

8 hours ago, yggdrasil said:

I think I will just do a completely new front end.

in terms of the panels, you could hardcode them in the clientareahome.tpl template if you wanted to - that's just HTML and Smarty... a series of if statements checking various clientsdetails/stats values (because you know they'll be logged in) and then adding panels based on those values - the colors, FA5 icons could all be coded in the template without the use of any array... if that's the road you want to go down, it's perfectly doable... similarly for the navbars... though possibly recreating the existing sidebars in a template could be a coding nightmare - not least because a lot of them are conditional... and of course, those conditions are in encoded files so you end up having to guess what the conditions being applied are based on the output.

8 hours ago, yggdrasil said:

horrible slow.

if it starts getting as slow as this community site, then we're in trouble - this is truly one of the slowest sites I visit... it's a metaphor for WHMCS as a whole.

10 hours ago, yggdrasil said:

I need to edit the HTML output.

no - you *want* to edit the html. 😀

as i've said previously, you could edit that template with Smarty and code it to change the color of a specific panel... though I fear showing you how would open a pandora's box of subsequent questions!

but that's not really worth it - if you want to avoid hooks, just hardcode the panels in the template.

[yggdrasil]

But this is just bad design. Very bad actually. What is the first thing heavy traffic sites do? Example WordPress? Make a static HTML cache for all PHP files. Why? Well, because its impressive how efficient a web server like Apache is serving static content. Example, a server that serves 1000 Visitors a day with only PHP can serve without issues the same page to 100,000 a day without sweating and I’m not kidding here. There is a reason why static CMS are also so popular now, performance and security. No load balancers required (by the way WHMCS does not work behind those either....)

Sure, WHMCS is a dynamic site, it uses PHP and MySQL but there is a reason why Smarty has a cache. Hooks? No, hooks can’t have a cache, I can’t see how they would because then they would fail to trigger on some actions or would trigger the same action for a different visitor. So now you are requesting PHP code calculations on every single hit. I cannot start to mention how horrible this is for any website. I mean seriously, I don’t want to put a 128 GB RAM server with Varnish just to serve WHMCS. Is someone at WHMCS even taking into account this stuff? Hooks are absolutely not scalable. And this is not how hooks are used with other software companies.

Let me put it like this. If you need to run a hook after an account registration or a new domain order, that is different than having to run a hook for every single bot, visitors or hit on your FAQ article or news page. If you are lucky enough to have performance problems by running hooks while doing customer account creations or orders, well congrats, you are selling like pancake and scaling your hardware should not be an issue but it’s a different story if WHMCS is forcing us to create hooks to change the CSS colors or links on public websites. This is absolutely not acceptable. I was already pissed with the sidebar menu’s they moved to hooks on v6 since those are also loaded everywhere. Now it seems WHMCS is going to move everything to hooks. What makes you think Smarty will stay? I have the serious suspicious they are getting rid of Smarty all together, not sure what they plan to do but the design of WHMCS front end speaks of bad quality now. They can't even upgrade bootstrap 4 which I did without issues in 2 hours and they release it broken to their customers. I'm one guy, WHMCS has several people working there and they can't even do simple stuff right.

I know they moved to Laravel and someone at WHMCS know understands how to use classes, but they are using them incorrectly, very incorrectly I might say. Everything is very sloppy coded. The front end site should be able to use a cache system, this is exactly what smarty is doing now, (or was…). While Smarty does not cache everything it makes a good job at reducing some calls and load. I love PHP but nobody on their right mind runs a website directly from PHP output. PHP calculations should be used for the server side thinking and tasks, not generating HTML. Nobody, not even people running WordPress run them without a cache, or Joomla or Drupal. Its all static HTML output. How exactly does WHMCS expect this to work in the future with hooks? Generate a server side load request on every single hit? Good luck getting massive traffic or worse, a DOS attack.

Its doable to create things this way? Of course. But nobody should be doing their websites like this. About the community. Well, I guess for WHMCS its acceptable to have a site that takes over 10 seconds to load. For me, its pathetic and I don't think anyone is going to buy my services if they experience how such a slow site. My WHMCS is not that slow of course, but its slowly getting there. Its getting slower and slower and I know this for a fact because I monitor the loading time every 5 minutes, since v5 it has drastically doubled on load time, and that was 2 years back. Its not getting better. WHMCS is dropping the ball now. The software is huge, bloated and slow. I can't believe I miss WHMCS 5.

I don't see any solution at this point than not using WHMCS as front end anymore. It's a one time job to create everything, but once done, I don't have to deal with their code upgrades or template changes. I'm free to use what ever I want. And I can talk directly to the database with PHP or using the API. Then, I wonder how much I actually will need the back end in the future, since if I'm running my own front end, that means 50% of what WHMCS does is gone. At that point its just another step to create a back end that talks directly to the database and get rid of WHMCS completely since the database is my property and I can talk to it with what ever platform I want. WHMCS is making my job harder, not easier. If someone like me is seriously considering making a complete new front end for WHMCS instead of using the tools the company is providing, that means there is something seriously wrong with WHMCS as a solution. I paid to avoid having to develop everything on my own, now it seems they are pushing me into that path anyway. They are basically forcing me to stop using WHMCS as front end (I'm still strangely happy with the admin side...).

Edited August 24, 2018 by yggdrasil

[brian!]

6 minutes ago, yggdrasil said:

What makes you think Smarty will stay?

as I may have mentioned in another thread - i'm apathetic on a lot of things to do with WHMCS... if they get rid of Smarty, then so be it... if the replacement is better, then there isn't a problem... if it's worse and there's no worthwhile documentation, then i'll leave them to it... though I can't believe they'd add BS4 and replace Smarty in v8 - the beta would have to be at least 6 months long.

9 minutes ago, yggdrasil said:

They can't even upgrade bootstrap 4 which I did without issues in 2 hours and they release it broken to their customers. I'm one guy, WHMCS has several people working there and they can't even do simple stuff right.

you mean FA5 - oh that was/is an ongoing shambles.

15 minutes ago, yggdrasil said:

The software is huge, bloated and slow.

I said that myself in a PM to a certain staff member at WHMCS... he deleted the conversation from his side... one of my proudest moments of the year to have offended him that much. 🤣

19 minutes ago, yggdrasil said:

I can't believe I miss WHMCS 5.

I still use a v5 installation for certain administration issues (no public/client access to it)... it's as ugly as hell to look at - but it does what it says on the tin, I trust it to work as intended and it's faster.

[bear]

Here I was coming here to see about the speed issue, since I'm getting into the conversion from an older version, only to find out that my high quality SSD powered VPS for this won't help and I'm stuck with the loooooong delays between pages. My site pages load in roughly 0.2 ms. WHMCS (admin side) pages take 10 or more seconds, some of them. This won't do.  At least the client side pages are a bit faster, though that's with empty data sets at this point.

Sheesh. 

[yggdrasil]

11 hours ago, bear said:

Here I was coming here to see about the speed issue, since I'm getting into the conversion from an older version, only to find out that my high quality SSD powered VPS for this won't help and I'm stuck with the loooooong delays between pages. My site pages load in roughly 0.2 ms. WHMCS (admin side) pages take 10 or more seconds, some of them. This won't do.  At least the client side pages are a bit faster, though that's with empty data sets at this point.

Sheesh. 

Sadly no, it will not help. In my experience, almost all softwares done with Laravel are painfully slow. I don't know why, if its because of the framework or developers not knowing how it works and abusing the class system. On the opposite, projects done with CodeIgniter are terrible fast. For me this shows that sometimes the latest trend in software is not necessarily always the best even when everyone suggest it. The same is true for PHP which everyone hates now, Python and Go seem to be the new fashion trends, or Git over Subversion. The problem is when developers just follow a trend because it's the new stuff, if we want to go that route pure PHP is always the best in the end. This is why I like frameworks that are light and don't get in the way.

About WHMCS, the new framework seems to allow them faster development but with that comes the cons, more bloated software and slowness. I think WHMCS did this to avoid introducing security issues on their code as now they rely on the framework to protect them which probably sanitizes all calls, SQL, etc.

As for the customer side, I will never stop saying this. You should not be building the front end with PHP hooks. This is PHP that gets call on every server hit, and while you can upgrade RAM, CPU is limited on servers. The worse of all is that WHMCS does not work in a distributed setup. It would if you could access the code and change some stuff related sessions to make them sticky, I think someone else posted this before about problems with WHMCS under a load balancer. If someone does not know what that means so far, its means you are royalty screwed if you expect to have massive traffic or grow your business in a future.

Under any other site this would not be a problem. A million visitors? Sure, cache. Like I said, Apache or any web server is extremely efficient. I saw customers getting on the first Google result under a Doodle day on a shared hosting getting dozens of thousands of unique visitors in a few hours without issues because it was just HTML. PHP + MySQL are a completely different story (or any server side code). This where the problems start. PHP in particular will tax your CPU. This is why it absolutely must cache code and even try to create HTML cache files for the most loaded pages. This is what Smarty tries to do. Once you remove that, and start to use only hooks, you are hitting direct PHP  calculations on the CPU for every page load, (since we need the hook on each load), RAM will only get you far for some PHP code which are not hooks since they need to be triggered on every page request. And since you cannot scale WHMCS on different servers, that means you are limited by the CPU sockets of the server. Even if you get the best hardware on the market, trust me, you are not going to get very fast once you need to call 100 hooks per visitor. This is just a nightmare, no front end using WHMCS can receive decent web traffic this way. Unless you plan to completely stop using the FAQ section and Announcement section and just use WHMCS for the order and customer side. I'm not sure how WHMCS plans customers to do this with abusing hooks. Processing PHP code for menus, side bars, and HTML elements is the worst implementation of a public website ever. On the admin side you can absolutely sustain this because its only the staff accessing (unless you are huge company and that point you would not be using WHMCS....). On the public site? It's the world, you have no control over the hits received on the front end.

What is more surprising is that you can say, but hooks are dynamic...Of course they are, but not everything is dynamic that WHMCS wants us to change with hooks now !!! Example, the sidebars on the customer side change, based on the product activated, or add-on, for example if a domain is expired, they are disabled. But the menus never change on the front end so there is no need to generate them with dynamic code. The homepanels I asked here? Again, they don't change, the individual data items they pull comes from the database. I seriously want to know how is changing the colors or items on a menu for different visitors on every load page or using hooks to create links. Nobody does this, its a coding aberration. More in a world where static CMS's are getting very popular again exactly for the reason they scale and are secure and WHMCS does the opposite.... Most things WHMCS wants us to use hooks today, are static things that rarely are modified. I can bet most people create a hook and never change it again, but those hooks are now executed every single time you load the page. That tells you that code should not be a hook, it should be hard coded. Can you imagine 20 hooks on a page and someone hitting reload over and over again? Well there you have it.

And none of this is making WHMCS better. Its making it also harder for customers. Look all the topics here from people that ask how to change things. Those questions did not existed with older versions.

What will happen the day Brian stops replying and helping those people with hook changes here? They will get angry and stop using WHMCS or open a support ticket just to receive a reply that WHMCS support does not assist with code changes, probably giving them a link to the docs which is alien language for those people. Those customers are not developers, so WHMCS is screwing them by forcing  them to change HTML with hooks. Forcing web designers to be web developers to change looks is not user friendly.

Edited August 25, 2018 by yggdrasil
typos

[bear]

50 minutes ago, yggdrasil said:

What will happen the day Brian stops replying and helping those people with hook changes here? They will get angry and stop using WHMCS or open a support ticket just to receive a reply that WHMCS support does not assist with code changes, probably giving them a link to the docs which is alien language for those people. Those customers are not developers, so WHMCS is screwing them by forcing  them to change HTML with hooks. Forcing web designers to be web developers to change looks is not user friendly.

Exactly right. The few people here that understand this and give freely of their time (especially Brian!) are what's keeping this new way of doing things from imploding. Have to wonder if that's the intent, to create a need for custom coding they can then charge for? 

I can deal, grudgingly, with the need to go to these great lengths to customize WHMCS, but the slowness is untenable. With Google rewarding for quick loading and punishing for the opposite we can't afford this. I've had it complain when a page took over a second to render; having one take 10 isn't going to fly. Menu links, colors, and so on needs to be an edit to files, and the "should it display" logic something that can be controlled via settings. the overhead that's being added with each change is getting out of hand. 

[yggdrasil]

1 hour ago, bear said:

Exactly right. The few people here that understand this and give freely of their time (especially Brian!) are what's keeping this new way of doing things from imploding. Have to wonder if that's the intent, to create a need for custom coding they can then charge for? 

I can deal, grudgingly, with the need to go to these great lengths to customize WHMCS, but the slowness is untenable. With Google rewarding for quick loading and punishing for the opposite we can't afford this. I've had it complain when a page took over a second to render; having one take 10 isn't going to fly. Menu links, colors, and so on needs to be an edit to files, and the "should it display" logic something that can be controlled via settings. the overhead that's being added with each change is getting out of hand. 

There is that one. Google does indeed punish slow pages, that means less visitors, and less customers. Now that you mentioned that, I saw a huge reduction from Google visitors to the FAQ articles. Google is not giving me even half of the visitors they did on v5. Same articles & content by the way. And as I mentioned before, I monitor page load and there is a drastic speed reduction over v5 to v7.

I'm not sure about the charge for coding since if I remember correctly, WHMCS does not offer coding services. The devil inside me tells me this is WHMCS strategy to be more reliant on their way of doing things and a way to lock in customers to their software. What they are achieving is the opposite. And this is not going to end well. There is no reasonable approach to software in which this can work in the future. When on other forums and social media, even WHMCS customers suggest new people that look for a new venture/business against using WHMCS that speaks very badly about the software. Every new WHMCS version is worse than the previous ones. You get some new features, of course, but you lose more. It seems v4 was the most popular version they had. The only con was security holes. They fixed the security problems starting with v5 but with v6 they decided to take WHMCS into a new direction, v7 is probably the worse WHMCS release so far. So many problems... 😫

Edited August 25, 2018 by yggdrasil

[brian!]

3 hours ago, yggdrasil said:

What will happen the day Brian stops replying and helping those people with hook changes here?

there would be others to fill the gap... they may charge the end-user, but nature abhors a vacuum and so something will fill the space... I can remember when I first started coming here, Sparky and others used to post a lot of code and I learnt a lot from that... I hope others are paying attention to the code i'm posting and it inspires them in the future to share.

2 hours ago, bear said:

They will get angry and stop using WHMCS or open a support ticket just to receive a reply that WHMCS support does not assist with code changes, probably giving them a link to the docs which is alien language for those people.

in fairness, I think support would give code for the most basic of navigation hooks, e.g removing/adding children, changing colours etc... though having seen some examples of it, they're often not 100% working correctly.

3 hours ago, bear said:

Those customers are not developers, so WHMCS is screwing them by forcing  them to change HTML with hooks. Forcing web designers to be web developers to change looks is not user friendly.

as i've said many times before, the other serious crime when they launched v6, was to not have an in-built menu editor... the amount of support time that must have been spent answering questions on navigation hooks must have been insane - it was bad enough here... it's the lack of internal coherent thinking that drove (i've given up worrying about it now) me nuts above WHMCS.

and yes, the idea of needing code to modify a menu/color is crazy... i've got used to doing it now, but that doesn't make it right.

5 hours ago, bear said:

The few people here that understand this and give freely of their time (especially Brian!) are what's keeping this new way of doing things from imploding.

don't tell me that - if I thought me walking away from this place would lead to the company imploding, i'd do it in a heartbeat. 🤡

however, I think you're bestowing too much importance on this both place and my role within it... if I wasn't here, then users have the option to buy third-party addons to manage this stuff... they shouldn't have to, but the option is there.

5 hours ago, bear said:

Have to wonder if that's the intent, to create a need for custom coding they can then charge for? 

if that were true, they wouldn't have stopped offering custom coding themselves and pointing everyone to here...

if we're sharing paranoid thoughts, I did wonder myself if the lack of quality/quantity/thoroughness of the documentation is deliberate because it really is rubbish... the more detailed they make it, the more they would have to keep updated... and it seems the spirit in the camp is to do the least amount possible, .e.g, give the punter the briefest explanation of a function and let them figure out the rest themselves.... and supposedly there's a team responsible for the documentation, which makes the situation even worse... if it were one person, i'd cut them some slack... but not a team.

[yggdrasil]

This is exactly the garbage I'm talking about as well with hooks. I decided today to finally upgrade my PHP to 7.1, I was running a stable and secure 5.6 but this is only supported one more month by Red Hat.

Surprise, surprise. All pages where a hook is executed now give an error similar to this:

Oops!
Something went wrong and we couldn't process your request.

Please go back to the previous page and try again.
 

Checking the logs it seems WHMCS does not like something about PHP 7 as the error shows:

[WHMCS Application] ERROR: ArgumentCountError: Too few arguments to function WHMCS\\View\\Client\\Menu\\MenuRepository::addContext(), 0 passed in /home/example/public_html/vendor/illuminate/support/Facades/Facade.php on line 215 and exactly 2 expected in /home/example/public_html/vendor/whmcs/whmcs-foundation/lib/View/Client/Menu/MenuRepository.php:0 Stack trace: #0 /home/example/public_html/vendor/illuminate/support/Facades/Facade.php(215): WHMCS\\View\\Client\\Menu\\MenuRepository->addContext() #1 /home/example/public_html/index.php(51): Illuminate\\Support\\Facades\\Facade::__callStatic('addContext', Array) #2 {main} {"exception":"[object] (ArgumentCountError(code: 0): Too few arguments to function WHMCS\\\\View\\\\Client\\\\Menu\\\\MenuRepository::addContext(), 0 passed in /home/example/public_html/vendor/illuminate/support/Facades/Facade.php on line 215 and exactly 2 expected at /home/example/public_html/vendor/whmcs/whmcs-foundation/lib/View/Client/Menu/MenuRepository.php:0)"}

Switching back to PHP 5 works fine. Lucky for me, this is my dev installation and not live. If this was the live site the result would be that most of my WHMCS pages would be failing. I hope people read this and see what a disaster it is to rely on hooks for simple things. Anything that can go wrong, WILL go wrong and now you only need one error to crash your whole WHMCS page because if your hook is there to create a menu, I assume its almost on every page. This is another reason why using PHP hooks is just an horrible idea. You should limit using hooks to the as few places as possible, not build your whole site around them.

Another big problem with WHMCS 7. In previous releases, if a third party module was not compatible with your ioncube version, only that module crashed. On version 7? Your whole WHMCS installation crashes for one single module. Again, WHMCS is not handling errors and exceptions very well. Why should a module that is not even called crash even the admin side and the whole public site? This is just poor, very poor development. Third party modules should never crash your main WHMCS installation.

Edited August 25, 2018 by yggdrasil

[yggdrasil]

My point in the last comment is not about the error in the code. I was able to spot and find it quickly. My point is that something like this can crash your page when it should not. Changing menus or links on a site should never be a delicate coding operation prompt to this sort of problems. A broken link should be a broken link. A broken page should give error not crash the whole site. A image that does not load just just show an error in that specific spot...Making this PHP based makes it completely sensitive to even the smallest issues with the code. And this is not blame on PHP either, PHP is a coding language, it was never designed to create HTML pages like WHMCS wants to implement on their system. Example, you can even create an image by generating the binary with PHP and output directly to the headers in a browser. And I actually do this for some charts that I don't want someone to link directly as they require authentication. But I would never dare to generate all images with PHP this way just because its possible. That would also be an aberration. Hooks are great to interact and trigger actions that require automation, similar to a fake web cron, but using this to generate or replace code in templates is wrong.