Why The Underscore-First Trick Had To Go

David Connelly ~ January 22nd, 2026

Trongate v1 prevented URL invocation through the use of an "underscore-first" method naming convention. The code was good. It worked. We had a good thing going. When building Trongate v2, the decision was made to ditch it. The reasons for getting rid of this functionality may surprise you, but it demonstrates some of the philosophies that separate Trongate v2 from Trongate v1.

The idea was simple: if you wanted to prevent a method from being invoked via the URL, you simply started the method name with an underscore as its first character. For example:

function _calculate_tax() {
  // This could not be invoked by the URL
}

If your goal is to build a framework that's super easy to learn, I hope you'll agree, that is/was a pretty good and intuitive solution.

So What Went Wrong?

When building Trongate v2, the very difficult decision was made to get rid of the underscore-first naming convention. To fully explain why, allow me to give you a little PHP history.

A Little Bit Of PHP History

Before PHP 5 (2004), there was no visibility (public / protected / private) for methods or properties.

Back in those days, developers used prefixes to signal intent:

_method_name() → meant "this should be treated as protected or private / internal - don't call it from outside the class"
__method_name() → sometimes used to mean strictly private (double underscore)

This pattern was widespread in older projects, PEAR packages, CodeIgniter, early CakePHP, and many PHP 4 and early PHP 5 applications.

The Problem

Strictly speaking, what those historic applications were doing was functionally different from what Trongate v1 was doing. Trongate v1 used the technique to prevent methods from being invoked via the URL - but strictly speaking, the methods were still "public". As for those historic PHP developers, their usage of the underscore-first technique had something to do with a work-around for access modifiers. The difference is nuanced but significant. Unfortunately, however, the internet does not like nuance!

Trongate v1 was built for speed. That means fast page load speed but also speed in terms of productivity. Being able to prevent methods from being invoked via the URL by typing in just one character (an underscore) felt great! It was super fast, super easy and perfectly in alignment with everything Trongate v1 was trying to achieve.

Unfortunately, when Trongate was using the underscore-first trick to prevent URL invocation, I observed one or two misinformed podcasters claiming that Trongate was "old-fashioned" - precisely because it was using this technique (and, of course, because it rejected everything to do with Composer). They were wrong. They had erroneously assumed that Trongate was regurgitating old methodologies from a bygone era. Those naysayers didn't take the time to do some honest research into how Trongate works. If they had, they would have discovered that Trongate was in no way the same as those legacy frameworks.

Having to constantly explain decision-making processes and framework nuances to PHP developers was a challenge, but a winnable one. Unfortunately, however, that situation became unwinnable when I observed that that some AI tools were making the same erroneous assumptions about how the underscore-first technique works, with Trongate. When that happened, I knew it was "game over".

The primary goal of Trongate v2 is to be the most AI-friendly web development framework in the world. In order to help achieve this goal, we decided to replace the underscore-first naming convention with block_url().

This was, indeed, a painful decision. However, it makes the framework more "guessable" for AI systems. As a bonus, we can also use block_url() to protect entire modules from URL invocation.

For more information about this, check out the documentation on Preventing URL Invocation.

I think that what we now have is a very nice, easy-to-use feature.

Final Thoughts

Let me wrap this up with a slice of humble pie.

I have just written an entire page explaining why an esoteric feature from Trongate v1 was replaced in Trongate v2.

And I have to ask myself: "How many people actually care?"

The honest answer is almost certainly, "hardly anybody". I am not delusional, and I do not - for one moment - imagine that there are millions of people lying awake at night, desperate to understand why the underscore-first trick was removed.

Nevertheless, if you have read this far, then I suppose you care.

So, to you - the reader - I say two things. First of all, thank you - sincerely. Secondly, I hope you can see that "building a framework that works in harmony with AI" is not a hollow marketing slogan or a fashionable cliché pulled out of a hat. It is a guiding principle that has shaped real decisions - including difficult ones.

Personally speaking, I didn't see this AI revolution coming - but here we are. Those of us who are involved in web development have to make a decision:

Hope that AI goes away
Embrace the AI revolution

I say, "Choose the second option, every time!". That's the optimistic option!

Folks, I cannot see the future and for all I know, we're all coding ourselves out of web development jobs! I really hope that AI will not lead to massive levels of unemployment, but if that's the way it has to be then let it happen on our terms. Instead of running away from AI, like a bunch of terrified weasels, let's run towards it, grab it by the horns and make it ours.

Let me assure you, Team Trongate is serious about building the world's most AI-friendly web development framework. I am optimistic that we will get this right. And when we do - some very cool things can happen.