We learn a lot by sharing within our teams at Symbiote. I enjoy investigating and fixing bugs, because it’s a way to dig deeply into the various systems we use with our clients, and make them better. The great aspect of working with open source software – I know that if someone else hasn’t already fixed a problem, I can fix it and share the fix, so it helps me and other people in the future.

I recently documented a fix for a particular client issue that’d cropped up within Silverstripe, the content management system (CMS) we work with most frequently. We’ve got a culture of sharing what we learn, so I wrote down my process for working through this fix. I’m sharing it here, hoping it might help you too, especially if you’re new to the industry or in a new role.

Now, I’m fairly new to developing in Silverstripe – most of my experience is with React, together with TypeScript and plain old HTML, CSS and JavaScript, on the front end only – so I was keen to try to trouble-shoot this particular problem as much as possible by myself. 

After receiving the support ticket and reading the description, I tried to reproduce the issue. I could do that, and I could identify where the issue cropped up, however I couldn’t find where the code was being drawn from within the Silverstripe codebase.

Thankfully we’re a close-knit team here and everyone’s happy to help. Since I’d tried everything I could think of, I talked to a colleague who had a tonne of Silverstripe experience. However, after several different attempts, we were still stumped about where the code was actually coming from. 

Next stop for help: Marcus, our Head of Technology. He’s had more than 10 years of experience using and sharing Silverstripe code. Marcus did some tests and showed me where the error was happening. I made my best attempt to fix it but uncovered some access issues. A follow-up meeting with Marcus enabled me to design a fix.

But, as with lots of bug fixes, that wasn’t the end of things. 

The fix now needed to be persisted/tracked in the codebase, because so far, the fix changes had only been applied locally in the installed vendor modules, which are not tracked by Git.

To do this I needed to create a patch file of the changes that would be applied. But the course of true bug fixes never did run smooth, as Shakespeare would have said if he’d been a software developer. I hit one last hurdle when trying to push the patch across and hit a problem with the continuous integration (CI) pipeline, which wouldn’t grab source code from patches, only from distributed/build files. Once I removed the source code from the patch, the pipeline passed and the fix was ready. 

What did I learn? I initially spent a lot of time thinking that this particular problem sat in PHP, as that was my assumption around a lot of Silverstripe vendor packages, especially when it came to the CMS itself. On top of that, the only JavaScript I found that seemed to be causing the bug was compressed and mangled – not something I could work with properly. 

My first impulse was to work this out myself. Which is valuable, because it makes me really think through a problem. But once I’d exhausted all the things I could think of, I figured it’d be most efficient for the whole project if I asked for help. 

Next time I come across a Silverstripe issue, if I can’t work out the issue and source from the initial analysis, I now know how to look more deeply across all aspects of the codebase: PHP, JS and beyond.

And, since I’m lucky to work somewhere where everyone’s happy to help out, I won’t hesitate to jump on a call with team members. Everyone who helped with this bug fix learned something, so it was really valuable to share it. 

I hope you find this encouraging if you get stuck on something you’re learning.