Page Mapping... RIP (When Your Business Case Eliminates a Feature)

So, I had two use cases for this subdomain mapping, and I figured out that one of these use cases isn't relevant, or it is really not relevant in the long term.

As always, business needs determine technical needs, though that can get lost when you're focused on code.

The first scenario is basic database publishing. I have a table, and want to display a record. I don't want to use WordPress' custom post types because getting data into and out of the system is difficult. So, I need a plugin or template that will display a record based on the URL. The Page Mapping feature is only peripherally relevant here: all subdomains map to the same page.

The second scenario is what's described in the previous post. The subdomain maps to a single page. This single-page site, it could work for some businesses, but most would rather have a complete website. Moreover, most designers and webmasters would rather have a complete website, even if it costs more and they still make a micro-site.

The third scenario is just upselling to a multisite or completely separate site.

So, the second scenario is a real outlier. At best, it could be relevant in the early stages of a business, when you need a little cash flow. Even then, it's probably a bad idea, because code is expensive. It costs money to maintain code, and having three use cases is more expensive than having two, or even one. (More specifically, the code is expensive to me. The cost of other options is externalized.)

The technique described is still relevant, but will be modified for the first use case.