ThemeForest OldStory - WordPress Theme

A Guide to Setting Up ThemeForest OldStory for a Bar, Pub, or Restaurant Website

ThemeForest OldStory is a visual WordPress theme for venues with a strong atmosphere: a whiskey bar, pub, restaurant, tasting room, small distillery, gastropub, or beverage shop. This guide does not repeat the product listing. Instead, it shows how to turn the installed theme into a working website: import the foundation, understand the demo structure, replace the content, configure the menu, events, WooCommerce storefront, forms, blog, responsive behavior, and common issue diagnosis.

The main challenge with OldStory is not clicking Install. The theme is built around Elementor, ThemeREX Addons, custom layouts, color schemes, widget areas, and several additional post types. If you configure them without a clear sequence, the site quickly turns into a beautiful but fragile copy of the demo: the menu points to the wrong pages, service cards display someone else's posts, forms send emails to the wrong address, and the mobile header loads unnecessary elements.

Next, we will walk through the setup as if this were a real client project. First, we will define who the theme is right for, then go through preparation and safe import, and after that configure the homepage, header, footer, menu, services, events, store, forms, blog, and final review. A separate section covers problems, from the wrong ZIP archive to stalled imports and optimization conflicts.

The practical rule is simple: build the site on a staging copy first, then replace the demo data with your own, disable anything unnecessary, review the public-facing site on desktop and mobile, and only then move it to the live domain.

What OldStory Is Designed to Do and How It Differs from a Typical Restaurant Theme

OldStory is not built for a generic business website. It is designed as an atmospheric showcase for a venue where the design needs to sell the mood before a visitor even reads the menu. In the demo, this is clear from the large hero section with a bar scene, poster-style framing, decorative typography, drink cards, about blocks, portfolio, store, blog, and subscription section. This approach is especially useful when visitors are choosing not just food or drinks, but an experience: a tasting, a night out at the bar, a culinary event, a gift, or a bottle purchase.

Unlike a minimalist cafe theme, OldStory comes with several ready-made combinations: a presentation-style homepage, visual drink catalog, events, team pages, blog, WooCommerce storefront, contact forms, maps, social links, and widgets. You are not getting one pretty template, but a set of building blocks that need to be adapted to a real business workflow. That is why setup should start with a site map, not with replacing the first image.

Where OldStory Works Best

The theme is a strong fit for a bar website with bold visual presentation, a restaurant with tasting evenings, a pub with an event lineup, a boutique liquor store, a beverage brand with a blog and portfolio, or a small venue that needs a cohesive site without building a separate design system from scratch. It works especially well when the homepage leads the visitor through a sequence like this: atmosphere - menu - products - events - the venue's story - contact details.

If the project needs a dry catalog without expressive styling, a strict restaurant chain website with dozens of locations, or the lightest possible theme with minimal visual effects, OldStory may be excessive. It includes many built-in styles and dependencies, so the time savings only appear when the setup is handled with discipline. Demo import helps you start faster, but it does not replace content and structure planning.

Signature Mechanics Worth Understanding Up Front

OldStory includes several mechanics that directly affect the final result. The first is the ThemeREX Addons and Elementor combination: demo pages and layouts are edited in the visual builder, while some settings live in the Theme Panel and Appearance > Customize. The second is settings inheritance: global values in the Customizer can be overridden in the page-level Theme Options. The third is separate header and footer layouts, where the logo, menu, burger panel, and sticky behavior may differ from what is configured in the main Customizer.

The fourth mechanic is demo import. A full import creates a copy of the demo with pages, media, theme settings, and plugin settings, but it is primarily meant for a clean installation. A partial import adds the needed pages and structures to an existing site, but it may use placeholders instead of the original images and requires manual reassignment of categories, posts, and widgets. The fifth mechanic is the set of custom post types: Services, Team, Testimonials, Portfolio, and Events, all displayed through ThemeREX Addons and Elementor widgets. If you do not replace them with your own content, the homepage remains a polished showcase of someone else's examples.

Who Should Choose This Theme and Who Should Look for Another Option

OldStory is worth considering if you are willing to build on a ready-made visual style and adapt it to your brand instead of creating everything from scratch. It works well for a bar owner, a restaurant marketer, a webmaster building a client site, or a team that needs events, menus, a blog, and a product showcase inside one WordPress setup. The key advantage is not one standalone feature, but a connected page system: the hero section, menu, offer cards, portfolio, products, subscription, blog, and contact pages already feel like parts of one consistent story.

The theme may not be the right choice if the client wants a completely custom page architecture, a strict corporate design with no decorative typography, or a site built entirely on a block theme with the Site Editor. OldStory's documentation states that the existing demo pages and layouts are built with Elementor, so they need to be edited in Elementor. Gutenberg can be used for new pages and posts, but mixing different editors inside the same page is not a good idea because it increases the risk of broken layouts and unpredictable spacing.

Typical Projects Where the Theme Saves Time

• A whiskey bar or cocktail bar website where atmosphere, menu, gallery, events, and a contact form matter.
• A pub website with an events calendar, blog, and separate pages for the team, kitchen, and drinks.
• A restaurant site with a WooCommerce storefront for gift sets, merchandise, or online orders, if the legal and payment workflows are already planned separately.
• A beverage brand or distillery page where portfolio content, production story, and articles work together.
• A small site for an event, tasting, or tour that needs a strong homepage and clear navigation.

When OldStory Is Not the Best Foundation

If you want nothing more than a super-light landing page without extra plugins, the theme may feel too heavy. If the project already has a large content-rich website, you should not run a full demo install: the documentation clearly warns that a full import replaces existing content. For a live website, a partial import, a staging copy, or manual page building is safer. If the core workflow is table reservations with payments, CRM integration, advanced time slots, and SMS, you will need a dedicated booking solution because OldStory itself is not a reservation management system.

Do not choose the theme based only on the hero section. Check whether the page types actually match your project: menu, events, store, contact pages, blog, team, reviews, and mobile navigation. If you do not need half of those blocks, setup may take more time than it seems.

What to Check Before Installing on WordPress

Before installation, separate three things clearly: the purchase package, the theme archive, and the working WordPress environment. The "missing style.css" error almost never means the theme is broken. It usually happens because someone uploads the full ThemeForest package to WordPress instead of the installable ZIP. That package typically contains the main theme archive, child theme, documentation, and bundled plugins. For installation through the WordPress admin, you need the oldstory.zip archive specifically, not the entire downloaded package.

The second check is server resources. OldStory's documentation recommends confirming in advance that your hosting environment can handle the demo import: increase execution time, memory, POST size, and upload size limits. These values matter most if you want to import demo media files, WooCommerce products, and sliders. If the site is already running on shared hosting with large plugins installed, create a backup first, temporarily disable heavy extensions, and run the import during a low-traffic period.

Minimum Preparation Checklist

1. Create a backup of the database and files if the site already contains content.
2. Confirm that you have the installable theme ZIP and the separate child theme archive.
3. Create a staging copy or a clean test installation if you plan to run a full demo import.
4. Check PHP limits and make sure WordPress can upload a large archive.
5. Decide which plugins are actually needed: Elementor and ThemeREX Addons are critical for the demo, while the rest depend on your use case.
6. Make a list of the pages that should remain after replacing the demo: homepage, menu, events, store, contact page, blog, privacy policy.

The most important preparation is not technical, but editorial. Before importing, gather your own photos, menu section names, business hours, address, phone numbers, social links, legal pages, and form copy. Then after installation you will be replacing content instead of trying to solve design, navigation, and copy at the same time.

Which Plugins to Enable Immediately and Which to Delay

The documentation states that ThemeREX Addons is required for the theme to work correctly, and Elementor is needed to edit demo pages. Enable WooCommerce only if you need a storefront or online shop. The Events Calendar is needed only if you actually publish events. Contact Form 7 is needed for the bundled contact forms if you are not replacing them with another trusted solution. Slider Revolution and Swiper Slider handle slider-based layouts, but before launch you should verify whether a complex slider is really necessary on mobile screens.

Plugins such as Instagram Feed, Mailchimp for WordPress, Advanced Popups, Cookie Information, wishlist tools, or additional payment solutions should be added after the main site structure is already working. The more extensions are active during the first import, the higher the memory load and the harder it becomes to diagnose issues. For a small bar, the theme, ThemeREX Addons, Elementor, a form plugin, events, and WooCommerce only when there is an actual storefront are often enough.

Installation, Child Theme, and Safe Demo Import

Installing OldStory follows the standard WordPress theme process, but the order matters. In the admin panel, open Appearance > Themes, click Add New, then Upload Theme, choose oldstory.zip, install it, and activate the theme. If the upload fails through the admin panel because of file size limits or an expired link, use FTP: extract oldstory.zip and upload the oldstory folder to /wp-content/themes. After activation, WordPress will prompt you to install the required plugins.

If you plan to modify templates, functions, or add CSS beyond the Customizer, activate the child theme before the demo import. OldStory's documentation specifically warns that the child theme should be enabled in advance, otherwise theme options may reset when the active theme changes. This matters especially for projects where header layouts, CSS classes, template files, or custom functions will be edited.

Full Import and Partial Import

A full import is best for a new WordPress installation with no important content yet. It uploads pages, media, theme settings, and plugin settings so the site looks like the demo. That is convenient for a fast start, but dangerous on an existing website: the documentation explicitly says that existing content will be lost and replaced with a new data set. On a live site, that approach is only acceptable after a backup and on a staging copy.

A partial import is safer for an existing website. It adds selected pages and structures, but it does not always pull in the original images and may leave placeholders behind. That is not an error: this mode is designed so you can preserve existing content and replace the demo building blocks with your own images, categories, and posts. After a partial import, be sure to review every Elementor widget that displays content by category or post IDs, because it may be showing the wrong set of items.

Initial Review After Import

After you see the successful import message, do not start editing the design right away. First, check four basic points. Open the homepage in a private browser window and make sure the correct header, hero section, section cards, products, or placeholders are visible. Go to Settings > Reading and assign a static homepage if WordPress did not do it automatically. Open Appearance > Customize and check which global settings are active. Then open Theme Panel > Theme Dashboard > Demo Data or the equivalent theme section and confirm that the import did not stall halfway through.

If the import stalls on media, do not keep refreshing the page forever. First check whether the pages and settings were created without the media files. In some cases, it is safer to import without media and upload your own photos than to keep repeating a large import on weak hosting. For a real bar, your own photography matters more than someone else's demo images anyway.

Homepage: How to Preserve the Demo Atmosphere While Replacing It with Your Own Content

In the OldStory demo, the hero section is built around a large bar scene, a decorative frame, vintage typography, and a short call to action. Below it are sections about the venue, offers, menu, products, portfolio, brand story, subscription, and blog. The goal of setup is not just to replace the photos, but to preserve the rhythm: a striking first screen, then a trust-building story, then specific reasons to visit or buy.

Open the homepage in Elementor and work from top to bottom. For each section, write down its role: "grab attention," "about us," "what we offer," "menu," "products," "gallery," "story," "subscription," "articles." If a section is not relevant to the business, remove or disable it immediately before the page fills up with accidental edits. If a section is needed, replace the content logic first, then the images, then the spacing, and only after that the small decorative effects.

Hero Section and Slider

The ThemeForest listing notes compatibility with Slider Revolution and Swiper Slider, and the documentation describes a Slider widget and Slider Controller for managing slides. In practice, that means the hero section can be either a simple static hero or a slider. For a bar with a strong atmosphere, 1 to 3 meaningful slides are enough: "tastings," "cocktails," "evening program." Do not create ten slides, because visitors rarely view them all and load speed gets worse.

If you use a slider, check where each slide is sourced from: Revolution Slider, a Swiper Slider built with a ThemeREX widget, or an Elementor section background. After replacing the image, open Elementor's mobile view and reduce the heading size if it covers the button or a face in the photo. Elementor responsive settings let you change values for different screen sizes, so there is no need to break the desktop version just to make mobile work.

The "What We Offer" Block

In the attached preview, OldStory uses large visual cards for drinks, food, and interior atmosphere. This is a strong block for quick visitor decisions. Replace it not with abstract "services," but with real directions: cocktail menu, kitchen, tastings, private events, bottle shop, live nights. Each card should lead to a detailed section or page. Otherwise it remains purely decorative.

Keep the content depth consistent across all cards: a short title, one clear action, and an image in a unified style. If one card links to a WooCommerce category and another goes to a static page, that is fine, but the visitor should still understand what will happen after the click. Do not mix a product, an event, and an article in one grid without a clear visual distinction.

Drink and Food Menu

The menu section in OldStory feels like a natural part of the venue: decorative heading, categories, and pricing. If the menu is small, you can keep it as Elementor content. If it changes often, it is better to create a separate page or custom post type so staff can update items without editing the entire layout. For featured drinks and bottles sold online, it makes more sense to use WooCommerce products and display them through the appropriate widgets.

Do not use a screenshot of the menu as the only source of information for pricing. Text inside an image is harder to index, less accessible for people using assistive technology, and becomes outdated quickly. A strong approach is to use photos and decorative backgrounds for atmosphere while keeping the actual menu items as regular text, a table, or WooCommerce products.

Header, Menu, Mobile Header, and Footer Layouts

The header in OldStory can be either standard or a custom layout. The documentation lists several ready-made header layouts: default, simple custom, white custom, a single event variant, and a single shop variant. This is an important product-specific mechanic: the logo and menu may be set not only in the Customizer, but also inside a specific Elementor layout. That is why the common situation of "I changed the logo, but the old one is still on the site" is often explained by the fact that the active header uses a Layouts: Logo element, which overrides the global logo in Appearance > Customize > Logo & Site Identity.

Start by identifying which header is active. Open Appearance > Customize > Header, check the Header Style, and see which custom layout is selected. Then open Layouts > All Layouts, find the active header, and edit the Layouts: Logo, Layouts: Menu, search, burger panel, social icons, and cart icon. If the site uses a store, make sure the shop header is not displaying a different set of elements.

Menus and Locations

OldStory's documentation describes three main menu locations: Main Menu, Mobile Menu, and Footer Menu. WordPress also provides the standard Appearance > Menus interface for creating structure, nesting, and assigning menus to locations. For a bar website, a structure like this is usually enough: home, menu, events, store, gallery, blog, contact. If the homepage is long, add anchor links to sections, but do not force mobile visitors to scroll through ten menu items.

OldStory includes CSS classes for stretching large dropdown menus and columns, such as .trx_addons_stretch_window, .trx_addons_stretch_window_boxed, and .columns-X. Use them only when the menu is actually large: drink menu, kitchen categories, private events, shop categories. For a small menu, that kind of mega-dropdown only hurts readability.

Mobile Header Without Extra Weight

The documentation has a separate mobile settings section where you can choose different header and footer layouts, as well as a sidebar, for mobile screens. This is useful because hidden desktop elements may still load. On a bar website viewed on a phone, you usually need the logo, burger menu, quick call or contact access, address, business hours, and, if there is a store, the cart icon. Large slider layers, social widgets, and decorative panels are better left out of the mobile header.

The check is simple: open the homepage, menu, and event page in Elementor mobile mode, then test them in a real browser on a phone. Make sure the burger menu opens, does not cover the booking button or cart, and that keyboard focus does not move off-screen. The theme changelog has included fixes for the mobile menu and keyboard focus, so after every theme update you should manually review this block again.

Footer as a Reference Zone

The footer in OldStory can be either default or custom. For a bar, the footer should not be just decorative. It should solve an informational task: address, business hours, phone number, email, social links, privacy policy, site menu, and, if there is a store, delivery or pickup terms. In the default footer, you can configure widget sets, columns, full width, and copyright. In a custom footer, changes are handled through Layouts and Elementor.

Do not leave the demo phone number, demo email, or generic social links in the footer. It may seem minor, but that is exactly the kind of detail that makes a site look unfinished. After launch, review the footer on all key pages: homepage, event, product, blog post, contact page, and 404 page.

Appearance Settings: Colors, Fonts, Logo, and Section Rhythm

OldStory is built around a combination of vintage display typography, dark backgrounds, warm gold-copper accents, and large photography. If you replace only the logo, the site still looks like the recognizable demo. If you completely change all the colors and fonts, you may lose the very reason the theme was chosen. The goal of setup is to find the balance: preserve the atmosphere while removing someone else's branding.

Global settings are available in Appearance > Customize, and many of them are duplicated in Theme Panel > Theme Options. The documentation emphasizes the inheritance system: page-specific settings can override the Customizer. So if colors or the header behave strangely, do not check only the global level. Also review the page's own Theme Options.

Color Schemes and Accents

The documentation describes three color schemes: default light, dark, and alter light. With OldStory, it is usually best not to break the dark hero foundation and contrast-heavy sections, but to carefully replace the accent colors to fit the brand. For example, if the bar has a copper logo, keep the dark background and use copper for links, button backgrounds, and highlights. If the brand is lighter, move the lighter style into selected informational blocks, but do not try to turn the whole site white. The visual strength of the theme comes from contrast.

After changing the color scheme, check buttons, hover states, active menu items, product prices, forms, and notices. A color may look great in the hero section but become unreadable on a product card or in a Contact Form 7 message. Do not evaluate color in one beautiful block only. Check it across the full user journey.

Fonts and Decorative Headings

OldStory supports Google Fonts and custom fonts, and the documentation mentions a limit on how many font families should be loaded. For speed and visual consistency, it is better to choose 2 or 3 families: one decorative display font, one main text font, and, if needed, a separate accent font for prices or navigation. Do not load many font weights just for experimentation. Every extra typeface adds overhead and makes the visual system harder to maintain.

If you edit pages in Elementor, remember that Elementor also has global colors and fonts. Elementor stores global styles in the site kit, while the theme has its own color scheme settings. To avoid conflicts, decide what your main source of truth is: either you manage the overall style through the theme and use Elementor carefully, or you intentionally configure Elementor global colors and fonts and then verify how they affect WooCommerce, forms, and third-party blocks.

A Reversible Custom CSS Adjustment Without Editing Core Theme Files

OldStory's documentation includes an Additional CSS section and individual CSS classes for Elementor blocks. Below is a small reversible custom adjustment for a business-hours card or a short house-rules note. It does not rely on any hidden theme API: you manually add the oldstory-info-card class in Elementor under Advanced > CSS Classes, and place the CSS in Appearance > Customize > Additional CSS. That is safer than editing parent theme files.

.oldstory-info-card {
  border: 2px solid currentColor;
  padding: 24px;
  background: rgba(0, 0, 0, 0.04);
}

.oldstory-info-card .elementor-heading-title {
  margin-bottom: 12px;
}

@media (max-width: 767px) {
  .oldstory-info-card {
    padding: 18px;
  }
}

To verify the result, open the page in both normal and mobile views and make sure the card does not break the grid, cover the background, or conflict with the selected color scheme. Reverting is simple: remove the class from the section or delete the CSS from Additional CSS. Do not use this approach to fix critical theme bugs. If the problem is an import issue, a PHP error, or a plugin conflict, CSS will only hide the symptom.

Content Types: Services, Team, Portfolio, Testimonials, Events, and Blog

OldStory's strength is not just the homepage, but the set of content types that can be displayed in polished blocks. ThemeREX Addons adds custom post types and Elementor widgets for Services, Team, Testimonials, Portfolio, Blogger, and other elements. For a bar owner, this means many homepage sections should pull data not from random text inside a section, but from managed content entries.

Before populating them, create an editorial content map. Services should not mean "everything at once," but specific offerings: tasting, dinner, private event, gift set, bar school. Team should include people who build trust: head bartender, sommelier, chef, event manager. Portfolio should show visual cases: the venue, cocktails, events, tastings, interior. Testimonials are guest or client reviews. Blog content should reinforce expertise: drink roundups, brand history, pairing advice, event announcements.

Services: Offers as Managed Content

The documentation explains that service posts can be added through Services > Add New and then displayed with the Elementor Services widget or Blogger widget. Each service can include an image, excerpt, group, and additional item options. If WooCommerce is enabled, a service can also be linked to a product. This works well for setups like "tasting as a service" and "gift set as a product": the service explains the experience, while the product handles the purchase.

Do not turn service posts into advertising slogans. A good entry includes a clear title, short description, photo, who it is for, duration or format, limitations, and a link to either a form or a product. On the homepage, display 3 or 4 key services and keep the rest on a separate page.

Events: A Schedule Without Manually Copying Blocks

OldStory is compatible with The Events Calendar, and the documentation notes that event page appearance is configured in the Customizer and that single events are added through the WordPress Dashboard menu Events. For a bar, this is one of the most practical modules: tastings, live music, guest bartenders, private dinners, and workshops are much better managed as events than as regular pages. It makes dates, archives, and upcoming event lists much easier to maintain.

When creating an event, fill in the title, description, venue, time, image, and action link. If the event leads to ticket sales or a deposit, do not mix that with a generic informational button: send visitors either to a WooCommerce product, an inquiry form, or a separate booking system. After publishing, check the event archive, single event page, event header style, and the mobile event card.

Portfolio and Blog

The portfolio in this theme can be used as an atmosphere gallery: interior, bar counter, dishes, guests without violating privacy, events, and packaging details. The documentation describes archive styles, masonry layouts, popups, and navigation to a single item page. For a bar's visual brand, a popup may be appropriate, but for SEO and detailed case content, a single portfolio page with text, image alt text, and internal links is the better option.

OldStory's blog settings let you choose archive style, excerpt length, post meta, pagination, related posts, and post animations. For a restaurant, the blog should not become a junk news feed. It is better to publish content that supports the visitor's decision: "how a tasting works," "what makes this set different," "how to choose a drink for dinner," "event recap." That way, the blog connects the theme's design with real practical value.

WooCommerce Storefront, Products, and How They Connect to the Bar Menu

The ThemeForest listing and the documentation confirm WooCommerce compatibility. In the OldStory demo, you can see product cards with categories, sale labels, ratings, wishlist features, and purchase buttons. For a bar or pub, WooCommerce can serve different goals: selling bottles, gift certificates, merchandise, tasting sets, seat reservations through a separate product, or pre-orders, if that fits the legal and business workflow.

Start by deciding what WooCommerce should do on your site. If you sell only gift certificates, there is no reason to build a huge storefront. If you have a full shop, configure categories, attributes, shipping, taxes, payments, emails, and legal pages using standard WooCommerce logic. OldStory handles the visual appearance and theme integration, but it does not replace the setup of the commercial side.

A Product as Part of the Story, Not a Separate Shelf

WooCommerce documentation recommends planning categories, images, attributes, inventory, variations, and reviews before adding products at scale. In OldStory's context, that matters even more: the product card needs to support the bar's atmosphere. A drink should have strong photos, a category, a short flavor description, volume, origin, availability, sales restrictions, and a clean price presentation. A gift set should include its contents, fulfillment terms, and a clear call to action.

If a product is related to a service, use two levels. On the service page, explain the experience and show the photos. On the product page, provide the actual purchase terms. That way the visitor does not confuse "read about the tasting" with "buy the certificate." If you use ThemeREX Services with a linked product, make sure the link points to the correct product and does not open an old demo product.

Store Settings in the Customizer

In OldStory's documentation, the separate Shop and WooCommerce settings control the appearance of shop-related pages, product lists, and single product pages. That is where you choose the color scheme, content width, sidebar, and other parameters. Start with the product list: how many products are visible, whether a sidebar is shown, whether filters are needed, and whether categories and prices are readable. Then check the single product page: gallery, description, buy button, related products, breadcrumbs, header, and footer.

For a small catalog, it is often better to hide the extra sidebar and focus on large imagery. For a store with dozens of products, filters are useful, but they need to be tested: the ThemeREX Product Filters widget works only when WooCommerce is active and has limitations depending on inline or list page styles. If the filter is not needed on every page, do not place it in the global sidebar.

Test Order Review

Before launching the store, create one simple test product and check its category, image, price, stock status, cart, checkout, and email. Do not evaluate only the product card: the user journey ends after the email or order status. If the checkout looks out of place after configuring Elementor Theme Style, check the form fields, buttons, notices, and mobile spacing. Elementor Theme Style can affect non-Elementor elements, including WooCommerce fields, so this review needs to happen after all design changes are complete.

Practical Scenario: Build the Bar Homepage and Review the Result

Imagine this project: the venue has a bar program, a small kitchen, tasting nights, an interior gallery, and several gift products. The goal is to create a homepage where a visitor understands the atmosphere within a minute, sees the main offers, and can move to the menu, buy a certificate, or sign up for an event. This is a natural use case for OldStory because the demo already includes a hero section, offer blocks, a WooCommerce block, portfolio, story section, blog, and subscription form.

Goal

You need a homepage with a clear sequence: a hero section with positioning, an about block, three offers, a short menu, products or certificates, upcoming events, a gallery, a contact or subscription form, a blog, and a footer with contact details. The page should work without feeling like an unwashed demo copy: all photos, addresses, phone numbers, product names, events, and links must be replaced.

Preparation

Before editing, confirm that OldStory, the child theme, ThemeREX Addons, and Elementor are active. If you need a store, activate WooCommerce and create the basic shop pages. If you need an event schedule, activate The Events Calendar and create 1 or 2 test events. If you need a form, check Contact Form 7 and the email recipient. Then open the homepage in Elementor and either save a copy of the page or work on staging.

Setup Steps

1. In the hero section, replace the heading, subheading, button, and background image while keeping readable contrast and enough spacing from the frame.
2. In the venue block, replace the text with a short story: the bar concept, kitchen, tastings, atmosphere, neighborhood, or one distinctive detail.
3. In the offers block, keep 3 or 4 cards and assign real links to them: menu, events, store, gallery, or contact.
4. In the drinks menu, remove the demo names and enter real categories. If the menu changes often, link to a separate page instead of showing the full list on the homepage.
5. Create 3 WooCommerce products or temporarily hide the shop section if sales are not ready yet.
6. Create the nearest upcoming event in Events and display it through the appropriate block or link.
7. Replace the footer contact details, social links, privacy link, and copyright text, then review the footer on both a product page and an event page.

Review

Open the page in a private window. Walk through it like a normal visitor: hero button, offer card, menu, product, event, contact form, footer. Then check the WordPress admin side: products are in the correct categories, events are published, forms send email, and the menu is assigned to both Main Menu and Mobile Menu. On mobile, make sure the slider does not cover the button, the burger menu opens, cards do not become too small, and the footer does not turn into one long chaotic block.

A Detail People Often Miss

If you edit only the visible Elementor section but do not update the linked content entries, widgets may continue pulling demo content. For example, the Services widget may still show old service posts, the Products widget old products, the Blogger widget a demo blog category, and the footer layout an old email address. After editing any page, always check the data source for each dynamic block.

Reviewing Speed, SEO, Accessibility, and Security After Setup

OldStory gives you a strong visual foundation, but responsibility for the quality of the finished website still belongs to the site owner. Speed is affected by photos, sliders, enabled plugins, fonts, WooCommerce, events, and popups. SEO is affected by headings, text blocks, image alt text, schema from third-party plugins, breadcrumbs, menu structure, and whether pages are indexable. Security depends on WordPress updates, theme updates, bundled plugins, forms, user permissions, and hosting.

Start with a simple review checklist after every major change. Do not test only the homepage. Also check one blog post, one service, one event, one product, the contact page, and the 404 page. Restaurant websites often have a beautiful homepage while secondary pages fall apart because nobody opened them after the import.

Speed and Visual Effects

ThemeREX Addons includes settings for CSS and JS loading optimization, disabling emoji, deferring scripts, asynchronous loading, and exclusions. The documentation recommends choosing those modes carefully: if a slider, menu, checkout, or Elementor widget breaks after optimization, add the problematic script to exclusions or roll the setting back. Do not enable everything at once. Optimize images and fonts first, then test scripts.

A large hero section with several slides and heavy photos may look dramatic, but it can slow down the first screen. For a bar, one strong photo and one clear CTA are often better than a five-slide carousel full of heavy assets. If a slider is necessary, reduce the number of layers, test the mobile view, and disable unnecessary effects on small screens.

SEO and Content

The theme by itself does not guarantee good indexing. A strong page happens when decorative headings do not replace meaningful content. For the menu, add standard text with categories. For events, add descriptions. For products, use unique product descriptions. For the gallery, add alt text and short captions. For contact pages, include the address and business hours as text. If the theme has an active SEO snippets option or related settings, validate the markup with a checker, but do not duplicate schema across multiple plugins unless there is a real need.

The biggest SEO risk with a demo theme is leaving someone else's lorem-style text and identical demo titles in place. Even if the design is finished, those pages do not help visitors and do not inspire trust. Replace the content first, then think about fine-grained SEO adjustments.

Accessibility and Forms

For accessibility, check button contrast, focus behavior in the mobile menu, readability of decorative headings, image alt text, and keyboard support in forms. The theme changelog has mentioned accessibility and mobile menu focus improvements, but each actual site still needs to be reviewed manually after setup. In Contact Form 7, changes to the form template are not automatically reflected in mail settings, so if you add a phone field or event date, add the corresponding mail-tag to the email as well.

Security and Updates

Do not edit the parent theme directly. Theme and bundled plugin updates can overwrite changes, and naming conflicts in functions.php can lead to fatal errors. For small functions, use the child theme or a small site-specific plugin. For CSS, use Additional CSS. For Elementor structure, use layouts and widgets. Before updating, create a backup, check staging, update ThemeREX Addons and the other plugins, and then walk through the user journey again.

Localization, Forms, and Editorial Cleanup After Demo Import

Once the visual structure is in place, the next step is the one people often leave until the very end: bringing the site into line with the real language, legal pages, and working communications. For a Russian-language site built on OldStory, it is not enough to replace the hero heading and menu item names. You also need to check theme strings, form labels, WooCommerce system messages, events, email templates, privacy text, footer contact details, buttons, and image alt text. Otherwise, the visitor sees a polished first screen, clicks a form or product, and lands in a mix of demo English, placeholder addresses, and confusing notices.

The OldStory documentation describes translating theme files and ThemeREX Addons through language files. That does not mean every change should be made in code. Separate your strings by source. Page text is edited in Elementor. Service, product, event, and post titles are changed in their corresponding post types. Contact Form 7 labels are edited in the form itself. Theme and ThemeREX Addons system strings are translated through language files or a localization plugin. WooCommerce notices and emails are configured in WooCommerce. That order keeps you from hunting for the same phrase in ten different places.

Contact Forms and Consent to Data Processing

OldStory comes with prebuilt forms, and the documentation ties some contact forms to Contact Form 7. There is one important detail in Contact Form 7: when you add a new field to the form template, the corresponding mail-tag does not automatically appear in the email. For example, if you add a "Visit Date" or "Number of Guests" field, open the Mail tab and insert that mail-tag into the message body. Then send a test request and check the email in the inbox.

For a bar or restaurant, the form should stay short. Usually a name, phone number or email, preferred contact format, and message are enough. If this is an event form, add the event name as a hidden field or a separate subject so the manager immediately understands the context of the request. If the site includes a privacy notice or consent checkbox, make sure the link points to a real policy page, not a demo placeholder. OldStory's documentation includes a privacy link setting through the WordPress privacy page, so assign the page in Settings > Privacy first and then test the form.

A form test counts as successful only after the email is received. The green message on the website confirms that the form submitted on the front end, but it does not guarantee that the email arrived, avoided spam, or includes all newly added fields.

Translating WooCommerce and Events

If the site uses WooCommerce, check not only the product card, but also the cart, checkout, account area, order emails, and notices. Even if the store is used only for certificates, the visitor will still see several system screens. Old demo terms such as product categories, sale, wishlist, or add to cart may be fine on an English-language site, but on a Russian-language project they should be translated consistently. Do not edit WooCommerce templates in the parent theme without a reason: start with WooCommerce settings, language files, and safe child theme overrides only where they are truly necessary.

For The Events Calendar, check event titles, venue, organizer, date and time, archive page, single event header, and action button. If the event is tied to ticket sales or a deposit, the link should go to the place where the user completes the action, not to a generic "Contact" page. If you use events only as a schedule, do not add unnecessary payment fields or promise automated booking if the site does not actually provide it.

Editorial Pass Through Demo Content

Do one full pass through the site as an editor, not as an administrator. Open the sitemap or menu and review every page. On the homepage, remove sections that do not support the business goal. In services, replace demo excerpts with real service formats. In portfolio, remove someone else's titles and keep only images you are legally allowed to use. In the blog, remove demo posts or replace them with your first useful articles. In products, check stock status, descriptions, categories, and images. In the footer, replace the address, phone number, email, social links, and privacy link.

A good standard is this: if a visitor lands on any page directly, without first seeing the homepage, they should still understand what kind of venue this is, where it is located, how to get in touch, and what action they can take next. That is why you should not leave secondary pages in a "we'll finish this later" state. On restaurant websites, people often arrive from search directly on an event, product, post, or contact page. If that page still has the old header, an empty sidebar, or a demo footer, trust drops faster than it does on the homepage.

What to Document Before Moving to the Live Domain

Before launch, save a simple record of your decisions: which plugins are active, which are disabled, which page is assigned as the homepage, which header layout is used globally, which page-level Theme Options override shared settings, which forms send emails, and which WooCommerce sections are actually enabled. It is a simple document, but it saves time during updates and maintenance. If the owner asks a month later to change the logo or add a new menu item, you will know exactly where the source of truth lives.

The final editorial review should happen after the technical setup, not before it. Until the homepage is assigned, menus are configured, forms are connected, and dynamic blocks are tested, text edits may end up in the wrong data source. Once the structure is stable, editing becomes precise: you update a specific service, product, event, widget, or layout instead of some random visual fragment.

OldStory Issues That Most Often Get in the Way of Launch

Theme troubleshooting should move from installation to content, then to appearance, and only after that to optimization. If you start with cache or CSS, you can spend hours on a symptom that is actually caused by the wrong ZIP archive, disabled ThemeREX Addons, or a page-level override in Theme Options.

WordPress Says style.css Is Missing

Symptom: when uploading the theme, WordPress shows a missing stylesheet or broken theme message. Possible cause: the full ThemeForest package was uploaded instead of the installable archive. What to check: unpack the package and find oldstory.zip. How to fix it: upload that archive specifically through Appearance > Themes > Add New > Upload Theme or upload the extracted oldstory folder via FTP into /wp-content/themes. No rollback is needed if the wrong package was never installed.

Demo Import Stalls or Does Not Load Media

Symptom: the demo import hangs for a long time, breaks, does not pull in images, or returns a data-loading error. Possible causes: low PHP limits, weak hosting, active heavy plugins, or an unstable connection between the site and the demo server. What to check: memory limit, execution time, upload size, post size, active plugins. How to fix it: temporarily disable unnecessary extensions, repeat the import, import without media, or contact your hosting provider. When to roll back: if the import was run on a live site without a backup and replaced important content, restore the backup.

The Old Logo Still Appears on the Site After You Replace It

Symptom: the logo has been changed in the Customizer, but the header still shows the previous one. The usual reason is that the active custom header layout has its own Layouts: Logo element. What to check: Appearance > Customize > Header, the selected header style, and the corresponding layout in Layouts > All Layouts. How to fix it: open the header layout, replace the logo widget, save, and clear the cache. Limitation: if different pages use different header layouts, you need to review each important page separately.

The Homepage Displays Old Services, Products, or Posts

Symptom: the section text has been changed, but the services, products, events, or blog cards still show demo content. Possible cause: the Elementor widget is pulling dynamic data from a category, post type, product IDs, or demo taxonomy. What to check: each widget's settings in Elementor, the selected post type, category, query, and item count. How to fix it: create your own entries, assign categories, and change the query. If the block is not needed yet, hide the section until the content is ready.

The Mobile Menu Covers Content or Feels Too Heavy

Symptom: the burger menu opens with a delay, elements overlap, or social widgets get in the way of the phone button or other actions. Possible causes: the desktop layout is being reused as the mobile header, too many hidden elements are still loaded, there is a sticky row conflict, or a heavy slider sits next to a transparent header. What to check: mobile settings in the Customizer, the active header layout, Fix this row when scroll, and mobile menu widgets. How to fix it: create a separate compact mobile header layout, remove unnecessary widgets, and test focus and scrolling.

WooCommerce or the Form Looks Different After Elementor Styling Changes

Symptom: checkout fields, Contact Form 7 labels, or buttons become hard to read even though the homepage looks good. Cause: Elementor global styles or the theme color scheme are affecting non-Elementor elements. What to check: Elementor Site Settings, Theme Style, Customizer colors, form field colors, WooCommerce notices. How to fix it: set readable colors for forms and buttons, check contrast, and use targeted CSS through Additional CSS only after you understand where the problem comes from.

Some Visual Effects Disappear After an Update

Symptom: a hover effect, slider control, mouse helper, secondary image, or animation is gone. Possible causes: ThemeREX Addons was not updated, a required advanced addon was disabled, or a script optimization mode is interfering with the widget. What to check: Theme Dashboard addons, active plugins, the browser console, and ThemeREX Addons optimization settings. How to fix it: update the theme together with its addons, temporarily disable JS optimization, then re-enable options one by one. If the effect does not matter to visitors, it is sometimes better to remove it than to fix it only for demo similarity.

When ThemeForest OldStory Is the Right Choice

ThemeForest OldStory is worth using if you need more than a generic restaurant template. It works best as an atmospheric website with a strong hero section, bar-focused storytelling, menu, products, events, gallery, and blog. The theme performs especially well when the business is ready to provide its own photography, copy, and structure, and the webmaster is prepared to go through setup in sequence: installation - child theme - demo import - global settings - layouts - dynamic content - WooCommerce/events/forms - mobile review - performance review.

Do not start by publishing. First deploy the theme on a test installation, import the needed pages, replace the demo content, enable only the necessary plugins, walk through the visitor journey, and fix the issues. After that, you can download the ThemeForest OldStory archive and use it as the foundation for a careful launch or project update.

The main readiness check: the visitor should understand where they are, what the venue offers, how to view the menu, how to sign up for an event or move to a product, how to contact the bar, and why the site feels alive rather than abandoned after a demo import. If that sequence works, OldStory is doing its job.