DateBook 5.0.6 – Multilingual Feature-Rich Dating WP Theme

I picked up DateBook for a small regional dating site that had been running on some ancient BuddyPress mess since 2017. The client wanted multilingual profiles, paid membership, better search filters, and “something modern but not Tinder-ish.” Yeah, that sentence already made me tired.

The first install of DateBook was surprisingly painless. Demo import worked from Appearance -> Import Demo Data, and the front page looked almost identical to the preview. That part I liked. No hour-long ritual of missing widgets, broken sliders, and “please install 19 plugins or die.”

Setup: Nice Until You Open DevTools

Most visible stuff is editable from the admin. Colors, logo, header style, profile card layout, and some typography live under Theme Panel -> General Settings and Theme Panel -> Typography. Homepage blocks were built with Elementor in my setup, so changing the hero section and featured members grid was not painful.

But then I opened Chrome DevTools, Network tab, and saw DateBook loading multiple font weights I never asked for: 300, 400, 500, 600, 700, plus two icon fonts. Why? For a dating homepage with ten cards and a search form? Come on.

I killed half of that by disabling Google Fonts in Theme Panel -> Typography and enqueueing my own local font in functions.php:

wp_enqueue_style('local-inter', get_stylesheet_directory_uri() . '/fonts/inter.css', [], '1.0');

Not elegant. But it stopped the page from behaving like it was downloading a small Netflix episode.

What DateBook Gets Right

The member search is actually decent. Filters for gender, age, city, and profile interests worked without me rewriting half the query. I expected chaos there, but DateBook uses pretty clean meta queries for profile data.

The multilingual side was also better than expected. WPML picked up most strings, and profile labels were manageable through WPML -> String Translation. I had to manually register a couple of theme strings from inc/class-theme-setup.php, but nothing insane.

Demo data import being available out of the box was a lifesaver. For a client who cannot imagine a layout until every avatar slot is filled, DateBook saved me two boring hours of fake profile creation.

The Stuff That Made Me Swear

The mobile menu. Dear lord. On my staging site, the hamburger opened fine once, then refused to close after JS optimization. Console showed:

Uncaught TypeError: Cannot read properties of undefined

The problem was the theme script depending on jQuery timing like it was still 2012. If I delayed JS in WP Rocket, DateBook broke the menu and the login popup.

My fix was ugly but stable: in WP Rocket -> File Optimization, I excluded:

/jquery-?[0-9.]*(.min|.slim|.slim.min)?.js
/assets/js/theme.js
/assets/js/members-filter.js

Also, I stopped deferring the datebook-main handle in my child theme:

add_filter('script_loader_tag', function($tag, $handle) {
    if ($handle === 'datebook-main') return str_replace(' defer', '', $tag);
    return $tag;
}, 10, 2);

Would I prefer the theme not to rely on fragile script order? Obviously. But here we are.

Builder vs PHP: Know the Border

You can safely change homepage sections, buttons, hero text, and most CTA blocks in Elementor. Header spacing, colors, logo, and footer columns are fine inside Theme Panel and Appearance -> Widgets.

But profile cards are not really builder-friendly. I had to edit the child theme copy of:
code
The “online now” badge markup was hardcoded in the card template. Same with some profile meta output. What were they thinking? That every dating site in the universe wants the exact same age/location layout?

For deeper setup, inc/class-theme-setup.php controls image sizes, menus, and theme supports. Don’t edit the parent file unless you enjoy losing work during updates. Hook it from the child theme or override templates properly.

Performance Notes From My Build

The DOM was heavier than I wanted. The members archive page had too many nested wrappers around every profile card. Not fatal, just annoying.

On a mid-range VPS, DateBook was acceptable after object caching and asset cleanup. Without cleanup, the members listing felt sticky on mobile. I removed unused Elementor widgets from pages where they were not needed and disabled extra icon packs in Elementor settings.

The biggest win was reducing profile images. Not “optimize images” as a lazy slogan — I changed the card thumbnail size in functions.php to match the actual display size:
add_image_size('member-card-small', 360, 420, true);

Then I updated the card template to call that size instead of loading oversized uploads. That alone dropped the listing page weight hard.

GNU GPL and Updates

The package I worked with is 100% compliant with the GNU GPL. No license keys are needed in principle, and the premium functionality, including demo data import, is available out of the box. Unlimited Website Usage also means I can use DateBook across client installs without domain limits.

The tradeoff is updates. Since there is no key-based dashboard flow, I install updates manually. My usual routine: clone staging, upload the new zip via Appearance -> Themes -> Add New -> Upload Theme, check template overrides in the child theme, then deploy. For bigger client sites, I use FTP and replace only the parent theme folder after a backup.

Annoying Questions I Actually Had

Why does the login popup break after caching?

Because delayed jQuery messes with the theme modal script. Exclude jquery-core and datebook-main from delay/defer.

Can I redesign profile cards in Elementor?

Not properly. Override template-parts/profile-card.php in a child theme and do it there.

Does DateBook play nicely with WPML?

Mostly yes. Some theme strings need manual registration from inc/class-theme-setup.php.

Why is the members page slow on mobile?

Too much DOM plus large profile thumbnails. Add a smaller image size and force the card template to use it.