Category: Events Module / Admin Settings Currently, users can create events with dates several years into the future. This can lead to unrealistic event listings, outdated information, and businesses using the Events module to promote their services instead of creating genuine events. I would like to suggest adding an administrator-configurable Future Date Limit to control how far in advance users can schedule events. Suggested improvement: Add a setting in the Events module that allows administrators to select the maximum period into the future for event dates. For example: 3 months 6 months 12 months 24 months Unlimited Custom number of months How it would work: Users can only select event dates within the permitted future period. The maximum permitted date automatically moves forward each day. Users entering dates beyond the limit receive a clear validation message. Administrators can override the restriction for legitimate events. Recurring events should be handled separately to accommodate genuine recurring activities. Why this would be useful: One issue with directory Events modules is that some businesses create events simply to advertise their business, products, or services. For example, a business might create an event with a start date today and an end date several years into the future, effectively turning an event listing into a permanent business advertisement. This undermines the purpose of the Events module, which should primarily showcase genuine events with meaningful dates. Introducing Future Date Limits would help: Prevent events from being scheduled years into the future. Discourage businesses from using event listings as permanent advertisements. Reduce incorrect or misleading event information. Improve the quality and relevance of event search results. Keep the Events module focused on genuine upcoming activities. Additional suggestion: Consider allowing administrators to set a Maximum Event Duration as well, such as 7, 30, 90 days, or a custom period. This would prevent users from creating an event that starts today but continues for several years, even when the start date is within the permitted future date limit. Together, these two settings would give administrators much better control over event quality without unnecessarily restricting legitimate event organisers. Regards Aaron
Category: Payment & Promotions / Coupon Codes Currently, the coupon code system allows administrators to set an expiration date, but there is no option to specify when a coupon becomes active. I would like to suggest adding a Start Date field alongside the existing Expiration Date field. How it would work: Start Date: The date the coupon becomes valid and can first be used. Expiration Date: The date the coupon stops being valid. Before the start date, the coupon cannot be redeemed. After the expiration date, the coupon automatically becomes invalid. If no start date is entered, the coupon becomes active immediately, maintaining compatibility with existing coupons. Why this would be useful: Businesses often plan promotional campaigns in advance, such as Black Friday, Christmas, New Year, and seasonal sales. Having both a start and expiration date would allow administrators to create and schedule coupon codes ahead of time without needing to manually activate them when a promotion begins. This is a small improvement that would make the coupon system more flexible, practical, and useful for marketing campaigns. Regards Aaron
Please add a Quick edit option to each listing on the admin Listings page, allowing administrators to update basic information without opening the full listing editor. Currently, each listing must be opened individually to make even a small change. When reviewing and maintaining thousands of listings, those extra steps take considerable time. Suggested functionality Clicking Quick edit would expand a compact form directly beneath the selected listing, as shown in the attached mockup. Editable fields would include: Listing name Phone number, email, and website Street address, city, state, and ZIP code Categories Listing level Active or inactive status Short description Logo The form should include Save changes and Cancel buttons, along with a link to the full listing editor for more detailed changes. Expected behavior Saving should update the listing without reloading the page or losing the current search, filters, pagination, or scroll position. A clear confirmation should appear after a successful save. Cancel should discard unsaved changes and collapse the form. Existing field validation and administrator permissions should apply to quick edits. This feature would make routine listing maintenance much faster, particularly when correcting contact information, adjusting categories, or reviewing several listings in sequence. The attached mockup illustrates how this could fit within the existing admin interface.
Would like to suggest consideration to identifying duplicate/similar listings as we are finding many users submitting multiple listings with identical/similar content . This tends to occur with personnel changes @sponsors with no idea a listing exists. Also when importing listings froma Dbase can also create a multiple listing situation
I think it would be very useful to add an Admin Notes / Internal Notes feature across all content types within eDirectory. This should apply to: Listings Deals Events Classifieds Articles Blog Forum Banners The purpose would be to allow administrators to record important internal information directly against any piece of content. These notes would be visible only to administrators and never visible publicly or to the account owner. For example: Suspended – 11 September 2026, 10:35 AM Content suspended following repeated attempts to add information that does not meet our requirements. Account owner contacted by email. Other examples could include: Verification Required – Business ownership needs to be confirmed. Complaint Received – Complaint received regarding information published in this listing. Banner Issue – Advertiser supplied incorrect artwork; waiting for replacement. Duplicate Content – Possible duplicate of another listing. Needs review before approval. Admin Note History Rather than having a single note that gets overwritten, I think each content item should have an internal history of notes. Each entry could automatically record: Date and time Administrator who added the note Note Optional status/reason For example: 11 Sep – Aaron: Listing suspended. Verification requested. 12 Sep – Lilian: Documents received from business owner. 13 Sep – Aaron: Verification completed and listing reinstated. This creates a simple internal administrative history for that content. Display in the Content Management Screens The feature would be particularly useful if Admin Notes could be displayed as a column in the existing Content management screens. For example: Title Status Admin Notes ABC Plumbing Active Verification completed... XYZ Services Suspended Suspended – duplicate busin... Only the beginning of the latest note needs to be displayed so it does not take up too much space. The administrator could hover over the text to see the full latest note, or click it/Edit to open the complete Admin Notes history. Admin Notes should also be searchable, making it possible to search for words such as: Suspended, Complaint, Verification, Duplicate, Warning, Ownership, Fraud, Payment, etc. Why This Would Be Useful As a directory grows, it becomes increasingly dif
We need a simple way for Sponsors to upgrade or downgrade their subscription tier without having to create a new listing. This affects every directory owner’s bottom line: A Sponsor ready to upgrade = more revenue — unless changing tiers means starting over. A Sponsor who needs a cheaper tier can keep paying something — instead of cancelling and paying $0. Less back-and-forth = less admin for us and less frustration for Sponsors. But there’s an even bigger issue: Sponsors can lose everything they’ve built on their listing. If changing tiers means creating a new listing, they don’t just have to rewrite their content. They can also lose their star ratings, reviews and testimonials — the social proof they may have spent months or years building would be gone. Why would a Sponsor risk losing all of that just to upgrade? And if they need to downgrade, we’re making the decision to leave even easier. Why rebuild from scratch on the same directory, losing their social proof when they can simply cancel? That creates unnecessary friction at exactly the moment we’re trying to retain or grow a paying Sponsor. Sponsors should be able to choose a new tier, click, done — while keeping their existing listing, content, ratings, reviews and testimonials intact. We shouldn’t make it easier to leave than to stay. Easy upgrades and downgrades are core functionality for a subscription directory. They mean more upgrades, fewer cancellations, protected Sponsor value, happier Sponsors, and more recurring revenue for directory owners. If keeping Sponsors and growing directory revenue matters to you too, please VOTE for this feature.
I love the eDirectory platform, including the mobile app functions. However, I think it would be great to add the “claim listing” feature to the mobile app version of the directory. I am really promoting usage of the app and I’d like to make sure that this feature is available to users-particularly those listed in the directory. Having this would further protect the directory
Request Please add native support for short-form vertical videos on individual Listing and Event pages, including: YouTube Shorts TikTok Instagram Reels Facebook Reels Ideally, this functionality should be integrated into the existing Listing/Event video player, allowing a short-form video URL to be added in the same way YouTube or Vimeo videos are currently supported. If extending the existing player is not technically practical, a dedicated Short-Form Video widget or field for Listing and Event pages would be an excellent alternative. Current Limitation eDirectory currently supports traditional YouTube/Vimeo video content on listings, but YouTube Shorts and other major short-form video formats cannot be used in the same way. Version 14 introduced a carousel widget supporting TikTok and YouTube Shorts for general pages, which was a valuable addition. However, this does not address the original use case: associating a short-form video directly with an individual Listing or Event. The short video should represent that specific business, attraction, destination, restaurant, hotel, activity, or event rather than being part of a general site-wide video carousel. Why This Matters Short-form vertical video has become one of the primary ways people discover businesses, destinations, attractions, restaurants, activities, and events online. For a directory, a visitor often does not need or want a long promotional video. A 30 to 60-second video can quickly show: what the place looks like; what visitors can expect; the atmosphere or experience; key attractions, products, or services; why someone may want to visit. This is particularly valuable for tourism and local directories, where visual presentation can have a major influence on a visitor's decision. Short-form video is also now routinely created for YouTube Shorts, TikTok, Instagram Reels, and Facebook Reels. Allowing directory owners and advertisers to reuse this existing content would significantly increase the value and relevance of Listing and Event pages. Suggested Implementation Preferred option: Extend the existing Listing/Event YouTube/Vimeo video functionality to recognize and properly display supported short-form URLs from: YouTube Shorts TikTok Instagram Reels Facebook Reels The player should preserve the appropriate vertical aspect ratio rather than forcing vertical content into a traditional 16:9 player. Alternative option: Introduce a dedicated Short-Form Video field/widget for Listing and Event pages that accepts supported URLs and renders the appropriate vertical player. Ideally, the implementation should also be responsive and optimized for mobile devices. Summary The general-page Shorts carousel introduced in v14 is useful, but it solves a different use case
For me, having an article section is a big part of my site SEO and monetization. If there could be a level assignment similar to listings and events, that could be very useful
For more than two decades, online directories have helped customers discover businesses, products, and services. They have provided a structured way for businesses to share information and for customers to search, compare, and make decisions. But the way people discover information is changing. The next generation of search is not only about typing keywords into a search engine and clicking through websites. Increasingly, people are asking AI assistants questions such as: "Find a plumber near me that offers emergency service." "Which restaurants nearby have outdoor seating?" "Find a supplier that specialises in this product." "Compare businesses that provide this service." The future customer may not visit ten websites before making a decision. They may simply ask an AI assistant to find the right business. This creates a new opportunity for online directories. The directories that succeed in the future will not just be websites where people search for businesses. They will become trusted sources of structured business information that AI systems can understand, access, and interact with. From Search Engines to AI Discovery Traditional online discovery has followed a simple path: Customer → Search Engine → Directory Website → Business Listing The emerging AI model looks different: Customer → AI Assistant → Trusted Business Data → Recommendation For businesses to be discovered in this new environment, their information needs to be: Accurate Structured Verified Current Available to authorised AI systems Directories are uniquely positioned for this future because they already collect, organise, and manage business information. The next step is allowing AI systems to securely connect with that information. What Is MCP? The Model Context Protocol (MCP) is an open standard that allows AI applications to securely connect with external systems, data sources, and tools. In simple terms: MCP allows an AI assistant to communicate directly with a platform. Instead of an AI system only reading a webpage, it can securely interact with approved functions and perform actions based on the permissions it has been granted. For a business directory, this opens up exciting possibilities: AI systems can discover verified businesses Business owners can manage their listings through AI assistants Directory owners can operate and improve their platforms using AI tools Introducing the eDirectory AI Connection The next generation of eDirectory can become more than a directory website. It can become a connection point between: Businesses Customers Directory administrators AI assistants AI search plat
Hello eDirectory Team, First, I'd like to thank your for continuing to improve the platform. I've been building a tourism directory and have found the Related Listings widget to be a valuable feature. D uring implementation, however, I identified an enhancement that I believe would greatly increase its flexibility while remaining fully backward compatible. Current Limitation The Related Listings widget currently supports three display methods: By Category By Location By Category & Location When By Category or By Category & Location is selected, the widget automatically displays listings from the same category as the page where the widget is placed. Likewise, when By Location or By Category & Location is selected, the widget automatically uses the same location as the current listing. While this works well for traditional "related listings," it prevents site owners from displaying complementary content from other categories or locations without custom development. Proposed Enhancement Add two optional override fields to the existing widget configuration. Override Category (Optional) Display this field whenever: By Category By Category & Location is selected. The field would present a dropdown containing all available listing categories. Behavior If left blank, the widget behaves exactly as it does today by using the current listing's category. If a category is selected, the widget displays listings from the selected category instead. Override Location (Optional) Display this field whenever: By Location By Category & Location is selected. The field would allow the administrator to select a specific location. Behavior If left blank, the widget behaves exactly as it does today by using the current listing's location. If a location is selected, the widget displays listings from that selected location instead. Suggested Configuration Display Method □ By Category □ By Location □ By Category & Location Override Category (Optional) [Dropdown] Override Location (Optional) [Dropdown] Sort By [Highest Rated] Number of Listings [10] If either override field is left empty, the widget simply falls back to its current behavior. Backward Compatibility One of the biggest advantages of this enhancement is that it is completely optional. Existing websites require no changes. Existing widgets continue to function exactly as they do today. Site owners only use the new functionality when desired. No existing implementations wo
Hello Team, I would like to suggest adding an optional Sticky (Floating) Sidebar feature for Listing Detail Pages. Current Situation On listing pages containing substantial content such as descriptions, videos, image galleries, reviews, nearby attractions, and other information, the right sidebar is only visible near the top of the page. Once visitors begin scrolling through the content, important sidebar elements disappear from view and remain inaccessible unless the user manually scrolls back to the top of the page. This is particularly noticeable on longer listings where users spend significant time reading and exploring content. Proposed Enhancement Introduce an optional Sticky (Floating) Sidebar that remains visible as users scroll through the page. The sidebar would stay within the visible viewport while respecting the page layout and automatically stop when reaching the end of the content area. This behavior is commonly found on modern travel, directory, real estate, e-commerce, and hospitality websites because it keeps key actions accessible throughout the user's browsing experience. Elements That Would Benefit A sticky sidebar could keep the following items visible throughout the page: Reservation and booking buttons Contact and inquiry buttons Maps and directions Social media links Nearby listings and recommendations Promotional widgets Advertising placements Other sidebar widgets configured by the site owner Benefits Improved User Experience Eliminates the need to scroll back to the top to access important actions. Creates a smoother and more intuitive browsing experience. Improves usability on long-form content pages. Increased Conversion Opportunities Reservation, booking, contact, and inquiry buttons remain visible at all times. Visitors can take action the moment they decide to engage. May increase lead generation and conversion rates for listing owners. Improved Advertising Visibility Sidebar advertisements remain visible for a greater portion of the visit. Potential increase in ad impressions and click-through rates. Better Engagement Across the Platform Maps, social links, and nearby recommendations remain easily accessible. Encourages visitors to explore additional listings and content. Suggested Configuration To maximize flexibility, consider making this a configurable option within the widget or page settings, allowing administrators to choose between: Standard Sidebar Sticky (Floating) Sidebar This would enable site owners to select the behavior that best fits their design and user experience goals. Additional Consideration Before implementing a completely new feature, it may be worth confirming whether the platform or theme framework already supports sticky widgets or sticky sidebars internally and simply does not expose the option within the current settings interface. If such functionality already exists, exposing it as a configurable setting could provide a quick and efficient enhancement with minimal development effort. Use Cases This feature would be particularly valuable for: Tourism attractions Restaurants Hotels and accommodations Event venues Tour operators Activity providers Long-form directory listings with extensive c
Following on from the llms.txt feature request — once llms.txt and llms-full.txt are in place, the remaining gap to a full score on the Content dimension of isitagentready.com is Markdown content negotiation. When an AI agent requests a page, it sends an Accept: text/markdown header. If your server returns HTML, the agent has to parse out navigation, scripts, ads, and markup noise to get to the actual content — burning tokens and often getting it wrong. If your server detects that header and returns clean Markdown instead, the agent gets exactly what it needs, efficiently. The request: When eDirectory detects an Accept: text/markdown request header, return a clean Markdown version of the page instead of HTML — covering at minimum: Category pages (name, description, listing summaries) Listing detail pages (business name, description, contact info, category) Key static pages (About, Contact, Add a Listing) This doesn't need to replace the HTML response for normal browsers — just intercept the header and serve an alternate clean representation to agents that ask for it. Why it matters: This is the difference between an AI agent being able to read your directory and being able to use it as a reliable source. Combined with llms.txt, a proper robots.txt with AI bot rules, and a sitemap, this completes the first three AI readiness categories and puts eDirectory sites at the top of the scoring curve. Most platforms haven't implemented this yet. It's a genuine differentiator right now. Aaron
AI agents (ChatGPT, Claude, Perplexity, Gemini) are increasingly how people find businesses and services — and they need a different signal than Google does. The emerging standard is llms.txt and llms-full.txt, two plain Markdown files served from your web root that give AI agents a clean, structured map of your site — what it covers, your main categories, key pages. Think of it as robots.txt but for LLMs. The spec is documented at llmstxt.org. Cloudflare recently launched a free AI readiness scanner at isitagentready.com that scores your site 0–100 across five dimensions. The llms.txt files directly impact the Content score. Without them, AI agents have to scrape HTML and often skip the site entirely. The request: Add a dedicated AI Identity section in the eDirectory admin panel where directory owners can provide: Directory name and tagline Purpose and description of the directory Who the directory is for (target audience) What regions, industries, or niches it covers When the directory was founded/launched Primary contact name and email Owner/operator website or social links Auto-generate llms.txt and llms-full.txt by combining that AI Identity information with the directory's live category structure, key pages, and site description — similar to how sitemaps are already generated Serve both files from the web root with correct Content-Type: text/plain headers and keep them updated as categories and pages change The AI Identity section is important because auto-generating from categories alone gives AI agents the structure of the directory but not the context — who runs it, why it exists, who it serves. That context is what helps an AI agent decide whether your directory is the right source to cite for a given query. For sites already on Cloudflare, this would also push scores significantly on isitagentready.com. Worth noting that full marks on the Content dimension also requires serving Markdown on Accept: text/markdown requests, which could be a natural follow-on feature. See Part 2 This is a quick win that puts eDirectory sites ahead of the vast majority of the web right now. The window where this is a differentiator rather than table stakes won't be open long. Aaron
I need to flag a serious issue with the Enable AI-powered summary on search pages feature, and request that a token cap or rate limiting control be added. What happened I enabled this feature on our directory and within a single day we had consumed 63 million tokens. One day. That is not a typo. At OpenAI pricing, 63 million tokens at $5.00/M input and $30.00/M output represents a potentially catastrophic unplanned cost for any directory operator. Even at budget provider rates this is deeply problematic at scale. Why this feature is uniquely dangerous compared to the others Every other AI toggle in the Configure AI Integrations panel is bounded by human interaction: AI suggest for admins and sponsors — fires only when a human edits content AI review summaries — fires per listing, capped by listing count AI content moderation — fires on submission events only AI mode on search bar — interprets a query but does not generate a full page summary The AI-powered summary on search pages is different. It fires automatically on every single search page load with no ceiling. Directory sites attract significant automated traffic — bots, crawlers, indexing spiders — and every one of those hits to a search URL burns tokens silently in the background with no warning and no limit. This is not a configuration issue on our end. It is a missing guardrail in the platform. What I are requesting Please add the following controls specifically for this feature: Daily token cap — hard ceiling after which the feature simply does not fire for the remainder of the day Monthly token cap — a broader budget limit with an alert when approaching the threshold Email alert — notify the admin when token usage crosses a configurable threshold (e.g. 50%, 80%, 100% of cap) Bot/crawler exclusion — option to suppress AI summary generation for non-human traffic Rate limit per IP or per session — prevent any single visitor or bot from triggering unlimited AI calls in a short window Any one of these would have prevented our 63 million token day. All five together would make this feature genuinely safe to run in production. Until one or more of these controls exist, toggled it off. Thanks, Aaron
I'd like to raise what I think is one of the most impactful feature improvements you could make to the AI section of eDirectory: opening up the AI provider configuration to allow a custom API base URL and model name, rather than locking users to just OpenAI. The OpenAI API standard is to AI what S3 is to object storage The best way to understand this is by analogy. Years ago, Amazon S3 defined an API standard for object storage. Today, dozens of providers — Cloudflare R2, Backblaze B2, Wasabi, MinIO, and many others — all implement that same S3-compatible API. The result is that any application built to talk to S3 can switch providers by simply changing an endpoint URL and credentials. No code changes. No re-integration work. The OpenAI /v1/chat/completions API has become exactly the same thing for AI inference. It is now the de facto industry standard protocol, and virtually every major AI provider in the world has adopted it as a drop-in compatible interface. Western providers OpenAI — api.openai.com/v1 Google Gemini — generativelanguage.googleapis.com/v1beta/openai xAI / Grok — api.x.ai/v1 Mistral AI — api.mistral.ai/v1 Groq — api.groq.com/openai/v1 Together AI — api.together.xyz/v1 Fireworks AI — api.fireworks.ai/inference/v1 Perplexity — api.perplexity.ai OpenRouter — openrouter.ai/api/v1 (routes to 100+ models via one key) Ollama (self-hosted) — localhost:11434/v1 LM Studio (self-hosted) — localhost:1234/v1 Chinese providers (all OpenAI-compatible) DeepSeek — api.deepseek.com/v1 Z.ai / GLM (Zhipu AI) — api.z.ai/api/openai/v1 Qwen / Alibaba — dashscope.aliyuncs.com/compatible-mode/v1 MiniMax — api.minimax.chat/v1 Moonshot / Kimi — api.moonshot.ai/v1 ByteDance / Doubao — ark.cn-beijing.volces.com/api/v3 Baidu / ERNIE — qianfan.baidubce.com/v2 StepFun — api.stepfun.com/v1 Xiaomi / MiMo — via OpenRouter Tencent Hunyuan — api.hunyuan.cloud.tencent.com/v1 They all speak the same protocol. If eDirectory simply exposed a custom API base URL and model name field, every single one of these becomes instantly usable — with zero additional development work on your end. One implementation unlocks the entire ecosystem, now and for every provider that emerges in the future. Just like S3 compatibility did for storage. The cost case
This is a much needed and great feature however it is of little use if the sponsors or listing claimer has to pay upfront and then we have to do a manual refund if we are not excepting the listing. It really is an easy work around with stripe to have charges deducted only once approved. That will make this feature usable. Please fix this. Thank you
It would be very beneficial if we could add prompts and/or examples in the long and short description blocks to ensure sponsors are giving good information for their listings
The sponsor dashboard does not align with personalisation of fonts, colours etc Like this page for example very outdated look and can this not be editable to just display available plans? This then redirects the sponsor to the list with us page which is not good UX
O eDirectory tem muitas ferramentas para um portal ou guia local e aproveitando a AI, acho muito interessante criar conteúdo com API da AI. Buscar eventos e notícias atuais e inserir no site, agregando conteúdo diário ao mesmo.