Investigating bugs with Silverstripe vendor packages

Published Feb 23, 2022, 5:15 PM
Written by Chris James

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 (https://www.silverstripe.org/) – 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 Jem, who has 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.

Silverstripe CMS
Silverstripe CMS

Hey, I'm Chris

I'm a Front-end Developer who has a passion for creating striking user experiences. My background in building web ad campaigns and React-based interfaces. I'm always eager to learn new skills and technologies, to satisfy his own drive for information and to go the extra mile and provide the best experience for the people who use what we build.

Chris James - Front-end Developer - Aspiring Synthwave Producer

Team member

Chris James - Front-end Developer - Aspiring Synthwave Producer

A motif of six squares arranged in a grid pattern with three squares on top and three squares on the bottom

I'm a Front-end Developer who has a passion for creating striking user experiences. My background in building web ad campaigns and React-based interfaces. I'm always eager to learn new skills and technologies, to satisfy his own drive for information and to go the extra mile and provide the best experience for the people who use what we build.

chris
chris