DEV Community: nEka

How to Build a Powerful WordPress Directory with Custom Fields and Advanced Search

nEka — Wed, 03 Sep 2025 20:32:52 +0000

WordPress is not just for blogging. With the right combination of plugins and custom code, you can turn it into a powerful platform for almost any kind of data-driven website, including a searchable directory.

For a recent project, universal-languages.fr, we needed to build a comprehensive directory of language schools, allowing users to search by location and keywords. In this tutorial, I'll walk you through the exact process of how to build a similar directory from the ground up.

The Tech Stack

We'll use a combination of powerful and flexible plugins to achieve our goal with minimal hassle.

Custom Post Type UI (CPT UI): To create a dedicated "Language School" post type, separating our listings from standard blog posts.
Advanced Custom Fields (ACF): To add custom data fields to our directory items (e.g., address, website, phone number).
WP Ultimate CSV Importer: To bulk-import data into our directory, saving hours of manual entry.
Relevanssi: To supercharge the default WordPress search, making it faster and capable of searching through our custom fields.

Step 1: Create the Custom Post Type

First, we need a place to store our directory listings. Installing CPT UI allows us to do this without writing any register_post_type code.

Install and activate the CPT UI plugin.
Navigate to CPT UI > Add/Edit Post Types.
Create a new post type. We'll call it "Language School". For the slug, our real-world project uses centre-formation (French for "training center").
Fill in the labels as needed (Plural, Singular, etc.).
Under "Supports", make sure Title, Editor, and Custom Fields are checked.
Save the post type.

You now have a new "Language Schools" menu in your WordPress admin!

We also need a way to categorize our schools, for example, by city. For this, we use a custom taxonomy.

Go to CPT UI > Add/Edit Taxonomies.
Create a new taxonomy called "City" (ville).
Attach it to our "Language School" post type.
Save the taxonomy.

Step 2: Define Custom Fields with ACF

A directory listing is more than just a title and description. We need fields for structured data. This is where ACF shines.

Install and activate Advanced Custom Fields.
Go to Custom Fields > Add New.
Create a Field Group named "School Details".
Set the rule to show this field group if Post Type is equal to Language School.
Add your fields. For a school directory, you might add:
- address (Text)
- phone_number (Text)
- website_url (Url)
- email_address (Email)

Now, when you edit a "Language School" post, you'll see these fields ready for input.

Step 3: Displaying a Single Directory Item

To display a single listing, WordPress looks for a template file named single-{post_type_slug}.php. In our case, this is single-centre-formation.php.

Create this file in your child theme's folder and add the following code. It's a standard WordPress loop, but we use ACF's get_field() function to display our custom data.

<?php get_header(); ?>

<div id="primary" class="content-area">
    <main id="main" class="site-main">

    <?php
    while ( have_posts() ) :
        the_post();
        ?>

        <article id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
            <header class="entry-header">
                <?php the_title( '<h1 class="entry-title">', '</h1>' ); ?>
            </header>

            <div class="entry-content">
                <h3>Details</h3>
                <p><strong>Address:</strong> <?php echo esc_html( get_field('address') ); ?></p>
                <p><strong>Phone:</strong> <?php echo esc_html( get_field('phone_number') ); ?></p>
                <p><strong>Website:</strong> <a href="<?php echo esc_url( get_field('website_url') ); ?>" target="_blank">Visit Website</a></p>

                <hr>

                <?php the_content(); // This displays the main description from the WordPress editor ?>
            </div>
        </article>

    <?php endwhile; // End of the loop. ?>

    </main><!-- #main -->
</div><!-- #primary -->

<?php get_footer(); ?>

Step 4: Building the Search Page and Logic

This is the core of our directory. We'll create a custom page template for the search form and a shortcode to process the search and display results.

1. The Search Page Template (search_centres_page.php)

Create a file named search_centres_page.php in your child theme with the following content. This template will hold our search form.

<?php
/*
Template Name: School Search Page
*/
get_header();
?>

<div class="container">
    <h1>Find a Language School</h1>

    <form role="search" method="get" class="search-form" action="<?php echo esc_url( home_url( '/' ) ); ?>">
        <input type="hidden" name="post_type" value="centre-formation" />

        <label>
            <span class="screen-reader-text">Search for:</span>
            <input type="search" class="search-field" placeholder="Search by keyword..." value="<?php echo get_search_query(); ?>" name="s" />
        </label>

        <?php
        // Dropdown for our "City" taxonomy
        wp_dropdown_categories( array(
            'taxonomy'         => 'ville',
            'name'             => 'ville',
            'show_option_all'  => 'All Cities',
            'value_field'      => 'slug',
            'hierarchical'     => true,
            'selected'         => get_query_var('ville'),
        ) );
        ?>

        <input type="submit" class="search-submit" value="Search" />
    </form>

    <div class="search-results">
        <?php echo do_shortcode('[centre_search_results]'); ?>
    </div>
</div>

<?php get_footer(); ?>

Now, create a new page in WordPress and assign it the "School Search Page" template.

2. The Shortcode for Displaying Results

Add the following code to your child theme's functions.php file. This code creates a shortcode [centre_search_results] that runs a WP_Query based on the URL parameters from our form.

function centre_search_results_shortcode() {
    $paged = ( get_query_var( 'paged' ) ) ? get_query_var( 'paged' ) : 1;
    $search_query = get_search_query();
    $city_filter = isset($_GET['ville']) ? sanitize_text_field($_GET['ville']) : '';

    $args = array(
        'post_type'      => 'centre-formation',
        'posts_per_page' => 10,
        'paged'          => $paged,
        's'              => $search_query,
    );

    // If a city is selected, add a taxonomy query
    if ( !empty($city_filter) ) {
        $args['tax_query'] = array(
            array(
                'taxonomy' => 'ville',
                'field'    => 'slug',
                'terms'    => $city_filter,
            ),
        );
    }

    $query = new WP_Query( $args );

    ob_start();

    if ( $query->have_posts() ) {
        echo '<div class="directory-listings">';
        while ( $query->have_posts() ) {
            $query->the_post();
            // Simple result display
            echo '<div class="listing-item">';
            echo '<h2><a href="' . get_permalink() . '">' . get_the_title() . '</a></h2>';
            echo '<p>' . esc_html(get_field('address')) . '</p>';
            echo '</div>';
        }
        echo '</div>';

        // Pagination
        echo paginate_links(array(
            'total' => $query->max_num_pages
        ));

    } else {
        echo '<p>No schools found matching your criteria.</p>';
    }

    wp_reset_postdata();

    return ob_get_clean();
}
add_shortcode( 'centre_search_results', 'centre_search_results_shortcode' );

Why Relevanssi?
By default, WordPress search is limited. By installing and activating Relevanssi, it automatically replaces the standard search. Configure it to index your centre-formation post type and its custom fields. Now, when a user types a keyword, Relevanssi will look inside the address, description, and other ACF fields, providing much more accurate results.

Step 5: Bulk Import Your Data

Manually adding hundreds of listings is not practical. This is where WP Ultimate CSV Importer comes in.

Prepare a CSV file where the column headers match your ACF field names (e.g., address, phone_number).
In the WordPress admin, go to the importer plugin's page.
Upload your file and map the CSV columns to the corresponding WordPress fields (post title, content, and your custom fields).
Run the importer.

Conclusion

And there you have it! By combining the power of CPT UI, ACF, and Relevanssi, you can create a robust, searchable directory that is both easy to manage and powerful for the end-user. The final step is to add your own CSS to style.css to make it look great. This modular approach is highly flexible and serves as a fantastic foundation for even more complex directory projects.

Slash Your Firebase Costs: A Real-World Guide to Caching in Next.js

nEka — Wed, 03 Sep 2025 20:13:46 +0000

The Dream: A Data-Rich Dashboard

Every developer loves a data-rich dashboard. For our fitness tracking application, GymLog, we wanted to give users a comprehensive overview of their progress. This meant creating a dashboard with multiple stat cards:

Total Sessions
Personal Records
Volume Lifted
Most Frequent Exercises
Activity Heatmaps

It looked great, but under the hood, it had a costly secret.

The Problem: When "Real-Time" Gets "Real Expensive"

Our backend is Firebase, and our data lives in Firestore. Each one of those statistic cards on the dashboard required one or more queries to Firestore to calculate its value.

A single page load could trigger 10, 15, or even 20 read operations.

For one user, that's fine. But what happens when you have hundreds of users checking their dashboard daily? Or a single user who refreshes the page five times in a minute?

5 refreshes * 20 reads/refresh = 100 reads

The numbers add up alarmingly fast. We were constantly worried about hitting the daily free quota limits on Firestore, which would either shut down our app's data flow or start running up a serious bill. The data doesn't change that often—a user's "most frequent exercise" is unlikely to change from one minute to the next. Hitting the database on every single page view was incredibly inefficient.

The Solution: Next.js App Router Caching

This is where the power of the Next.js App Router comes in. By default, Next.js aggressively caches data fetched on the server. This was the perfect solution to our problem.

Instead of having our client-side components fetch data directly (and repeatedly), we moved our data fetching logic to Server Components. The key is to use the native fetch API, which Next.js extends with caching capabilities.

The magic lies in the next.revalidate option. It allows you to implement a "stale-while-revalidate" strategy. Here’s the concept:

The first time a user requests the page, we fetch the data from Firebase and render the page.
Next.js caches the result of that data fetch on the server.
For the next X seconds (our revalidation period), any other user (or the same user refreshing) who requests the page gets the cached data instantly, without ever touching our Firebase backend.
After X seconds have passed, the next request will still get the cached (stale) data, but in the background, Next.js will trigger a new fetch to revalidate and update the cache with fresh data.

This gives us the best of both worlds: blazing-fast page loads and massively reduced database operations.

Putting It Into Practice

Let's look at a simplified version of how we implemented this for a TotalSessionsCard component.

First, we created an internal API route to abstract the Firebase logic. This keeps our Firebase Admin SDK code securely on the server.

src/app/api/stats/total-sessions/route.ts

import { NextResponse } from "next/server";
import { getFirestore } from "firebase-admin/firestore";
import { adminApp } from "@/lib/firebase"; // Your admin app initialization

// This function talks to our database
async function getTotalSessions(userId: string) {
  const db = getFirestore(adminApp);
  const sessionsRef = db.collection(`users/${userId}/sessions`);
  const snapshot = await sessionsRef.count().get();
  return snapshot.data().count;
}

// The API route handler
export async function GET(request: Request) {
  // In a real app, you'd get the userId from the authenticated session
  const userId = "a-sample-user-id"; 

  try {
    const totalSessions = await getTotalSessions(userId);
    return NextResponse.json({ totalSessions });
  } catch (error) {
    return new NextResponse("Internal Server Error", { status: 500 });
  }
}

Now, in our dashboard page (which is a Server Component), we can fetch this data using the special fetch that Next.js provides.

src/app/[locale]/dashboard/page.tsx

import { TotalSessionsCard } from "@/components/TotalSessionsCard";

// This is the data fetching function for our component
async function getDashboardStats() {
  // This URL is internal to our Next.js server
  const res = await fetch(`${process.env.NEXT_PUBLIC_BASE_URL}/api/stats/total-sessions`, {
    next: { 
      revalidate: 3600 // Cache for 1 hour (3600 seconds)
    },
  });

  if (!res.ok) {
    // Handle errors
    return { totalSessions: 0 };
  }

  return res.json();
}


export default async function DashboardPage() {
  const { totalSessions } = await getDashboardStats();

  return (
    <div>
      <h1>My Dashboard</h1>
      <TotalSessionsCard total={totalSessions} />
      {/* ... other stat cards */}
    </div>
  );
}

Look at that next: { revalidate: 3600 } line. That's the entire implementation.

With that one line, we told Next.js: "Fetch this data, but then cache it for an hour." Now, no matter how many times the user refreshes the dashboard within that hour, it will only result in one single read operation against our API, and therefore, only one query to Firestore.

The Results

The impact was immediate and dramatic:

95%+ Reduction in Reads: Our Firestore read operations for the dashboard plummeted.
Faster Page Loads: Subsequent page loads are instantaneous as they are served from the cache.
Cost Savings: Our Firebase bill is now negligible and predictable.
Better User Experience: The dashboard feels snappy and responsive.

This approach has been a game-changer for our project. It allowed us to build the rich, data-heavy experience we envisioned without the fear of runaway costs. If you're building a Next.js app with a backend like Firebase, I highly recommend leveraging the built-in caching. It’s simple, powerful, and incredibly effective.

Happy caching!

WordPress vs Next.js: A Developer's Technical Decision Framework for 2025

nEka — Wed, 03 Sep 2025 19:57:45 +0000

As we navigate the evolving web development landscape in 2025, the choice between WordPress and Next.js continues to spark debates among developers. However, the question isn't really "which is better?" but rather "which is better for this specific project?"

After working with both technologies extensively, I've developed a framework to help developers make this crucial decision based on technical requirements, team capabilities, and project constraints.

The Current State of Both Platforms

WordPress: Evolution, Not Revolution

WordPress has undergone significant changes with Gutenberg blocks, Full Site Editing, and improved performance capabilities. It's no longer just a blogging platform but a comprehensive content management system powering over 40% of the web.

Key WordPress advantages in 2025:

Mature plugin ecosystem with solutions for virtually any requirement
Non-technical user-friendly interface
Strong SEO capabilities out of the box
Extensive hosting options and support community
Cost-effective for standard website needs

Technical limitations to consider:

Plugin dependency can create security vulnerabilities
Performance optimization requires careful configuration
Customization beyond themes often requires PHP knowledge
Scaling can become complex with high traffic volumes

Next.js: The Modern Web App Framework

Next.js has established itself as the go-to React framework for production applications, offering server-side rendering, static site generation, and excellent developer experience.

Next.js strengths:

Superior performance with built-in optimizations
Flexible rendering strategies (SSR, SSG, ISR)
Seamless integration with modern development workflows
Excellent developer experience and debugging tools
Built for scalability from day one

Challenges to address:

Steeper learning curve requiring React/JavaScript expertise
Higher development costs and timeline
Need for technical maintenance and updates
Limited content management capabilities without additional tools

Technical Decision Matrix

Choose WordPress When:

Project Characteristics:

Content-heavy websites (blogs, news sites, corporate websites)
E-commerce with standard requirements (< 10,000 products)
Quick time-to-market requirements (< 8 weeks)
Limited development budget (< $15,000)
Non-technical team will manage content long-term

Technical Requirements:

SEO-focused with regular content updates
Multi-user content management needs
Extensive third-party integrations (payment processors, marketing tools)
Standard web functionality requirements

Example Use Case:
A local business needs a website with service pages, blog, contact forms, and basic e-commerce. WordPress with a quality theme and essential plugins can deliver this efficiently within budget constraints.

Choose Next.js When:

Project Characteristics:

Custom web applications with complex user interactions
Performance-critical applications
Projects requiring custom UI/UX implementations
Long-term development with technical team support
Budget allows for custom development (> $20,000)

Technical Requirements:

Real-time data updates and dynamic content
Complex state management needs
Integration with modern APIs and services
Progressive Web App (PWA) requirements
Custom authentication and user management

Example Use Case:
A SaaS platform requiring user dashboards, real-time analytics, custom workflows, and third-party API integrations. Next.js provides the flexibility and performance needed for this type of application.

The Hybrid Approach: Headless WordPress + Next.js

For projects requiring both robust content management and custom frontend experiences, combining WordPress as a headless CMS with Next.js frontend offers compelling advantages:

Benefits:

Content editors enjoy familiar WordPress interface
Developers get modern React-based frontend flexibility
Excellent performance through static generation
Scalable architecture supporting multiple frontends

Considerations:

Increased complexity in setup and maintenance
Higher development costs (typically 40-60% more than single-platform solutions)
Requires developers familiar with both technologies
More complex deployment and hosting requirements

Making the Technical Decision

Evaluation Framework

When choosing between WordPress and Next.js, consider these technical factors:

Team Expertise: Do you have React developers? Can the team maintain a Next.js application long-term?
Performance Requirements: Are sub-second load times critical? Do you need real-time updates?
Content Management Needs: How frequently will content be updated? Who will manage it?
Integration Requirements: What third-party services need integration? Are there existing APIs to connect?
Scalability Plans: Expected traffic growth? Future feature expansion plans?
Maintenance Capacity: Who will handle updates, security patches, and ongoing development?

Real-World Performance Comparison

Based on recent projects and industry benchmarks:

WordPress Performance Metrics:

Average load time: 2-4 seconds (optimized)
Core Web Vitals: Achievable with proper optimization
Development time: 4-8 weeks for standard sites
Maintenance: 2-4 hours monthly (plugin updates, security)

Next.js Performance Metrics:

Average load time: 0.5-1.5 seconds (optimized)
Core Web Vitals: Excellent scores by default
Development time: 8-16 weeks for custom applications
Maintenance: 4-8 hours monthly (dependencies, security updates)

Cost Analysis Framework

WordPress Total Cost of Ownership:

Initial development: $3,000 - $15,000
Annual maintenance: $1,200 - $3,600
Hosting: $100 - $500 annually
Plugin licenses: $200 - $800 annually

Next.js Total Cost of Ownership:

Initial development: $15,000 - $50,000+
Annual maintenance: $3,000 - $8,000
Hosting: $200 - $2,000 annually
Development tools/services: $500 - $2,000 annually

Future-Proofing Considerations

WordPress Evolution:

Continued block editor improvements
Better performance optimization tools
Enhanced headless CMS capabilities
Growing integration with AI content tools

Next.js Trajectory:

Improved development experience
Better optimization features
Enhanced server components
Tighter Vercel ecosystem integration

Both platforms are actively developed with strong roadmaps, making either choice viable for long-term projects.

Conclusion: Context-Driven Decisions

The WordPress vs Next.js decision should be driven by project requirements, team capabilities, and business constraints rather than technology preferences.

WordPress excels for content-driven sites requiring quick deployment and easy maintenance. Next.js shines for custom applications demanding high performance and complex functionality.

For teams unsure about the right choice, starting with WordPress for MVP validation and later migrating to a headless architecture or full Next.js implementation provides a pragmatic path forward.

The key is matching the technology to the problem you're solving, not choosing based on what's trendy or personally preferred.

For more insights on web development decisions and technical comparisons, check out WebNyxt for in-depth analysis and expert perspectives.

Discussion Questions

What factors have influenced your WordPress vs Next.js decisions? Have you tried the headless approach? Share your experiences in the comments below!