Bootstrap 4 Support

Don't worry they will not update bootstrap at all and leave you with all the security holes. Even worse, users cannot upgrade on their own because WHMCS took open source files and encoded them violating GPL licenses while bundling third party open source code with their proprietary code. This is a NO, NO. While you can mix proprietary code with open source, you cannot encoded and release the open files as proprietary. This is precisely what WHMCS is doing and the reason why people need to post this a feature request. Just think about this. WHMCS does not own Bootstrap but you need to ask them to update the files, why? Because they took free open source files and put parts of it behind IonCube files as if they own that code. Tip: They don't !!! They only own what they coded under their files, they cannot change Bootstrap or other open source licenses, TinyMCE is another example on which they encode the original config file to avoid users from changing settings. Again, a file part of open source software that is under GPL but they put it under IonCube and put their copyright as WHMCS is the owner of that file.

That's not what they've done with Bootstrap. Bootstrap isn't encoded.

The problem is the core WHMCS code, which is encoded, generates html which isn't templated. So you might have a template for a page but the elements in that page such as a table or navbar is a chunk of html coming out of the black box that is WHMCS's encoded PHP.

Without reverse engineering the encoded PHP, we're stuck with that BS3 based output. So you end up having to develop two themes. A BS3 based theme for WHMCS and whatever you want to use (BS4, Foundation, Vue, React, Laravel or whatever) for your main site. It's time consuming. Or you just admit defeat and accept that your client support area is going to look out of place with your site.

It's been a while since I looked at TinyMCE but I think they actually just minify the javascript, which is perfectly fine. IIRC TinyMCE ships with a minified version even. The script tag with the settings *is* non-editable as it's embedded in encrypted PHP, not a template. There's no config file. And this is already off topic I guess.

@aegisdesign You mentioned HTML is generated from the PHP code before, but when we replied asking for details you didn't reply back. Can you provide some examples of the HTML you are referring to?

Sorry about that, I was rather gobsmacked at the time you asked then I left it. I'm still gobsmacked. Surely it would be easier for you to grep your code for BS3 components and classes that are deprecated than for me to guess?

But nothing has happened in a year so...

First, taking the six theme, delete the BS3 bootstrap css in css/all.css. Drop BS4's bootstrap.css file into the theme's css folder.

Change the includes/head.tpl file to load css/bootstrap.css and change the all.min.css to be the edited all.css. This allows you to swap bootstrap versions. Fine for development purposes.

Load the client area up now and look at the carnage - navbars not working, panels not working, floats not working, forms a mess.

Read https://getbootstrap.com/docs/4.0/migration/

You can fix the navbar with a bit of work in includes/navbar.tpl so the right classes are used on the items and dropdowns.

panels mostly work if you edit includes/panel.tpl to use card- instead of panel- classes.

Same for includes/sidebar.tpl replacing panel- with card- and pull with float.

Many of the templates in the includes/ folder are a good start to migrate.

But you can only go so far without coming up against embedded code in /vendor/whmcs/whmcs-foundation that generates .panel-, .pull-, font-awesome icons and more BS3 specific code.

eg.

Primary and Secondary sidebars use .panel- classes and font-awesome icons in your code for each item.

Dropdown navbar dividers are duplicated because of the way the code generates each item.

Forms don't always work because of changes to the way BS4 input-groups work.

There's also lots of spans, divs and p tags in the code but not in the templates which makes alternate layouts a bit harder. And am I right in thinking html tables are generated entirely in the code?

Those are what I remember looking at before deciding I wasn't happy chasing code changes and hoped it would be addressed soon. It hasn't.

It's not a big job to swap out BS3 for BS4 *with* access to the source code. Dare I suggest it's a couple of days work to do. (plus QA etc) There's big gains just with .panel- and .pull- search and replace.

The big problem of course is it breaks compatibility with existing themes. This isn't a problem for people who just change the logo in the six theme or maybe a header/footer since you're giving them the six theme. It is a problem for people who have custom themes as there's no method for WHMCS to know if the theme is compatible with a specific version of BS. Maybe check for tags in the theme's css header like Wordpress does or have a yaml info file?

Just swapping BS3 out for BS4 is also just kicking the can down the road for a bit (6 months apparently for LTS BS4 support). Ultimately we'll go through this again and again until the presentation code is unencrypted and separate to the controller code in the templates where it belongs. That break has to be done at some point and it would free up some creativity in the template designer market.

Thanks for responding. However all of the code you reference above is contained within template files. While it is valid to say that some class names are provided from the PHP code for convenience, they are rendered via templates and therefore are customisable. It was specifically the claim that HTML is being generated within the PHP code that we were looking for expansion on as we are not aware of any HTML tables or otherwise that is generated from code and not customisable.

That's simply not true. *Facepalm*

/vendor/whmcs/whmcs-foundation/ is littered with code generating html directly

Some of us have sat in their debuggers and tried to work out where code is generated to fix issues and replace encrypted code.

But, if what you say is true, then why are we still on bootstrap 3 if all the html is templated? There's not one third party theme using bootstrap 4 because all the theme developers know it's impossible.

aegisdesign you are now just basically saying what I said before in a different way. When I mean encoded, its not necessarily IonCube obfuscated. You have said the following in your latest reply, there is not one bootstrap 4 theme because developers knows its impossible. Why? Please answer this. The reason is obvious. Because they don't have access to the generated code in order to change. That is precisely what GLP and other licenses talk about when they say its a widely-used free software license, which guarantees end users the freedom to run, study, share and modify the software.

Any way you obstruct, prevent, hide, obfuscate users from making changes is a basically in non compliance with open source. Open source means OPEN, its developer friendly and everyone is able to directly modify the code. You are now confirming what I said before, you can't do it with WHMCS because they changed the behavior on how those original open source files work. If they are outputting code from other files, and you have no access to those files for modification, that is encoding open source files, you just changed the behavior in order to avoid users from making changes. The result is the same. If I download bootstrap from the source, I can change it. But I cannot change the bootstrap that comes with WHMCS. About tinymce, its the same story, they changed how the software works from the original sources. That even includes if you just link parts of the code, the cases are valid for GNU GPL and MIT licenses. Let me put it clear for those that don't understand. If I put a link or path from an open source file under a PHP encoded file, I'm not allowing the user to change the location on a server or drive for that file. Example, if I link to the open source files as /home/user/name/route-bootstrap.css and that single is encoded, I'm violating the open source file license, because now I'm not letting users modify the file name, the route, the link, the path and even worse, I could inject or change this in the future and since its encoded, you have no control over that. This is precisely what WHMCS is doing with many things on their themes. This is also why its so developer unfriendly, you even need to create hooks to output menu HTML/CSS code. Its horrible, you cannot just use a regular IDE to edit standard compliance code. In the past themes/templates from WHMCS did exactly that, you could just open the smarty file and change all the code.

This was the code that outputs to the user area, it has nothing to do with the logic or code. This is why you had so many third party templates until WHMCS version 5. Starting with version 6 when WHMCS moved to Laravel, they had the brilliant idea to remove things from the theme files and move them behind PHP, horrible performance, slow and non developer friendly. Result? People asking WHMCS to upgrade bootstrap as a feature request. This alone is insane. You need to contact the software developer company in order to upgrade free open source files because you can't, and none developer can't. Sure, you can intercept the output and generate your own output with PHP, JavaScript, but this would be a Frankenstein code, ridiculous in terms of performance and user experience. You don't design pages like that. There is a reason we have standards, like HTML 5 standards, CSS standards, and others. WHMCS follows none.

This is why you need to rely on hacks to modify something that takes 5 second with standard code. Web developers need to be PHP code developers in order to change the design or create third party themes. This is unacceptable.

We're going a little off topic here but what you both are suggesting is simply not true.

HTML output for the client area is not generated within the PHP code, it is controlled via templates. And it is totally possible for a 3rd party developer to create a client area theme using Bootstrap 4.

There is little to no HTML generated within PHP files. The few exceptions to that are code that is dependent upon or generated by modules for module specific output. In those cases it would be necessary to work with the developers of those modules to update the code they are generating but in the case of modules we ship by default, the majority of them should contain no bootstrap specific styling.

To bring this back on topic, the reasons we have not yet released official Bootstrap 4 support at this time is as follows:

* Low user demand - still only 54 votes in 28 months, that's less than 2 per month.

* Many customers websites still designed on and for Bootstrap 3, where Bootstrap 4 would make integration more difficult

* Many customer websites still actively using Bootstrap 3, which would require actively maintaining 2 themes

* Limited technical benefits to Bootstrap 4

* Better support for older browsers

I want to be wrong, really. But that is not the case. There are HTML tags and code, even links you cannot change on the themes anymore. This was not the case before WHMCS version 5. Why are there no bootstrap 4 third party themes available for WHMCS? 100% bootstrap 4 themes for WHMCS is technically not possible currently, unless you intercept the WHMCS output and replace it on the fly (each time a visitor request a page), this kills a server in terms of performance instead of reading code directly (overhead).

Bootstrap is just CSS and HTML 5 and some JavaScript. All of that is not server code but client side code. Client side code that is generated on the browser should never be done by PHP or a framework. The front end cannot be fully 100% customized at this point.

Limited technical benefits? Don't you think customers should decide what front end they want for their websites? If they want to use bootstrap 3, 4 or even 5, or something else (customized front end), that should be their choice.

I'm not talking about the admin side or third party modules. I'm talking about the front end visitors load. This should be completely separated from WHMCS leaving web designers and developers freely using what ever frame work or code they want for design and brand purposes. There is a reason why all WHMCS installations feel boxed and look the same. Restrictions, this makes it less attractive for profitable companies, customers or integrations. I know some people that will refuse to order from a WHMCS website because it looks cheap. If 100% customization was possible, they would not even be aware someone is using WHMCS. We don't have that choice now. Everyone is forced to follow similar design patterns and trends if they use WHMCS.

WHMCS should not be maintaining bootstrap for its customers. This involves even more work and more upgrade issues for future versions for your own developers (nightmare...). Client side front end should be isolated and separated. Once bootstrap 5 is out, you will end up with a fragmented customer base for years, those on 2, those on 3, those on 4 and those that want 5. Instead of focusing on the core software WHMCS developers now need to handle visual bugs and issues because they bundle everything.

@WHMCS

I am surprised by some of the arguments you put against upgrading Bootstrap.

1. Many customers websites still designed on and for Bootstrap 3, where Bootstrap 4 would make integration more difficult

Many customers are probably on low PHP versions too. Would you argue they should stay on PHP 5.6 or would you suggest they upgrade to a more recent version?

2. Many customer websites still actively using Bootstrap 3, which would require actively maintaining 2 themes

This is not a great argument either. You're maintaining PHP 5.6, 7.1 and 7.2. Upgrading to Bootstrap 4 doesn't necessarily have to break other themes. They don't have to upgrade. They can use their current theme. New features would most likely require changes on customer websites already.

3. Limited technical benefits to Bootstrap 4

I would argue the same for some PHP versions. Would that stop you from supporting PHP 7.3 or 7.4 in the future?

4. Better support for older browsers

You shouldn't decide which browsers to support on a customer's website. That's for your customers to decide. It's their website.

You've still not provided a single example of the HTML tags generated from the code that you keep referring to? Please provide some examples for context.

One specific example.

The ticket filter options in the primary sidebar are generated in the code with "panel-default panel-actions view-filter-btns" classes in /vendor/whmcs/whmcs-foundation/lib/View/Client/Menu/PrimarySidebarFactory.php and not in a template.

panel-* is deprecated in BS4.

Those are simply class names. All of the HTML output for sidebars is generated by the `includes/sidebar.tpl` template file and therefore is fully customisable. The class names can be easily manipulated in the template layer for use with a different frontend framework or library.