hydrostarr

[Disclaimer: I’m basically a WordPress newbie, so I may be fumbling the syntax/jargon.]

Additionally: I do NOT want any Page or Post (even “main” or “home” pages – and I still don’t understand their different) to have any navigational capability to other Pages or Posts. Each one lives independently, and a website visitor is unable to discover or navigate to any other page.

This effectively makes each page an individual website. Making each Page/Post publicly viewable, but only if you have the link to said Page/Post. Hence,

(Just like Google Photos albums currently behave.)

This way I can email mutually-exclusive user groups/communities different Page links and prevent each community from seeing the other-community’s Pages. I just don’t want to have to setup a WordPress install (or whatever) for every Page; no need to. All Pages/Posts can be the same theme – just “not interlinked.”

(…again, just like Google Photos.)

Maybe I can do this by simply employing a super-plain, one-column Theme, and make sure to remove all navigational menus/sidebars/whatever. Then each created Page/Post only shows that Page’s (or Post’s) content, and no navigation to any other Page/Post in my WordPress website?

Plus:

* No core changes to WP.
* we can automate most anything (Python Fabric is weapon of choice, but use plenty of general bash & Python scripting) so long as we have a procedure
** …but Apache .conf changes (for each new site) are acceptable

In the end… I suspect we’re making a mountain out of a mole-hill here. Have strong “feeling” there’s a simple answer here for our application context (our WP site doesn’t really leverage WP as a “dynamic blog” like others do–it’s a rather static content set, just a company site selling products, no external/community users changing/adding content in forums/blogs or such), and there may be many wrong assumptions/misconceptions about the operational context… or just a general misunderstanding of the basic requirements.

In general: I can do this with most any other Apache/php application. Why not WordPress… or at least our WordPress, as it’s coded today? We don’t (yet) know.

Sorry for late reply. This is not solved. Problem:

https://serverfault.com/questions/361723/seeking-wordpress-apache-conf-that-allows-for-dynamic-subdir-to-site-creation

Addtl (redundant?) notes:

* .htaccess is a hack, prefer not to do that (we don’t use .htaccess for any of our production servers, considered “inferior” approach)
* each site will have it’s own database
* each site will have it’s directory (in filesystem and in Apache’s URL: mysite.com/site1, mysite.com/site2)
* each site/subdir can be dynamically created without changing Apache .conf
* workflow: git checkout a wordpress-based site install to a unique directory, create/import corresponding database, and above links (eg: https://mysite.com/siteX ) appear without any further (Apache or otherwise) configuration.
* this is all on Linux (specifically Ubuntu) system

Looks it’s feasible (Mike Little chiming in):
https://lists.automattic.com/pipermail/wp-hackers/2012-March/042520.html

Just need to figure out how.

fyi. Email just sent to wp-hackers.

——– Original Message ——–
Subject: Multiple versions of same install independently running on same server
Date: Sun, 11 Mar 2012 11:54:30 -0500
From: Hydrostarr <lists.automattic.com–[email protected]>
To: [email protected]

Need multiple versions of same install independently running on same
server. No sharing of install/files/databases. Just want to git clone
the same install (many different template/style.css customizations
between independent site installs) into different install directories
and map them independently (with with diff Apache virtual hosts or
subdirs on the same host) to different URLs.

Nothing’s worked thus far. Every time attempted there’s some
interdependency between install dirs, databases, Apache config. WP just
doesn’t “work relative to a root” like most all other web-server apps
that’s we’ve employed previously.

Every “multisite” blog/article we’ve read is for multiple “shared”
sites–sharing the same WP base install and/or database or something.
We don’t want that. We want our separate sites to know -nothing- about
each other, nothing “shared.” And we’d prefer if we could reference the
same site via different URLs for testing/modularity for
Apache-web-caching engines, etc (say https://site1.my.com and
https://my.com/site1 point to same WP install, and WP doesn’t “break”
when accessed from either one–currently impossible with the hard-coded,
base-URL). Alas, can live without this added luxury if we can solve the
larger problem (of multiple, independent installs on single Linux server).

fwiw. We change the base URL and such ( https://goo.gl/3TJq6 ) for each
install. We also change the hard-coded path in the mysql database from
say ‘/var/www/…’ to ‘/var/site2/…’ and still no luck.

What might we be missing? Maybe we need to use some WP plugin to
realize this “magic” of independent installs? Hard to imagine that.
Suspect we’re doing something “silly/dumb” and just trying to find out
what it is. Maybe we shouldn’t rely on the stock Ubuntu WP install?
(We -think- we’ve tried that with no success… but may try again.)

More details:
https://goo.gl/ldbkI
Ubuntu 11.04.
Stock WP install with ‘apt-get install wordpress’ (maybe the latter is
a/the problem)?

Problem still unsolved. wp-hackers did not respond other than to say post to jobs.wordpress.net, which I just did, but see the post show up. serverfault.com has not working answers. Also tried using multiple Apache virtual hosts with separate databases, that didn’t work either.

Why WordPress can’t use relative subdir/URL references for everything and be independent of any absolutely filesystem or URL path is a bit beyond me. That’s how every other modular app (and at least one of other CMS) does it.

Very disappointing this is still a problem.

Alternatively, if you’re insistent on hard-coding all the rules into the main config and not having .htaccess files, direct all requests to /index.php, parse the url, pull out the first directory from the url, then run include(‘./’ . $subdir . ‘/index.php’); or something..

Thx for suggestion. Can someone translate this into Apache-conf lines?

(Sorry, we’re not that good with Apache-rewrite-isms; we avoid them like the plague because they tend to be quite problematic. WordPress is one of few if only collaborative apps we know that requires them. Yes, most Apache-rewrite rules we’ve ever seen can often be done with a cleaner, less-error-prone approach… but I digress…)

Would be happy to hear we’re over-thinking things. But right now, it doesn’t work. Putting .htaccess (and enabling .htaccess in Apache main conf) as per the codex generates this error when visiting https://my.com/main/subpage:

Not Found
The requested URL /index.php was not found on this server.

…even though https://my.com/main does work. Again, would be thrilled to hear this is pilot error… if we could just get something to work.

If need be, can make a sufficient “anonymous” site with general public access to have people tinker with the config to see if they can get it to work… or witness first hand what we may or may not be messing up. Any takers?

($50 USD offer still stands.)

Kewl, thx. Just now subscribed/posted to wp-hackers, thx for the tip.

Quite sure. For this project, we don’t employ WP for blogs/users/etc. It’s simply a branded organization website, and we’re constantly changing/tweaking website “guts” (like the style sheet, coloring, video integration, graphics files, changing spacing/layout for new/different presentation, etc) that have nothing to do with the integrated (in our case mysql) database. [ In fact, we rarely change the database portion of website (the part that’s typically “dynamic.”) The fact that this is a WP site is really not that important to us in our current development (frankly). It was simply the most-convenient means to provide text edits. Otherwise, we could have considered writing our own CMS. But WP seemed good enough. But frankly, it’s now getting in the way….per above. ]

Because of this, we’re constantly making new “gut revisions” of the site that we want to review, and Mulitsite will not solve this problem. In fact, it will make it much worse.

Frankly, we suspect we know what we’re doing, and we need completely independent installs independent of Apache config changes as per above. (Can presumably get similar results by making multiple hostname-DNS entries and configuring Apache with corresponding virtual hosts for *every* new website rev review… but that’s way, way more cumbersome then simply deploying multiple git branches in respective subdirs…again as per above.)

Other web apps can do this. Including PHP-, Python-, Perl-based apps. With simple Apache ‘Alias’ mapping directives. Not fancy/cumbersome mod_rewrite requirements. (Somewhat poor design if ya ask us, but we take what we can get, especially if it’s free. ?? ) Why can’t WordPress?

Pls help us find ASAP what we’re looking for. We need Mulitple Site in way described above. And need it badly. We already need to concurrently present 5 new color-scheme website revs (with changing button-color icons as .png files in the underlying filesystem) to our client… and we needed this yesterday. (Or more like yester *year*.)

Again: Apache + git (with branching) + subdirs is bloody, dead-red easy to do. The Apache-WP integration (appears) to be the problem, namely the Apache config-file mod_rewrite config/directives. How soon can we make it not the problem…?

Finally: $50 USD (via paypal.com) goes to anyone who can solve this (without requiring Apache config changes for newly-added sites/WP installs) by 6p EST Fri, Feb 24.

Thx, nice description of the diffs. I need Multiple Site. Require multiple, completely-independent, WordPress installations.

Need to figure out Apache config to support that. Specific details/requirements at https://serverfault.com/questions/361723/seeking-wordpress-apache-conf-that-allows-for-dynamic-subdir-to-site-creation .

(Note: I have root access and will be adding /etc/apache2 config files directly; not sure if that changes apache-config directions. Those without root access are reduced to modifying .htaccess… which is generally viewed as a undesirable hack per our IT-admin policies.)

I frankly don’t understand the diff. I presume it’s multiple sites. (Multisite requires some extra install/plugin/something…?)