This is some of the coding work and thoughts I looked at today. If you’re interested in WooCommerce Membership Sites [email me](

## Should You Refactor old SCSS or Nuke and Pave

Been working on a site for about 9 years and we’ve done a bit of nuke and pave, but mostly just kept working with existing code for our styles. That means there is often a bunch of things spread all around that need to get changed, and then we find one more thing that needs fixing.

For devs, it often appeals to nuke old code and write new stuff from scratch. You get to simply stop dealing with technical debt that has annoyed you for a while. The problem is that you’re going to introduce a bunch more problems that you won’t see until you’re done rebuilding. There are edge cases that you solved in the earlier version of the project that are going to come back.

For eCommerce sites this is especially important because you’ve worked on improving your conversion and any change to your design is going to affect conversion rates. I think a better approach to nuke and pave is to progressively refactor. Maybe start by moving the Sass to 7-1 structure (outlined below) and then tackle the front page to move it to flexbox and css grid while A/B testing any layout changes you’re going to make. When you’re happy with the frontpage move on to the next part of the site, like the header. A slow and steady change over to new technology without throwing out what is working in the older site design is a way safer way to work with your client’s business than nuking their site to “fix” it without thinking about how it may affect their conversions.

If you’re working with server side code, then start with writing Unit Tests to verify any functionality you’re going to work on. Then start refactoring and make sure your unit tests keep passing. Anything less is playing fast and loose with your client’s income.

I’ve been refactoring PHP based WordPress code after building 9 plugins for a client over 2 years. Some functionality is shared, but we didn’t know it at the time. I ended up rewriting things because functionality was buried in a single plugin and I forgot about a method. We’re moving to extract that functionality now so that we can not have duplicated code. This starts with writing tests across the existing code.

## Research

**[Structuring your Sass Projects](**
– introduced me to the 7-1 pattern for layout of Sass projects. The 7 areas below are imported into _main.scss_ (or whatever)
1. **Abstracts**: holds helpers, functions, mixins, config files, variables. Anything in here is used in other spots and they aren’t themselves compiled into your CSS
2. **Base**: resets, typography, the boilerplate code for your project
3. **Components**: styles for buttons, carousels, sliders. Probably a bunch of these files
4. **Layout**: the styles for the parts of your site, like _header.scss or _forms.scss
5. **Pages**: styles specific to individual vidual pages, like _frontpage.scss for the front of your site
6. **Themes**: not used by most projects but it would be the light vs dark theme or other colour themes for your projec8t
7. **Vendors**: third party code from external libraries

**[Progressively Enhanced CSS Layouts](**
– looking forward to no more floats and moving to flexbox and css grid

**[Refactoring Techniques](**
– huge resource on ways to refactor your code

Looked at sanitizing a phone number as user meta, but it appears that the best/only way to do this is to use [sanitize_text_field](