Adding One Little Field (That Wasn’t So Little)
W were recently asked to add a single new section to one lawyer’s bio page on a client’s website. Easy, right? It should’ve been a fifteen-minute task. But if you’ve ever pulled on a thread thinking it was nothing, only to watch your sweater unravel slowly in your hands — yeah, it was kind of like that.
The client in question was Paine Edmonds Laywers, a Vancouver-based law firm. Their site, built on Wix, uses a dynamic page template powered by a collection of lawyer profiles. Each profile includes all the usual suspects: name, photo, contact info, a professional intro, areas of practice, education, activities, and a few personal notes.
The request? Add one more detail: Selected Cases.
Simple enough—until we took a closer look at how the site was built.
Quick Context: What Are Wix Collections and Dynamic Pages
Before we dive into the twisty part of the story, let’s pause for some context.
In Wix, Collections are like spreadsheets stored in your site’s CMS. Each row represents a content item (like a lawyer), and each column represents a piece of data about that item (like their name or education).
Dynamic Pages take that data and display it in templated layouts. One template can create unique pages for each collection item:
- Dynamic list pages show multiple items (like a team directory)
- Dynamic item pages show individual entries (lawyer profiles)
So if you’ve got 10 lawyers in your “Lawyers” collection, Wix will automatically generate 10 unique profile pages using a single template. It’s powerful, efficient, and usually pretty smooth… until you want to make a change that doesn’t follow the standard format.
When One Field Becomes Everyone’s Field
Here’s where things got tricky.
We assumed, as many people would, that there’d be a simple checkbox somewhere in the Wix Studio Editor. Something like “only show this field when there’s content.” That would make sense, right?
But the reality is a little less magical: Wix shows all connected fields on dynamic pages, even when they’re empty.
That means when we connected the new Selected Cases field to the lawyer bio template, it didn’t just show up for the one lawyer who had content — it showed up on every lawyer’s page, blank and awkward, like a party guest who arrived before the hosts were ready.
Which wouldn’t be so bad, except most of the lawyers didn’t have selected cases to show. And naturally they didn’t want an empty section floating there like a to-do list they hadn’t gotten around to.
So now we had a new problem to solve: How do we show a field on just one page of a dynamic template — without showing it everywhere else?
The Fix (a.k.a. The “Let’s Just Make This Work” Approach)
When you’re working under a tight deadline, elegance sometimes takes a back seat to “functional and effective.”
Here’s the thing: Wix lets you connect a field from your CMS collection to any element on a dynamic page. That’s great. But what’s missing is a simple checkbox in the visual editor, something along the lines of “Only show this element if the field has content.”
That feature doesn’t exist (yet), which means developers are often left to fill the gap themselves.
One robust approach is to build a toggle field system — add a separate Boolean field (like showSelectedCases) to your collection for each optional field. Then you can train content editors to toggle visibility directly. For larger sites or more complex needs, this gives content managers more control and avoids relying on client-side checks.
But in this case, the priority was simplicity.
So we settled for the magic of Javascript: a short script using Wix Velo that checks if the field is empty, and hides or shows elements accordingly. Here’s how we implemented it (we’ll talk about the whys after this):
```html
$w.onReady(function () {
// Set default state: hide both the heading and the content
$w('#selectedCasesHeading').collapse();
$w('#selectedCasesContent').collapse();
// Wait briefly before accessing the dynamic dataset
setTimeout(() => {
try {
const currentItem = $w('#lawyerDataset').getCurrentItem();
// Check if the selectedCases field has any content
if (currentItem && currentItem.selectedCases && currentItem.selectedCases.trim() !== "") {
$w('#selectedCasesHeading').expand();
$w('#selectedCasesContent').expand();
}
// No content? Elements stay hidden (default state)
} catch (error) {
console.log("Error accessing selected cases content:", error);
// Fail silently – elements remain collapsed
}
}, 500);
});
```
Is it the most scalable solution? No. Is it lightweight and effective for a single field in a real-world project? Absolutely. And sometimes, that’s the win you need.
Technical Gotchas
If you’re working with Wix dynamic pages and Velo, here are a few things we learned the hard way — so you don’t have to.
Dataset IDs Are Case-Sensitive
The most common mistake is guessing the dataset ID. You might assume it’s something like #dataset1, but if you renamed it or added more than one, that guess will fail silently. Always check the Dataset panel in the Editor for the exact name, as it’s case-sensitive.
“Anchor Names” Are Actually Element IDs
Wix refers to element IDs as “anchor names,” which can be confusing. To find or change one, select the element, open the Properties Panel, and give it a clear, descriptive ID like #selectedCasesContent. It’ll make your code easier to read and debug later.
Timing Is Everything
Just because your code runs inside $w.onReady() doesn’t mean your dataset is ready too. Instead of guessing with a delay, the more reliable approach is to use the dataset’s own .onReady() method, as it ensures your data is actually loaded before you try to use it.
What We Learned
This project was a great reminder that “easy” changes in CMS-driven sites aren’t always easy under the hood.
Working within Wix’s dynamic page structure offers a ton of power and efficiency, but also a few quirks. There’s no built-in logic for “only show this if there’s content,” so you’re left deciding between quick scripts or more scalable data-model solutions. And sometimes a clever workaround wins the day.
It also reinforced something we often discuss with clients: When planning structured content, it’s as much about considering edge cases and conditional logic as it is about the base data structure itself. Even one “well, there’s only one place that needs this” can perhaps point to building something in an entirely different way — otherwise, the consequences can ripple across an entire site.
At the end of the day, we delivered a solution that was clear, functional, and invisible to users. A win is a win.
Have you encountered similar challenges with Wix dynamic pages? Reach out to us if you need help implementing conditional content on your site.
