some other pre-sales questions ;)

Hi Nicholas,

phplistings seems great & I like your detailed FAQ/article topics. I especially appreciate your multi-directories side-by-side possibility
A couple of pre-sale questions please
(sorry it may seems a lot but I have tested your demo and look a lot around the site before asking; maybe it can help others also) 

1.  up to how many records, **approximately** can phplistings reasonably handle on a shared hosting ? Any demo or customer link with BIG directory ?
2.  as one of the topic in your FAQ, I would like to have it living side by side with wordpress. If I have 2 completely different directories (let's say /summer-jobs and /ice-cream-shops), can these 2 exist with nothing on the root (root would be for the wordpress main index.php, icons and others) ? Are there any other dir conflicts ?
3.  and in previous scenario, is phplistings generating its own 2 sitemaps with custom names (like summer-jobs.xml and ice-cream-shops.xml or others) to avoid sitemap name conflicts ?
4.  not sure I get the concept about "Listing type" right ... when I create a new listing in the demo, I am forced to chose one ... is that forcing me to some fields ... correct ? Is that same as "parent type" on the ones already created ... so why in the demo has "Jobs" the parent type "Listings" checked and not "Jobs" !?
5.  if I add several custom fields to my new listing type: for a given record, are the values of these fields stored in the same table as the record itself (all the record in *one* line of the table), or inside another table(s) (like wordpress meta, with some reference post <-> meta) ?
6. what are the Locations (I see 14k+ in the demo & I have read the manual page) ... created automatically when creating a record, or optional, or must be created before any record otherwise record can not exist? what is there benefit ?
7. no much about the paiement except the plenty of gateways. Is there a pdf invoice template , and sent to the paid customer ? is there a copy for admin ? Is there a backend for the customer to track purchases ?
8. I see themes function but not in the demo ? same for languages: I created a 2nd, but can't use/select it after ...

Thanks in advance,
Fabrice

Hello Fabrice,

thank you for your inquiry.

up to how many records, **approximately** can phplistings reasonably handle on a shared hosting ? Any demo or customer link with BIG directory ?

The software is well optimized and can easily handle 100k+ listings even on a shared hosting plan. However, it also depends on the hosting provider, as some of them apply very strict resource limits. In cases of high traffic, they may throttle MySQL usage, so performance can vary depending on the environment.

I can share a few examples of websites with 100k+ records via email or through a support ticket, as I’m not able to disclose them publicly. Thank you for your understanding.

 as one of the topic in your FAQ, I would like to have it living side by side with wordpress. If I have 2 completely different directories (let's say /summer-jobs and /ice-cream-shops), can these 2 exist with nothing on the root (root would be for the wordpress main index.php, icons and others) ? Are there any other dir conflicts ?

You did a great job going through the tutorials.

In this exact scenario, you would need two separate phpListings installations in two different directories on your hosting account. These would be fully independent installations, just as you described.

So yes, this is absolutely possible, phpListings can be installed and run without any issues in a sub-directory setup.

 and in previous scenario, is phplistings generating its own 2 sitemaps with custom names (like summer-jobs.xml and ice-cream-shops.xml or others) to avoid sitemap name conflicts ?

There will be two separate sitemaps, one for each directory, and they will be available at URLs like https://example.com/summer-jobs/sitemap.xml and https://example.com/ice-cream-shops/sitemap.xml

 not sure I get the concept about "Listing type" right ... when I create a new listing in the demo, I am forced to chose one ... is that forcing me to some fields ... correct ? Is that same as "parent type" on the ones already created ... so why in the demo has "Jobs" the parent type "Listings" checked and not "Jobs" !?

A Listing Type determines which form fields and schema.org properties will be used for that type. In short, listing types let you create different "templates" for different kinds of listings within the same directory system.

The parent type relationship is what enables linking between different listing types. For example, when "Jobs" uses "Listings" as its parent type, it allows you to connect a job to an existing business listing.

That’s why a "Related Listing" field appears when creating a job, it lets you select a business listing, and that relationship is then displayed on the job listing page.

 if I add several custom fields to my new listing type: for a given record, are the values of these fields stored in the same table as the record itself (all the record in *one* line of the table), or inside another table(s) (like wordpress meta, with some reference post <-> meta) ?

Since phpListings is well optimized, custom field data is stored in a separate table, similar to WordPress. Each record is linked to a listing via its ID, along with the field name and corresponding value.

what are the Locations (I see 14k+ in the demo & I have read the manual page) ... created automatically when creating a record, or optional, or must be created before any record otherwise record can not exist? what is there benefit ?

Locations are typically structured as countries, states, and cities, each with geo-coordinates included. These are predefined, so users can only select from existing locations when adding a listing.

This enables a cascading dropdown for easy selection when adding a listing, and the map will automatically center and zoom in based on the chosen location. Once the city is selected, users can fine-tune the exact position by dragging the map marker.

The goal is to speed up listing submission and enable features like location-based search and radius search for finding nearby listings. We don’t rely on paid APIs for this, only predefined location data.

no much about the paiement except the plenty of gateways. Is there a pdf invoice template , and sent to the paid customer ? is there a copy for admin ? Is there a backend for the customer to track purchases ?

The software automatically generates invoices and emails customers when a new invoice is created. It also sends notifications for unpaid invoices or suspended listings, so no manual work is required.

Invoices can be downloaded as PDF files, and all of them are stored in both the client and admin panels.

You can get a general overview of how the billing system works in this manual:

https://www.phplistings.com/manual/billing/products-invoicing

I see themes function but not in the demo ? same for languages: I created a 2nd, but can't use/select it after ...

The demo is quite limited, so you can’t add new themes or languages there.

However, once phpListings is installed on your own hosting, you can easily add new languages by uploading language files and also create custom themes. We can definitely assist with that, just let me know.

Thank you.

thanks for all these the details and I appreciate your supprt

"custom field data is stored in a separate table, similar to WordPress." ... hmmm, from my experience, with many records that is a big mess (and that is in fact the EXACT reason why I want to move away from wordpress and CPT - custom post types with custom fields)

•  it makes a lot of additionnaly queries to retrieve one single record (or plenty of mysql JOIN) --> lot of DB resources --> VERY slow with nice traffic (I have 2M views per months currently... and CPU is overloaded with db queries despite cache systems at all levels, like Redis and others and a hosting provider who is king enough not to trottle my account and letting me hit 100% CPU almost continuouisly)
•  it is a mess to maintain and access directly to modify, import/export directly in phpmyadmin or any custom code, as all one listing is not in one row

Hello,

phpListings does use a separate table for custom fields, but it is very different from WordPress.

In WordPress, wp_postmeta is a generic system shared across the whole CMS, which leads to heavy JOINs, complex queries, and poor performance on large datasets.

phpListings is designed specifically for directory workloads, so data is split into purpose-built tables (listings, categories, locations, memberships, etc.) and the custom fields table is used in a controlled, optimized way only for listing custom fields data.

The alternative "single wide table" approach (adding every field as a column) is also not scalable because it requires constant ALTER TABLE changes and becomes unmanageable with dynamic fields - an older and rigid 1990s-style design.

phpListings sits in between: flexible like meta fields, but structured and optimized like a purpose-built directory system.

Thank you.

Hi Nicolas,

Thanks for your response. I feel I hurt you; sorry this was not my intention.
I believe what you say and give poor credit to wordpress for that (but they must maintain a compatibility with their legacy and huge installed base)

A last question, back to my question #2:
I only need the *directories* to leave under their own dir/slug. These slugs would not be in any page, post, dir or category of wordpress.
I can not install several instance of the phplistings, as it will be a nightmare to admin, so as for the users to create a double account, billing (...). And I do not want to go down the road of mirror tricks and constant replication. So one install is really a must, that handles 3-4 slug/different dirrectories.

So I understand from your response that some common pages or admin pages or other root files are conflicting with wordpress ?
So is there no possibility of renaming the files or the folders in conflict with worpdress on the root so that there is only one install ? what is conflicting ?

and sorry I forgot the one about the location (and posts can not be edited on this forum): so user can not enter his adress that will automatically be located on a map ? he must select one the 14k pre-entered point !? ... if you confirm that, this is cray ... no directory will have all potential locations pre-entered (even on one country ... not even talking about several countries) ...

(and if you confirm this, this is a shame as openstreetmap code or other existig plugins created around openstreet map do support adress -> position on the map, without giving latitude longitude)

Hello,

So I understand from your response that some common pages or admin pages or other root files are conflicting with wordpress ?

phpListings is not conflicting with WordPress itself and can be installed into a sub-directory without any issues. This is actually the standard and recommended setup mentioned in the manual.

The issue in your specific case is that both WordPress and phpListings are standalone applications which expect to control the website root, routing, rewrite rules, admin paths, and internal requests. Because of this, installing both applications into the exact same physical root directory is not considered a reliable setup.

While this could theoretically be partially separated with complex .htaccess rules, it would be fragile and difficult to maintain long term.

So the recommended structure is:

* WordPress in the website root
* phpListings in a subdirectory such as /directory/ or /listings/

You can still use a single phpListings installation for all your listing sections and users.

and if you confirm this, this is a shame as openstreetmap code or other existig plugins created around openstreet map do support adress -> position on the map, without giving latitude longitude

phpListings uses predefined locations to keep the system structured, fast, and consistent across search, filtering, and SEO pages. When users pick from a controlled location set, you avoid issues like duplicate entries, spelling variations, and inconsistent map/search results.

Free-form address input sounds simpler, but it depends heavily on external geocoding services (like OpenStreetMap/Nominatim or Google). Those come with real-world issues: rate limits, occasional downtime, inconsistent accuracy, and different results per request. That can make listings less stable and harder to manage at scale.

Also, most directories don’t actually need full street-level precision, they need reliable, searchable regions (city, area, region, country), which predefined locations handle much better.

That said, this is not a hard limitation. Address-based input with automatic geocoding and map pinning can absolutely be implemented via customization or integration if needed. The current approach is just the most stable default for directory structure and performance.

no directory will have all potential locations pre-entered (even on one country ... not even talking about several countries) ...

phpListings does not require manual creation of all locations. We provide ready-made location datasets that can cover a single country, multiple countries, or the whole world, depending on the project.

These are pre-structured administrative locations (country → region → city), designed for consistent search, filtering, and SEO.

So it’s not about manually entering thousands of places, it's about importing complete location packs as needed. Free of charge.

Thank you.