Top Five Tips for Mastering Trongate

From a strictly technical perspective, Trongate's greatest strength is its architecture. It's the only PHP framework I'm aware of that enables developers to build modules that are entirely self-contained. This means a module can include far more than just PHP code. With Trongate, modules can contain CSS, JavaScript, images – and even other modules!

One of the common mistakes I've observed is when developers say things like, "I've built 'X'" (where 'X' might be a forum, an invoicing system, or some other impressive feature).

Technically, what they've built (as far as I can tell!) is outstanding – both in terms of code quality and usability. Unfortunately, all too often, the code is not self-contained. So, instead of encapsulating the entire feature within a single module, developers end up spreading it across multiple modules. This makes reusability difficult and rules out any chance of having the code featured on The Module Market.

The solution is simple. Make your modules self-contained. In particular, take the time to understand how to nest modules within modules. Once you start building this way, you'll never look back.

At the heart of Trongate lies the engine directory. This folder contains all the core files and essential inner workings that power the framework. It's the DNA of Trongate – the low-level code that handles everything from routing and controllers to view rendering and security helpers.

As tempting as it might be to tweak or "improve" something within the engine directory, I strongly advise against it. Modifying this directory can lead to instability, break future updates, and make your app incompatible with tools and modules built by others in the Trongate community.

Trongate is designed to be extended, not altered at its core. If you find yourself wanting to change how something works, ask yourself: "Can I solve this by building a custom module or overriding behaviour through the normal application structure?" In nearly all cases, the answer will be yes.

There is, however, one small exception to this rule: the $debug setting found near the top of the Model.php file. By default, this is set to false. During development, you might find it helpful to temporarily set $debug to true in order to inspect the SQL queries being executed by the Model class. This can be an effective way to troubleshoot or optimise your data layer. Just be sure to return it to false before moving to a production environment, as leaving it enabled can expose sensitive query information.

So remember: trust the engine, and don't mess around with it. It's the foundation that makes everything else work as expected.

I wasn't sure whether to title this tip:

"It's okay to use third-party libraries."

or,

"Avoid using third-party libraries."

Confused?

Allow me to elaborate.

One of the misconceptions about the Trongate framework is that it doesn't support third-party code. I'm referring to tools and resources like Packagist, CSS frameworks, JavaScript libraries, and similar external assets.

Nothing could be further from the truth. Trongate was built to integrate smoothly with third-party resources, including Packagist. Not only do we cover this in the documentation (and here is the link!), but the Trongate website itself uses a variety of third-party libraries.

So let me be crystal clear: Trongate works beautifully with third-party code. There's a wealth of valuable tools out there, and you're absolutely welcome to use them alongside Trongate.

However, experience has taught me a valuable lesson – relying on third-party code introduces risk. Specifically, it compromises stability.

Here's a real-world example.

The Trongate website currently uses a third-party library for handling "social auth" logins. I implemented the system, but I didn't write the underlying third-party code.

Just a few days ago, I encountered a couple of issues related to the login system. Whether those issues stemmed from flaws in the third-party code or were just momentary glitches remains to be seen. Time will tell.

Speaking personally, I use third-party code all the time. However, I do so with a clear expectation: at some point, it will probably break. You may call that pessimism. I call it preparation. Maintaining a healthy scepticism about third-party dependencies can save you from both a false sense of security and a mountain of frustration when something suddenly stops working.

So yes, use third-party code – but use it with caution. And above all, expect it to break.

And while we're on the subject of stability, let me remind you that Trongate is PHP's only "v1 forever" framework. It's the only framework I know of that puts stability at the very top of its priority list.

I can't promise that Trongate will never break – no software can offer that. But I can say this: Trongate is the only framework I'm aware of that was designed from the ground up to make stability its highest priority.

I remember – a number of years ago – I posted a tutorial series on YouTube covering another PHP framework (not Trongate). I will refrain from naming the framework because none of the people behind that PHP framework are here to defend themselves. However, it's an excellent framework and I really like it. The code (which I've looked at) is outstanding and it's packed with great features. I'm a fan!

After recording about ten or so videos, I ran into some technical issue that I needed to figure out. This was probably about six years ago, and my memory on the topic is weak. However, I think it was something to do with uploading images. Regardless of whether or not that was the particular issue, I remember that I just needed a quick word of advice pertaining to this one thing that wasn't made clear in the documentation.

Anyway, to cut a long and miserable story short, I remember hanging around a discussion forum for three or four days trying to get help. I couldn't get any!

Because I hadn't posted much content, I felt like an intruder (perhaps that's my fault and not theirs!). In any event, I ended up offering cash for questions – and even that never worked. Nobody would take my money! So, I took my tutorials down and I gave up on that particular framework. That was hugely disappointing for me, at the time.

That type of scenario will never happen with Trongate.

We have online discussion forums. We also have some incredibly kind, generous, and positively charged people who love helping others. If you run into any issues or you just need a word of advice, use these resources. It's why they're there.

If you reach out for help, I promise - nobody will ever tell you to "go and read the manual". As strongly as possible, I want to encourage you to reach out and ask for help, if and when you need it.

Oh, and if you'd like to reach out to me personally, you can contact me via this page.

If I had to choose just one method for mastering a subject – whether it's a framework, a language, or a skill – I'd say this:

Teach it.

There's something transformative that happens when you step into the role of teacher. Concepts that once seemed fuzzy become crystal clear. You spot gaps in your understanding that you didn't know were there. Best of all, you begin to think more critically, more precisely, and more creatively.

So here's my challenge to you: post a tutorial.

Don't wait until you've "mastered" Trongate. Don't wait until you've built something big or finished some monumental app. Start where you are. Share what you know. Start today!

Your tutorial could be a blog post, a YouTube video, a tweet thread, or even a complete online course. It doesn't have to be polished or perfect – it just has to be honest and thoughtful. I can assure you, there are plenty of developers out there who will appreciate it.

By the way, we have a YouTube channel, and we're actively looking for contributors. If you've ever wanted to make your mark, help others, or simply give back to the community, this is your chance. We (and I speak on behalf of all the folks at "Team Trongate") would love to have you on board.

I don't care if you've never posted a tutorial before and I don't care if you've never written a line of code in your life. Often, people who have little experience post the best tutorials because they speak on a level that most people can understand. Therefore, If you'd like to get on board as a person who teaches Trongate then I want to positively encourage you to get involved.

Interested in getting involved? Don't waste another minute. Get in touch!

Building a framework is relatively easy. Writing documentation, on the other hand, is a nightmare. If you find anything in these docs confusing, unclear, or just not quite right – it's not your fault. It's mine. I take full responsibility.

If you spot an error, notice something missing, or think a section could be better explained, your feedback is invaluable. Your feedback helps to make these docs clearer and more useful for everyone.

So, I hope I'm very clear. If there's anything in the Trongate documentation that is confusing for you, do not allow that challenge to harm your self-esteem. Instead, just blame me. It's my fault. Not yours.

Please report issues or suggest improvements on GitHub. That's the best way to help improve the documentation quickly.

Not comfortable with GitHub? No problem - you can also get in touch via this contact form.

Your voice matters and your feedback is welcome.

I've just realised this is the final page. So, I feel strangely obligated to end with something deep and meaningful. That being the case, I have to say - I really like it when you go to a Chinese restaurant and they give you those little fortune cookies. You crack them open and inside is a mysterious message, usually something weirdly vague yet oddly profound. Those are good, aren’t they?

May the code be with you!

DC