Update WHMCS to Bootstrap 4 instead of 3.3.7.
Thanks for your continued contributions to the discussion. Let's please keep this request on topic regarding Bootstrap 4 implementation. A discussion of changing how the template system works would be best assessed on its own merits, eg: https://requests.whmcs.com/topic/whmcs-child-themes-in-wordpress-style-to-make-upgrades-less-work
We're excited about some of the new abilities in Bootstrap 4 and are certainly keeping a close eye on the development and adoption of it among our users. A major consideration for us when it comes to making a switch like this however is in ensuring WHMCS remains universally and easily adaptable and integratable into our customers existing websites, and for that reason we believe switching at this time would be premature. We will however be re-reviewing this regularly.
As you no doubt already know, as of 18 Jan 2018 Bootstrap 4 final was released so any hesitation because of alpha/beta status is no longer warranted. Please consider adopting Bootstrap 4 as soon as possible by leaving the six template as is, with only bugfixes, for those who need it and adding something like a "seven" template based on BS4. I'm sure the "community" would pitch in with plenty of patches. Thanks.
It might be fair to look at this closer in a few months. Most themes will now be moving to Bootstrap 4 now that it is marked stable.
It's important to be up to date with those structural components
As suggested previously, it would be nice to have a "Seven" theme - keeping "Six" with BS3 (for backward compatability) and the new "Seven" theme to move things forward. We have recently re-developed our main website in Bootstrap 4 and have had to develop the same theme twice in order to integrate with WHMCS' software.
Thanks for your suggestion. We are aware of Bootstrap 4's release earlier this year and have done some initial investigation. Due to the backwards incompatible nature of the changes, an entirely new template is necessary. It would also be necessary to re-write the order form templates for use with Bootstrap 4.
The semantic versioning we use would typically dictate that such backward-incompatible changes require a major version bump (eg. v8).
Due to these considerations, this isn't something we are able to implement today, but it's something we are interested in doing in the future.
Any ETA ?
BTW Backward compatibility still possible with Template six and Template seven can be bootstrap 4. I think WHMCS don't need the major release for this.
There is no ETA at this time. But please do keep generating support for this feature request. The more votes it receives will help demonstrate to us that there is appetite from the WHMCS user base for this feature.
The problem is WHMCS v7.x generates Bootstrap v3 specific HTML and CSS classes. Not all the output is templated. So not only would you need a 'seven' template and new orderform templates BUT you'd also need WHMCS itself to generate BS3 compatible HTML/CSS for the six theme and BS4 compatible HTML/CSS for the seven theme.
They should really remove all HTML/CSS code from WHMCS and put it in templates making WHMCS completely independent of any chosen front-end layer so you could pick BS3, BS4, Foundation, Timber, Vue, React...
The seven theme suggestion above is perfect, would be great to see this inplemented!
Thanks for your continued comments.
A major consideration, in addition to creating a new main theme itself, are the order form templates. These are currently all designed for Bootstrap 3, and so would also need to be refactored (or an entirely new set created from scratch).
Presumably there would also need to be some kind of dependency system created to prevent an order form template being selected in conjunction with a theme designed for different Bootstrap versions.
This means that maintaining two themes for different versions of Bootstrap becomes technically complex very quickly. So the preferred option might be to go for a hard swap in a major version, rather than operating both side-by-side for several minor versions.
What are your thoughts on that approach?
@WHMCS John - Either way, we need BS4 sooner rather than later. The community is becoming much more active in this thread (despite it being open for 9 months). It's becoming pressing for most now. We are currently maintaining a basic BS3 and BS4 version of our website to make integration into WHMCS easier, and honestly - it's a nightmare and doubling my workload.
Maintaining different versions would be indeed complex and time consuming. For now a hard swap probably is going to make it. I'm not sure what John means by saying it requires a complete redesign for the themes and order forms. Not at all. Just the classes on the code has to be updated to use the Bootstrap 4 styling. Its as simple as looking up the Bootstrap migration documentation (many articles are written as well) then doing a search and replace function for each file and it will start to work and look as before. The visual looks on the order forms and themes is almost the same, the changes are minor like a bigger font and some some things are using different libraries but all it requires it searching the old functions and replacing them with the new BT 4 Style. The real changes are under the hood. I'm in the same boat as Lee now, having to maintain 2 versions because we moved almost everything already to BT 4, now WHMCS is holding us back for months now and we need to maintain 2 code versions and revisions of everything and still cannot upgrade the main website because of all the legacy code in WHMCS.
A hard swap would be preferable if it's NOT going to take another
year to hit a stable release. If a copy of the six theme, and
orderforms, were "dumped" on Github with a small amount of custodial
guidance from WHMCS then I'm pretty sure the community would have
already done the grunt work and refactored the new theme to BS4 by now.
with a refactoring, the concept of adding a different "child" theme
based on a parent theme, with only the changed tpl and css files in a
new child theme, would be a huge improvement. We have the general
Wordpress child-theme example as a guide. For me, I find I only need to
modify a dozen lines of template code so I am reluctant to make a mass
copy of the six theme because then I have to track template changes in
major updates otherwise my site breaks. I have found it's easier to
script sed edits to the templates after an update or fresh install so I
only have one small script to maintain. The custom.css file really helps
but the templates themselves need to be managed as a child-theme for
those of use who only need to modify less than 10% of the templates.
I think this is a great idea, but should be a feature request in it's own right.
It's always struck me as odd, and I've been using whmcs since v3.x, that the order forms are cross theme. They should be rolled into the theme.
Duplication of template files could be perhaps mitigated against by implementing child themes that override the core theme. See how WordPress or Prestashop do this for example.
Another problem I've come across in removing bootstrap from themes is there is still html generated within whmcs. Ie. Some html output is not templated. It means we're stuck using Bootstrap and can't use anything lighter or more modern.
Or just move order form templates to within each theme?
Or implement proper theme overrides so you can have a core set of templates with only overrides in the theme where required instead duplicating every template file in every theme as you currently have to do. It would making upgrading easier as we wouldn't have to worry about an upgrade overwriting templates or having to diff template changes on every upgrade.
However, I'm not sure it would be possible to implement a BS3 & BS4 set of templates at the same time as there's still a significant chunk of html that gets generated within the whmcs code and is not templated. Last time I tried to strip out Bootstrap and replace it with something else, I quickly realised parts of it are impossible as it generates code containing bootstrap specific html & CSS classes before they hit the template tags. Until whmcs completely separates the view, we're stuck with bootstrap and possibly be at that.
That's where I got stuck trying to upgrade from BS3 to BS4 myself - some of the tags generated were depreciated! I'd have to write a load more CSS to make it work backwards.
I was able to do a BS3 to BS4 migration a few months back. It was so much work that I scrapped the project altogether. I ended up using so much JS to overwrite and swap classes or data-attributes that it wasn't worth the effort.
Oops. "possibly be" = "possibly v3". I blame my phone's autocorrect. ;)
If you're going to go through this process of updating the themes from BS3 to BS4, please do an overhaul of the theming system itself. A lot of HTML is still hardcoded into WHMCS and inaccessible from the TPL files (especially on the admin side). I do like the idea of a WordPress-like theming system with child themes associated with it. This would make customizations much easier for people who are not able to dig deep into HTML/CSS/JS/PHP.
I think WHMCS is at the point where it could make it a little easier for people to adjust their themes without this knowledge. Setting up key configuration options for colors, fonts and other changes would give customers a sense of freedom. This would not be of much help for theme developers like myself, but if it's a system our themes can tie into then great.
A great example of this is a system like that of XenForo. It has the parent/child theming system like WordPress, but also a very easy to edit system that allows you to make changes to your theme on the fly without editing the CSS. It has basic configuration options for each theme, colors, fonts, etc. Implementing a system like this would definitely make WHMCS a more attractive software for people seeking to look different.
I believe your idea of adding checks to the theme system would suffice. With these changes, you wouldn't be able to take older WHMCS and continue to use them.
I think there is a lot you can do here, but the first step has to be moving all hardcoded markup out of the encoded files and into TPL files. In addition to cleaning up a lot of the markup that's still in use today (more for the admin themes).
I'd add that this is the same problem we had with being stuck on Bootstrap v2 for such a long time also. Back then it was easier to implement you own Bootstrap v3 theme as there wasn't so great a difference between v2 and v3.
I know WHMCS (the company) can't predict breaking of incompatibility between 3rd party framework versions but it perhaps should have been obvious then that being reliant on a particular version was not a good thing. Yes, putting the six theme out on git was good but it's not really helped move forward with Bootstrap because of the encrypted code still generating some of the HTML.
Can you provide some examples of the HTML being generated from encrypted code? There should be little to no HTML being generated and output that isn't controlled via templates within the client area.
Are there any updates on this yet? Do you have an ETA?
Ironically, that discussion on child themes is now read-only, archived and 6 years old.
Its really interesting how WHMCS is using EOL third party software. This would not be an issue if it was not for the reason that people cannot just replace the bootstrap files and decide to upgrade on their own because code is inserted from closed source files into templates. This means WHMCS customers cannot just upgrade bootstrap and other vendor files and are the mercy of WHMCS developers.
Agreed! I personally think WHMCS should be more open source to allow for further customization.
Bootstrap 4 is very much the way forward. I would like for this to be implemented and believe a new theme, "seven" as suggested above to be the right approach.
Update to bootstrap 4 please the User experience in WHMCS is desperately lacking!
Bumping this. Bootstrap 4 has entered Long Term Support with release 4.4.0 yesterday and will receive no new features. New features are going into v5 only.
As such, this feature request should probably be closed. ie. Do not update to Bootstrap 4.
Please, please, please just remove the embedded reliance on any presentation framework and build it in to templates so we don't have this situation going forward.
v3 was End-of-life in July 2019. v4 will be EOL in 6 months from now with no security fixes. WHMCS v7.9 beta (released yesterday) is still using Bootstrap v3.
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.
@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.
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.
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 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).
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.
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.
Comments have been locked on this page!