Categories not working (v. 15.0.2)

[JTS-FIN]

Using latest module v 15.0.2 with latest ispapi registrar module v7.0.3. Not using Suggestion Engine. Tested using blank WHMCS v.8.2.1 Twenty-One theme and also Six using latest Chrome and Firefox for Windows.

When using the mydomainchecker.php as a client, the categories do not work as intended. The default selected categories are not applied to searched or shown domains. Also selecting other categories do nothing. As if the javascript event listener for these button wouldnt not work at all.

I have tried emptying the template cache and using incognito. Also reset categories, switch setting in admin area, and save addon module settings. Only reseting to v13 or v14 seemed to fix the issue.

On the side note: Why was the domain-in-box feature removed? It seemed like a good feature to highlight the domain client was searching.

Also the old version added domain to cart instantly, why was that changed? Now client has to wait until backend tells it is ok for it to show. Not as responsive as it used to be.

[KaiSchwarz-cnic]

@JTS-FIN sorry, for the late reply. For an unknown reason, I have not received a notification about this github issue. In general we are reacting to issues/customer tickets few hours after creation. I just stumbled over this gh issue now while checking a PR.

On the side note: Why was the domain-in-box feature removed? It seemed like a good feature to highlight the domain client was searching.

We do not remove features, we add them. The only thing that has been removed were Aftermarket Domain names, but just because they are in general incompatible with WHMCS' transfer process. That's really the only thing we removed and I even added a task to our backlog to analyze if we can find a way to continue offering them, while keeping the transfer process in whmcs working as expected (aftermarket domains are already registered, still they can be purchased - so we returned them as available. WHMCS pre-checks transfers, but if domains are returned as available, they cannot be transferred. that was the pain point with aftermarket domain names).

Also the old version added domain to cart instantly, why was that changed? Now client has to wait until backend tells it is ok for it to show. Not as responsive as it used to be.

Also this has not changed.

I guess there are multiple issues you're/were faced with. The later issue with instantly adding domains to cart could have been related to the fact that we were under a heavy DDoS attack about a week ago. Responses were highly delayed therefore or even timed out. That might leave the impression that a instant adding of domain names is no longer possible.

Also, switching between the categories could have been affected by the DDoS attack, when switching categories, new domain searches are triggered which might also have run into timeouts or highly delayed responses.
Therefore, please be so kind to give our version again a try. If there's still something not working as expected, please follow-up here.

Again my pardon for the late reply, this is really unusual for us.

[KaiSchwarz-cnic]

... and regarding the DDoS attack: I can forward that our team has reviewed and hardened the infrastructure to not again run into all these issues. Let me also forward our excuses for this.

[KaiSchwarz-cnic]

Closing. Feel free to reopen in case this issue still persists. Thanks!

[JTS-FIN]

Hi, I made videos to demonstrate what Im talking about. Same installation. Default six template. Newest WHMCS.

v.15.0.2:
https://youtu.be/RmT22I7cLdM

v.9.2.2:
https://youtu.be/hAlUYUxtajs

As you can see, 9.2.2 has a big information box "Your domain is available". This is what I was referring to when I talked about "domain-in-box". Also the adding to cart is instant in 9.2.2 but very sluggish in 15.0.2. Also 15.0.2 demonstrated how selecting categories does nothing, list is unchanged no matter what you select. Didn't show it on the video, but it works on 9.2.2.

Let me know if you need further details.

[KaiSchwarz-cnic]

Ah, yes. This "domain-in-box" - I remember, we have this big box removed, but replaced by a more compact line in search results to save some space. It did not provide any benefit (compared to the compact one shown below), just taking page space.

[KaiSchwarz-cnic]

I'll check the latest version regarding six template compatibility and performance. I really wonder why v9 could be faster than v15 as we have worked on performance improvements somewhere in v14 or v13.

[KaiSchwarz-cnic]

Hey @JTS-FIN,

Performance
I am actually checking and working on the performance issues you are reporting.
I use microtime() in our source code to identify what is raising runtime in our addon. I can forward that in case a request takes longer, it was always a matter of loading the init.php - so the WHMCS Core System with all its dependencies and configs.

Without loading the init.php for ajax requests - which is of course something to think about - we would have to code with pure PHP. So, for example not using Capsule for the DB queries, not using WHMCS native classes for data lookup. This is something, I noted down as idea - but, I guess really hard and time consuming to work on. This is further more not something that has changed from v9 to current version.

I have no idea why the load of the init.php takes sometime long where it is very fast usually.
In v9 the Domain Search was mainly PHP-based and with v10 we moved logics / process flow to javascript especially to save runtime on php's end and to make the addon far more flexible. in v9, there were no success / error modals popping up, maybe a reason why it leaves the impression of being faster .. no idea. I would be interested in comparing average xhr request runtimes.
That would give a far better impression. I no longer remember how v9 exactly worked, years ago and tbh, my available work time is highly limited and not allowing to dive into this topic deeper. So, again, I noted down to check for a pure/native PHP-based processing of background jobs without loading the init.php. That would eventually speed up a lot.

Still, I worked on a bit of micro tuning, but this won't of course help with the init.php load time which is responsibility of WHMCS itself. Improving the load/runtime of WHMCS, means also to improve DB accesses, PHP, Web Server. So, something out of our scope, but you can of course dive into this a bit. Still, I am aware of that this was not your point.

I'll continue now with your other findings and other things reported to my hands regarding this module. All my changes will be merged somewhere next week I think.

Anyone can see these performance measurement in future in the response headers of the API call. There will be a header field labeled X_PERF which then contains a json encoded string, which can be decoded using for example https://jsonlint.com.

{
	"script": {
		"start": 1633685217.713236,
		"end": 1633685221.699727,
		"rt": 3.9864909648895264
	},
	"init.php": {
		"start": 1633685217.713247,
		"end": 1633685220.93907,
		"rt": 3.225822925567627
	},
	"addon": {
		"start": 1633685220.940139,
		"end": 1633685221.699727,
		"rt": 0.7595880031585693
	},
	"dispatcher": {
		"start": 1633685220.942317,
		"end": 1633685220.942384,
		"rt": 6.699562072753906e-5
	},
	"controller": {
		"start": 1633685220.942385,
		"end": 1633685221.699721,
		"rt": 0.7573361396789551
	}
}

The above is an example of an ajax request taking very long where the script runtime is about ~4s and the load of the init.php takes 3.2s. Our logic on top just is about ~0.8s which is basically fine. I guess, WHMCS as backend is not the best sparring partner for javascript layer, but can be improved.

Basically, things could get technically improved with http/2 or http/3 support, but this depends on the web server in use at least.

Categories/Performance
Regarding fast switching of categories: We of course cache search results on browser-side for a while, but keep also in mind that when massively switching categories on and off, this will end in having a lot requests being still in processing by PHP even though we cancelled the ajax requests of previous category switches. So, with every category switch you might trigger further availability checks (for the domains we have no results yet). Click Jacking with categories slows the entire page down.

... continuing

[JTS-FIN]

Hi

My problem with the categories is not fast switching, but the fact that they don't work at all in my installation. None of them do anything like I demonstrated in the video.

Regarding the performance v9 vs v15, it seems obvious to me that in the v9 the client doesnt wait a response from the backend. It just instantly says it is added to cart, when in reality backend is still processing the request. I also think this is a better approach than in v15 since it works like 99,99% of the cases anyway. If backend fails, then the "Added to cart" message should be reverted and say it failed instead.

Best ofc would be something like this when user adds a domain to cart:

• Instatly say "Adding to cart" in the area where user clicked. So user knows the click came through.
• If it success change it to "Added to cart"
• If it fails change it to "Adding to cart failed"

However we already made the decision to stay in the old 9.22 version, it also seems to work with the latest WHMCS versions. We rather much like domain-in-box from usability and commercial perspectives, so v9 works much better for our needs than later versions in which this feature was removed. Would appreciate if you would consider bringing it back in the future versions.

[KaiSchwarz-cnic]

@JTS-FIN I understood the category switch problem already, no worries, just wanted to provide you some early feedback.

Best ofc would be something like this when user adds a domain to cart:

Instatly say "Adding to cart" in the area where user clicked. So user knows the click came through.
If it success change it to "Added to cart"
If it fails change it to "Adding to cart failed"

I remember having such kind of idea in backlog - showing a spinning icon temporarily instead of the checkbox.

[KaiSchwarz-cnic]

@JTS-FIN Regarding the category switch issue - I noticed that the bundled javascript and css files were missing in the archive. That's why neither the admin area nor the client area were working - missing javascript libs.
v15.1.0 is now launched including them and with several further patches and the discussed spinning wheel when adding/removing to/from shopping cart.

Why haven't we noticed such a breaking issue? We internally develop using symbolic links and not with a build package. So, if we cannot reproduce something, it is bound to such a difference. Lack of work time and man power is another issue. Sorry for the inconveniences caused.

I noted down your request for that "domain-in-box" feature. Maybe something we can reconsider (maybe by default turned off, but can be turned on by configuration?). Just keep watching the release notifications.

In addition, I want to replace our native jquery & browser-api based javascript approach with a SPA JS Framework to make our module better maintainable (and structured). VueJS or another more lightweight framework - and the domain-in-box feature comes directly after. That's my personal planning on our module in addition to a lot more interesting features of course.

Closing. If you have anything else, just let me know.

HTH