Divi and Sticky Menu bars

I was recruited to fix a CSS problem caused by another developer, for the site https://www.magueymelate.com/. The owner graciously let me write about the experience.

The goal: Put a sticky bar on top of the site, for very specific pages.

See the Opt-in on top? It travels with you until you close it. That’s the sticky bar.

The Process

Goal:

Build a sticky banner for opt-ins for 4 specific pages

Fix:

What the previous developer did

What did the previous developer break?

  • The opt-in form wasn’t working
  • The design code wasn’t responsive
  • The opt-in appeared on every page
  • The color scheme didn’t align with what the client wanted.

How to do this

So how do you go about doing this? Here’s the system I followed.

Step 1:

Look at old prior code using DevTools.
Within the dev tools, you’ll have to do a bit of detective work, looking at what the styles/classes & IDs are that are causing the design.

Note: If the code also has some functionality, you may have to dig into the JS code as well. This is significantly more painful and often not something I prefer doing. To dig into the JS code, open up the Sources Tab, do a refresh, and manually read through all the JS scripts until you find the culprit.

Knowing this will help you understand if you should salvage the code or rebuilt it from scratch.

Step 2:

Finding the prior code from the previous developer.
I decided to keep some of the code. There’s still things I need to remove, so my next step is finding their code.

Within WordPress, there’s a few places where code can hide.

  • Within Appearance > Themes
    Usually function.php, styles.css, etc
  • In Appearance > Customize
    WordPress decided that users may want to put CSS code here instead.
  • In a plugin
    A good developer will isolate their code from affecting others.
    So if the client decides they hate the Sticky bar now, they can turn it off.
  • In a plugin’s settings:
    Divi has a spot to put in CSS/JS code too. If I wasn’t super familiar with Divi, I wouldn’t have known that.
  • Hard-coded in the body
    You’ll know if it’s hardcoded if it’s in the HTML, while you’re searching in the DevTools.
    Rarely do developers hard-code the design (unless it’s for a workaround). Fortunately, it’s a easy fix.

Step 3

Identifying the fix

The previous developer wrote the sticky bar CSS code, that I wanted to modify and re-use. Why re-invent the wheel?

But in the process, I discovered their method of creating opt-ins was to use the default HTML code that came directly from the client’s email marketing platform. That default HTML code had it’s own problems, and I wanted to avoid using it.

Step 4

Deploy a fix and call it a day.

The first thing I did was isolate my updates and share it with the client.

Most WordPress clients do not have a staging site. And for a quick-fix situation, it’ll be overkill to dump their site, create a version in local, get it approved, and import the code over. The next best thing is to simply create a new page.

I created my own version by creating Page > New Page, then hiding it so only logged in users can see it.

I wrote my code on that page, just to get a prototype, and got the client approval.

For round 2, I cleaned up a lot of the design code, and used GravityForms as the form software. I really love GravityForms, as it uses a lot of classes/ unique IDs that you can easily target with CSS.

It works, the client loved it, and now it’s time to deploy!

Except it didn’t work.


Unforeseen consequences:

I broke one of the most basic rules of development — always develop in the same environment.

This isn’t a “Oh no, my code works on Chrome but not Firefox” or “I should have used a Linux server running PHP 5.4, not a Windows server running PHP 7!” (Which are all valid issues I had prior.)

The client’s site was built in Divi. I built my sticky bar on a WordPress Page.

What is Divi?

Divi is a site builder for WordPress. It’s one of the best builders out there. I’ve been a huge fan from 2013-2017.
As I got deeper into WP development, I recognize it’s faults. it’s a headache for developers. It creates a lot of “Divi Overhead”, using their own custom code to make the magic happen. (I now recommend BeaverBuilder.)
For example: If you turn your divi code into the HTML mode, you’ll see the mess that Divi left.
Beaver Builder is generating clean HTML, so anyone can modify.

What I didn’t know was that Divi wraps your code in THEIR own code. The original CSS couldn’t work around it.

As a workaround – the original developer had injected code directly into header.php. I thought it was a weird move. But now i understand that they did that to bypass Divi.

<!-- RK Sticky bar --> 
<?php 

	if( is_page(array('club', 7538, 2432, 'signaturebox'))) {
	?>	
    <div class="sticky-bar-form">
			<div class="grid-container">
				<div class="sticky-space1"></div>
				<div id="sticky-close" class="sticky-space2">X</div>
				<div class="sticky-bar"> <?php echo do_shortcode('[ gravityform id="x" title="false" description="false" ]') ?> </div>
			</div>
		</div>

		<script type="text/javascript">
			const stickyClose = document.querySelector('#sticky-close');
			const stickyBarForm = document.querySelector('.sticky-bar-form');
			const mainHeader = document.querySelector('#main-header');
			
			//mainHeader.style.marginTop = "32px"	
				
			stickyClose.addEventListener('click', function(event) {
			  if (stickyBarForm.style.display == "") {
				stickyBarForm.style.display = "none"
				mainHeader.style.marginTop = "0px"  
			  }});

		</script>
	<?php 
	} 

?>	

I moved my code to the header.php, and it worked!

Leave a Comment