Thanks Jonas, your PM hat is noted!

I’ve beefed up the `helper_tester` a fair bit, and I’m about to throw up a PR for the string helper (just picked that one to start with - no particular reason).

Went from 8 tests to 93, now covering all 14 string helpers referencing the official v2 docs. Found and fixed 3 small bugs in `engine/tg_helpers/string_helper.php` along the way, too.

Funny how quickly things show up once you start hitting edge cases properly - string stuff always has a few surprises hiding in it.

Anyway, onto the other four helpers next. Wish me luck 🤞

ps. Dan, Balazs, Jonas or anyone - please keep testing this helper to ensure we have captured everything.

Thanks. That's now pulled in.

Thanks also to Sasin for his suggestion.

When this is all done it's going to open up the doors to some amazing new functionality.

Hail Dafa. Hail Team Trongate!

Hi DC,

I've completed the rewrite of tests 😎 and pushed a PR of the last 2 helpers..

In summary:

While building the test coverage suite for the Trongate Helper modules (String, Flashdata, Form, URL, and Utilities), I conducted a thorough cross-reference between the engine source code and the official v2 documentation.

I wanted to pass along a few bugs and edge cases that were uncovered during this audit so you can review them:

1. String Helper (tg_helper engine bugs)
The string helper had a few bugs in the string service engine:
- truncate_str(): Was not multibyte-safe. It could corrupt UTF-8 characters (like emojis or accents) if the hard cut fell exactly on a multi-byte sequence (fixed by swapping to mb_strlen and mb_substr).
- filter_name(): Contained a regex injection vulnerability because it didn't use preg_quote() when replacing user-provided characters.
- truncate_words(): Used explode(' ', ...), which artificially inflated the word count if a string had multiple consecutive spaces.
- remove_substr_between(): Left double spaces when removing text between two words.
- nice_price(): The engine's return signature incorrectly stated string|float, despite the logic dictating it returns a string (e.g., "£15.00").

2. URL Helper (Quirks & Edge Cases)
- anchor() XSS Protection: The docs state, "Attributes and URLs are automatically escaped to prevent XSS attacks." The engine intentionally skips escaping the link text so developers can pass HTML elements (like <img> or <strong>) into the anchor. I've updated the test suite to expect this behaviour.
- get_num_segments() routing offset: Because Trongate auto-routes the second segment to the 'index' method, the underlying framework array registers 2 segments even when visiting a single-segment URL like '/url_helper_tester'.
- segment() type-casting: When asking for an out-of-bounds segment and casting it to an 'array', PHP's underlying settype natively converts the empty string "" into [''] (an array containing an empty string), rather than an empty array [].

3. Utilities Helper (Edge Case Quirk)
- return_file_info(): If you feed this helper a file without an extension (such as simply 'README'), the engine incorrectly attempts to concatenate an empty string with a literal dot. As a result, the filename is correctly identified as 'README', but the file extension is returned as a solitary '.' rather than an empty string.

Hope this helps track down a few of the lingering edge cases in the core helpers! Let me know if you need any more help on these. I'm off to bed now 🥱😴

Wow. That's amazing. Thank you! We're all super grateful.

By the way, there was another mistake that I made all over Trongate. I spotted it a few weeks ago. It's non-breaking but strictly speaking, it's not "proper". There were instances where I'd have something like a custom form validation method and the return types would be set as 'string|true'.

The idea here was that validation methods can only return either true (bool) or an error message (a string). Of course, it turns out that 'true' is not a valid return type. So, it should be return types of 'string|bool'. I think I've fixed that but as a quick note to self, I must remember to check that out and make sure it's cool too.

It looks like Dafa here has managed to give us some kind of full framework overhaul. This is great!

When the dust has settled, I'll do a YouTube video and discuss all of the madness that I've being going through this past few days. Nobody will believe me. However, I'm confident that I'll come away from this with a great education.

Hail!

DC asked for our opinions in one of his earlier posts. So please allow me to share my thoughts on this entire matter.

DaFa and sasin91, I have to respectfully disagree with the current approach. While the Service Routing update is a brilliant concept, the AI-generated implementation has introduced bugs and inconsistencies that are now draining the time of Team Trongate's best senior-level developers.

Our "rock-star" team shouldn't be cleaning up after a "junior-level" AI. For an architectural change this significant, I believe a manual approach would have resulted in much higher stability and fewer headaches.

I call a spade a spade: the AI messed this up, and I'd hate to see Trongate's reputation for stability compromised. I respect the decision made, but I believe we would be better off relying on our human expertise for the heavy lifting in the future.

Thanks Balazs. I was wondering what you were going to say.

By now - I assume you all know how I feel about AI.

Nevertheless, given the massive effort that has gone into this I think it's best if I play the diplomatic card. In other words, I'm happy to let you guys figure it out.

If it helps, I can tell you that there's no rush with this.

EDIT: For what it's worth, I had a quick look at the code and I think we will (unfortunately) have to update some of the docs. However, on the positive side, I think the code is probably good. If we can agree to (let's say) a ten day cooling off period for testing or whatever then maybe that could work.

I'm 92% sure that the code is good.
I'm 100% sure that if something went wrong then it would be fixed within 24 hours.

Okay folks, I'll start with an apology. In my last post I said the word "I" about a gazillion times. So, I apologise for always finding a way to make this about me. Nevertheless, if you can put up with this guy saying "I" a few more times then I think I may have come up with a good solution.

I <--- there it is! --- think I've come up with a good way to move forward. Some of you have worked really hard on this thing and, as far as I can tell, testing everything is miserable (with or without AI). If this was a week or two previously then I'd be all in for the idea of saying "no thanks AI". However, I think we're in too deep.

To quote from the great William Shakespeare himself:



I admire the boldness of Balazs. I respect the philosophy. I agree with him. However, in this instance, turning back and going to back to square one would be massively painful. It would also mean that people have wasted their time on this.


There's no better testing ground than the real world. So, I'm going to take the validacious repo on GitHub and I'm going to use it for three real websites that I'm working on. One of which will be the Trongate website (this website!) and the others will be a couple of other sites I'm working on. One of the sites I'm working on is due for launch in about 11 days - the other, in about four weeks.

So, we'll have three sites using this code out in the wild. I'll be watching all three sites like a hawk. If anything goes wrong, you can rest assured I'll be on the case in a heartbeat.

Before midnight TONIGHT this website will be using validacious.

Problem solved. Thanks for all your help with this.

Hail Team Trongate!

DC

A total power move from the web developer extraordinaire! I think that is exactly what was required in this situation. I like it! 👍🏻