One of the challenges of working with a pre-purchased template is that it can be a ‘black box’ that a developer knows little to nothing about from a code perspective and this can cause serious development problems for the unwary.
One of the best ways to avoid falling into the black hole of an unknown template is to budget the time to analyze the template from the outset and to examine all of the pages and assets that come with that template in a very methodical fashion. Go through the code line by line to gain an understanding of how the designer/developer structured the design. If the code is poorly commented, go through the exercise of commenting it yourself. There’s nothing quite like getting down at the ground level with a template and figuring out what it’s really saying, element by element and then marking those elements with clear, easy-to-read comments for the next person who will be handling it after you.
Once your template is fully understood so that you know without really thinking about it, which blocks of code need to be used to apply design effect X or positioning area Y, then it’s time to jump into cutting up the code into discrete pieces, be it include files or CMS templates and folding dynamic code around elements to really make the template come alive.
It pays to go slowly at first so that any mistakes are caught early and you’re sure that no stray lines have made their way into your pages or that that loop there got properly closed, so that when you’re applying everything within the CMS later, there’s few or no surprise error messages with arcane references to a variable on line 367 that you remember looking at, but can’t place in context right away.
Long story short, preparation, preparation, preparation and deliberation up front can actually pay off in a shorter turnaround time over all and save a hard-working developer from a serious case of monitor eyes.