Content warning: we’ll use some CSS, PHP, and Front-End Web Developer jargon. Some non-developers may need coffee before reading this post. You have been warned!!
I use Claude every day. Not in the way some people mean when they say that — a quick synonym lookup or a recipe suggestion. I mean hours at a time, deep in a problem, going back and forth across multiple sessions on the same project.
I build websites and alot of what I work on sits at the edge between development and marketing — custom WordPress plugins, Elementor integrations, code that talks to external APIs. It’s the kind of work where you spend a lot of time reading documentation and hunting down why something that should work doesn’t.
This is an honest account of what a day actually looks like. The good bits and the frustrating bits. No tidy narrative where everything works on the first try.
How a session usually starts
I tend to come in with something specific. Not ‘help me build a plugin’ — that goes nowhere useful. More like: ‘I have a WordPress plugin that pulls session data from an external API. I need an Elementor widget that renders a timetable from that data and links each row to the booking flow.’ That level of specificity matters.
A decent starting prompt for something like that looks roughly like this:
I want to build an Elementor widget that pulls from our API plugin so I can put the trial timetable into an Elementor page but can link to the rest of the plugin pages for the rest of the booking process.
Claude will often ask clarifying questions before writing anything — what does the plugin expose (REST endpoint, PHP functions, shortcodes), how should the booking link work, what data needs to display. That back-and-forth is worth doing rather than skipping. The output when you front-load context is meaningfully better than when you just ask and see what comes back.
The plugin created from that prompt worked great, as is often the case when creating w a new widget. Claude is great as creating eclosed pieces of new work very quickly.
I installed the new widget, and it was working within an hour for something that had taken me a day to build and test in the past. The Elemenor API is open on the web, and I fed Claude the code it needed to work with the custom api I was working with.
Now I have a thorough picture of the plugin. Let me also quickly check the bookingform.php for the URL params it expects:
Check bookingform URL parameter handling
Check bookingform URL parameter handling
I have everything I need. Now I’ll build the Elementor widget.
Now I have the complete picture. Let me build the widget:
What actually happens in the middle
Here is where I want to be honest: it rarely works cleanly when dealing with existing code and more complex systems.
Later that same day …
I was working on diagnosing a conflict — an API plugin that uses Bootstrap 3 was breaking the Elementor header and footer on dynamic php template that pulled dat directly from a api . The menu was losing styling and animation, type was rendering at 62.5% of the right size, and footer links were misaligned. Classic case of a legacy plugin loading global CSS resets that clobber a more modern setup.
The first thing I did was fetch the page source and the plugin files and drop them into context. Then asked Claude to diagnose it. The initial read was correct in principle — Bootstrap 3 sets html { font-size: 10px } as a base reset, which breaks every rem value Elementor uses — but the first proposed fix was too blunt. It suggested scoping Bootstrap via @import inside a style block, which doesn’t work: @import ignores the surrounding scope.
That is a pretty normal session. Not dramatic. Just methodical. As I warned you at the start, standard, tedious, from-the-inside-out Front-end web developer stuff. (I joke I enjoy it most of the time )
Example Claude Output
There it is. There are multiple smoking guns in style.css:
body { font: 13px/1.22 arial, helvetica, clean, sans-serif; }
h1 { font-size: 138.5% }
h2 { font-size: 123.1% }
h1, h2, h3, h4, h5, h6 { font-size: 100%; font-weight: normal }
ol, ul { list-style: none }These are all unscoped global resets. The scope wrapper div only protects against Bootstrap — style.css is a separate stylesheet that still applies globally. The real fix is to add a scoped override stylesheet to the tkd theme. This is the cleanest approach: don’t touch style.css (it’s needed for the … content), instead add a stylesheet that fires after it and undoes its damage to Elementor elements outside the scope wrapper.
Find all global element resets in style.css that could affect Elementor
Find all global element resets in style.css that could affect Elementor
I have everything I need. The problem is clear — style.css has bare body, h1–h6, ul, ol, and li resets with no scope that clobber Elementor’s header, nav and footer typography globally. The right fix is a small override stylesheet that restores Elementor’s values outside the content area. I’ll add it as a new file loaded after style.css.
Read the full reset block in style.css to catch everything that needs undoing
Read the full reset block in style.css to catch everything that needs undoing
Now I have the full picture. I’ll create the override stylesheet and update nestapi.php to load it.
Unfortunately, the first 3 solutions did not work. Claude’s response to this was walk me through more debugging.
Example output and instructions from Claude
I need to see the actual rendered HTML source — let me fetch it differently to get the <head> and stylesheet load order.
The markdown fetch strips the <head> — I need the raw HTML to see what stylesheets are actually loading and in what order.
I can’t get the raw <head> HTML through the fetch tool — I need you to grab it directly. But I can already tell what’s happening from the plugin code and the symptoms. Let me be direct about the real diagnosis.
Quick diagnosis checklist for you
- Open the page, right-click → Inspect → look at the
<head>— if you seebootstrap-3.3.7.min.cssloading before Elementor’s stylesheets, that’s the conflict confirmed. - Temporarily disable the API plugin and reload — if the header/footer looks correct on any other page, Bootstrap is the culprit.
- Check if the issue is only on
locationCPT pages — if it also appears on taxonomy pages … thenstyle.cssis the wider problem.
The Bootstrap 3 conflict (Fix 1) is the most likely cause and takes about 5 minutes to implement.
I pasted the actual rendered page source, which showed the stylesheets loading in the wrong order and confirmed the font-size on the HTML element in the Computed tab. Claude spotted it : Bootstrap’s own html { font-size: 10px } rule was the root cause, not just a cascade issue, but getting it in the right place to deal with WordPress enqueuing order of stylesheets for plugin theme and Elementor was trickier
The fix that worked was adding a small inline style block immediately after Bootstrap’s link tag that resets HTML back to 16px and re-applies the 10px base only inside the content scope. Two lines of CSS, but it took about six iterations and sharing the inspector output to land on them and get them in the right place to deal with enqueuing conflicting multiple CSS files. The bane of any WordPress developer who deals with WordPress theme and plugin files is that they do not all speak to each other correctly. I could, and have gone through this process without Claude, but not at the same speed.
Where it saves the most time
The thing I use Claude for most is work that used to require switching context constantly — reading API docs, cross-referencing against existing code, writing boilerplate I know the shape of but would take twenty minutes to type correctly. Having all of that in one place, with context that carries across a session, is the actual time saving.
I also use it for CSS scoping problems. Specifically, situations where a legacy stylesheet has bare element selectors (body, h1-h6, ul, ol) that override everything downstream. I’ll paste the stylesheet and ask Claude to rewrite every rule prefixed with a scope class. It ran a proper CSS parser across a 4000-line file — handling @media blocks, skipping @keyframes, converting html and body selectors to the scope class — in about thirty seconds. That would have been two hours of careful find-and-replace.
The honest version
Claude doesn’t replace knowing what you’re doing. It makes it faster, and it handles the tedious but not intellectually difficult parts — boilerplate, pattern repetition, reading and summarising documentation, catching things you’ve overlooked.
The sessions that work well are the ones where I come in with a clear problem, share the actual evidence (code, inspector output, page source, error messages), and stay in the loop rather than walking away and hoping the output is correct. The ones that don’t are when I’m vague, or when I let it run too far without checking.
It’s a tool. A good one. But the thinking still has to happen on your end.
