What cms should I use for a dating site of this kind?

[tpb101]

I want to create a dating site, with up to 10,000,000, ultimately, or more. The website will target locations of the USA, Canada, and the UK, to begin with, lets say.

I want to create something like:

domain-name.com/california/san-francisco-1 (or this could be dynamic too, I think that non-dynamic would be better, seo wise, and for other reasons, but I did not look into this yet)

there would be 100 pages for every city (including the smaller ones, the ones with some search volume, Worldwide), and different keywords, based on the same template like "singles in <city>", "<city> personals", "dating in <city>". I would like to create a template, and output it, so I would not need to work on every single page. Just have a set of 100 selected keywords, list of cities and states, and crate all the pages, based on that. Text on the site would be template based also, just keywords would be different, according to the title tags, on every single page.

I also want to have a blog, a forum on the site, and other pages / content hubs, which will be planned, and added later.

What is the best cms / solution, for something like this. I am familiar with MySQL and PHP, so something based on this would be needed. I know Wordpress very good, but I think that Drupal, could be a better way to go.

Thanks.

[Kendo]

I am familiar with MySQL and PHP

In this case it will be best to roll your own. CMS provides a quick start for those who can't code but target orientated design is always best. Although starting with an existing CMS can save time, you most likely will find that the popular CMS like WordPress and Drupal are already over complicated for use as a building block. Also, those CMS are targets for exploit and always need updating. So start with a very basic CMS and one that uses MySQLi.

[topr8]

>>I think that non-dynamic would be better, seo wise, and for other reasons

>>What is the best cms / solution, for something like this

aren't these 2 comments a contradiction?

[lucy24]

up to 10,000,000, ultimately, or more

10,000,000 what? Pages? Users? Daily visits?

non-dynamic would be better, seo wise

I kinda think he's talking about the URL. If it ends in .html it looks like a hand-rolled page. Or at least it does until the search engine* takes a closer look at the code and recognizes the hallmarks of one or another popular CMS.

I don't think search engines care about URL format in and of itself. If there's hard information to the contrary, someone will step in and say.


* Or, ahem, cough-cough, a snoopy human visitor.

[Demaestro]

I would avoid a pre canned CMS and would look more towards frameworks, this will allow you to define all the functionality, without unnecessary bloat and security holes that need closing. A framework will still giving you a head start on a lot of things but let you "choose your own destiny" so to speak.

Laravel has been really good for me, codeigniter is another popular one.

[ergophobe]

Have you read any of Markus' articles about Plenty of Fish?

The only way he was able to make it profitable was by constantly optimizing the code for performance in order to keep his hosting costs down. Yes, you could perhaps use a CMS to build a site that would serve 10,000,000 users, but could you afford the server costs?

By Metcalfe's Law, the number of connections in a network is proportional to the square of the number of users. So with 10,000,000 you're looking at a massive number of connections and some serious horsepower required.

So I would second Demaestro and say build something bespoke to solve just this problem. My normal advice is to not think about scale, but this might be an exception. A dating site that doesn't scale is a blog ;-)

[Kendo]

By Metcalfe's Law, the number of connections in a network is proportional to the square of the number of users. So with 10,000,000 you're looking at a massive number of connections and some serious horsepower required.

So what you do here is use 2 sites. One to deliver the page and another to deliver all of the JavaScript, CCS stylesheets and images.Then 10,000 hits will remain 10,000 hits because the images/media will be pulled only once and cached by the browser.

This method becomes even more valuable when maintaining several sites that use the same images/media. If you look at WordPress for example, you will see the potential for an incredible saving.

You will have a tedious chore ahead of you if using an out-of-the-box CMS. But then just imagine the data you will save if running the same CMS version for all customer sites!

Only problem with this is that according to advice in another current post about always "updating WordPress to remain secure" is that such updates will undo all of your work. It should also be noted that such updates can and have introduced security flaws, and that is the reason that I really only ever recommend Custom CSS that has been designed to do a particular job and one that you can be assured will remain secure.

[ergophobe]

Kendo and Demaestro are definitely right - to operate on that scale you're going to need custom code.

You could integrate custom code into a CMS and if you do it as a separate module/plugin/add-on, you'll still be able to run updates without issue, but I don't think you can get there with a CMS and a custom module. There might be some off-the-shelf software made for running dating sites, but I guess none of us here know it. As far as I know, it's all proprietary.

I'm not trying to be a naysayer. As I say, I almost always find myself in the position of telling people not to think about scale. Most people worry about scale before they even have their first customer. But if you're making a dating site and you hope to run at a profit, I think you need to grapple with scale from the outset, otherwise you just create a model for losing more money faster.

use 2 sites

2 sites? You mean two sites or putting your static resources on a separate domain? Like example.com and static.example.com for static resources? You could just use a CDN. But that isn't the real problem. With Amazon Web Services or Cloudflare, that's all easy enough.

Then 10,000 hits will remain 10,000 hits

That's the problem. And that's where Metcalfe's Law comes in with respect to dating sites in a way that it just doesn't with respect to Wikipedia or most content sites.

I assumed he meant 10 million members, not hits. And 10,000 searches on a dating site with 10,000 members is not the same as 10,000 searches on a dating site with 10,000,000 members. And as per Metcalfe's Law, it's not merely 1,000 times harder. It's much worse than that.

So the problem isn't handling the static resources, it's the massive number of possible connections for your dating algo to handle. If you have 10,000,000 members in your database and you need to come up with joins that find

gender: male
geo: Toronto
seeking: female
age: 25 < age < 35
hobbies: at least two that overlap
religion: lapsed Catholic
pets: none
kids: none
marital status: single or divorced
subscription status: active
etc
etc
etc

And you have to run those queries on 10,000,000 people for 10,000,000 people, you have to know a thing or two about databases, data structures. profiling, etc etc.

Markus from Plenty of Fish (https://www.webmasterworld.com/profile/markus007/) used to be an active member here and had some illuminating posts on what it takes to run a dating site without going broke and why it has particular scalability problems that most sites don't have (LinkedIn would be an exception, but remember LinkedIn was started by a team whose background was... dating sites).

As Markus said "At the end of the day, its all about algorithms and AI and not about platforms/languages." [webmasterworld.com...]

[Kendo]

In case there is some confusion about my explanation...

When a page is requested all of the objects linked on that page such as images and style sheets become requests also. So each page can become 40 or more hits. Not only is it a data download but the server needs to process those requests and in most cases log them.

Now the browser or ISP may cache those images and style sheets so that the same data from them is not needed but the request sent and received by the server remains.

By using a second site or server for images and css you are taking the load off the main site. Also, your pages will be delivered quicker.

[lucy24]

I keep thinking about those 1,00,00,000* members. Sure we'd all like to end up with those numbers-- but is it good practice to start out that way? Is a framework designed to support ten million accounts going to work well in the early days when you have 1000 or 100 or 10,000? Or will it be inexplicably slow in other ways-- and, if so, will it make you less likely to grow and grow to your desired vast numbebrs?

I don't know if you can make a comparison to a store or fairground or concert hall that's made to hold 50,000 and instead there are only 500 because you've just got started and everything seems weird and empty. Maybe a real-estate site is a better analogy. Will the users prefer to see 5,000 separate pages, each with one or two listings or often none at all-- or 50 well-populated pages, each including listings that are far removed from what you're looking for?

Food For Thought.


* Inevitable mental association, because In My Day we were content to read the matrimonial ads on dead trees.

[ergophobe]

Kendo - I've got it, but I don't think you mean "a second site" you mean an additional server or set of servers on a separate subdomain.

I still think you get more bang for your buck in that case with a distributed CDN, especially for resources like JQuery where if you're lucky, the visitor has already loaded it from some *other* website.

Lucy - That's usually my approach. People worry about scale to early. But my small knowledge of dating sites is that if you ever hope to run at a profit, you must think about scalability from the get-go. Frankly, in most cases a dating site with 500 members isn't very useful typically. And in any case, a successful dating site results in people coupling up and dropping their memberships. The churn rate is astronomical - either you're bad at finding matches and people quit because you suck or you're great at finding matches and people quit because you're good. Either way, they quit (which is why the LinkedIn founders gave up on dating and focused on career management).

So it's one of those places where if you start out with a system that won't scale, you had better be sure you have a plan in place to make it scale. If not you either will die from obscurity or die from success, but you'll die either way.

[lucy24]

which is why the LinkedIn founders gave up on dating and focused on career management

Did LinkedIn really start as a dating site?! I had no idea.

But worth noting here that LinkedIn does have a mechanism for closing accounts. The basic information presumably gets shifted to a second "inactive" database so it doesn't bog down the server on ordinary requests, but the information must still exist somewhere. That's what you'd want on a dating site, whether it's to avoid confusion ("Oh, oops, you're not the John4321 I was friendly with last year") or to protect against intentional abuses ("Why certainly I'm the same John Smith who has a doctorate in statistics and is CEO of a Fortune 500 company, yup, that's me all right, I've just been away for a while"). Most types of membership sites don't need to do this: when you're gone, you're gone.*

Something tells me LinkedIn does not use an out-of-the-box CMS.


* Or, conversely, once you're here, you're here forever. "Sorry, we can't calculate your chess rating because half the people you've ever competed against have let their USCF membership lapse so we don't have the information any more."

[ergophobe]

LinkedIn did not start as a dating site. The founders previously built a dating site, but they noticed the phenomenon that I mentioned:
- if you're bad at it, members quit because they aren't finding someone
- if you're good at it, members quit because they found someone.

And with a dating site, it's bad form to keep up your membership dues after you've found someone. So they had to renew the membership every 3-4 months

With a career site, people will manage their career until they retire and even beyond. So while they *can* drop out, they typically don't. They might drop the premium membership, but as long as they stay in the system and are willing to accept email from recruiters, the network effect remains and value to premium members remains.

>>Something tells me LinkedIn does not use an out-of-the-box CMS

I'm trying to remember... I don't know if it was an article or someone I met personally who was telling me about their setup, but LinkedIn has a small army of coders last I heard.

[lucy24]

until they retire and even beyond

My hunch was that the main reason LinkedIn makes it easy for accounts to be deleted is that, outside the works of Terry Pratchett, dead people do not play a significant role in the workforce.

LinkedIn has a small army of coders

I should think Facebook and similar do too.

[ergophobe]

I take that back. LI has a large army.... if you can believe their own search, current employees with the title engineer or developer at LinkedIn numbers... 3112. But a search without titles gives a number of 47,000 and the actual number is 7600... so if you divide by 6, you get about 500 devs now.

[press.linkedin.com...]

[linkedin.com...]