I’ve used Code Modules successfully in Gatsby projects packaged using Webpack. The Sample Website uses Parcel to build the site. But Code Modules also works fine with sites built using Grunt or Gulp. Of course, Code Modules work fine with an all BBEdit workflow. When you see the string #COMPANY# on your web page, it’s pretty clear what caused the error. If a particular variable has not been defined, BBEdit just keeps the variable name itself - i.e. Those variables need to be carried over from one site to another. The promise of the called module needs to be satisfied in the new website.Īlso, modules often use variables declared in the Page module’s entry.shtml file. If a module depends upon another module - it calls it - then reusability gets more complex. If a reused module manages the social media links, for example, the links themselves ( items/), the markup ( types/), and the order ( lists/) will have to be changed, but those changes are quite easy once the new markup structure is known. While the data for each website is unique, often a module can be modified for reuse on another site. I often scrape and copy that path and then, still in the terminal, open that file in BBEdit and adjust the target string: bbedit markup/social/items/twitter.shtml. Ag returns the relative path of the file containing the string together with the line containing it. Start in the app/modules/ root to speed up the search. (Quotes can be eliminated for simple strings with no spaces.) ag '#COMPANY#' to find a variable or ag -i 'click button to continue' to find a case-insensitive string. It is invoked on the command line using ag - e.g. I also particularly like “The Silver Searcher” ( GitHub) based on “ack”. BBEdit provides a very good search and replace feature which can be limited to just search the modules folder. Perhaps all you want to do is change a string somewhere and you don’t want to have to follow the chain of includes in order to find it.
Navigating through the modules and their internal files can sometimes be a pain.
This approach provides confidence that refactoring a module hasn’t broken the website.
BBEDIT COMPARE FILES UPDATE
Similarly, if you’re using Git on a committed repo, you can update the entire site and then use git status to see if any files have changed. If the files aren’t, you can see what needs to be fixed. If the files are identical, then nothing you’ve done has broken the module for that page. Update the high-level page and compare it with the copy, using BBEdit’s compare two front windows tool. One useful trick is to copy the source code for a high-level HTML page into an unsaved separate file.