Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2011-09-08 14:13:29
- AdamK
- Member
- From: Kraków, Poland
- Registered: 2009-08-11
- Posts: 47
Multisite installation: configuration process
Hello
I did not find (didn’t try too hard…) a thread similar to mine, so there is my impression on configuring a new site:
1) why should TXP not try to write config.php by itself?
2) there should be an option, maybe marked as an advanced, on the configuration page: “it’s multisite installation”, which would add the requested
define(‘txpath’, $txpcfg[‘txpath’]);
to the config.php
I think, BTW, that all those “INCORRECT” words in readme.txt on multisite setup should be removed: it’s NOT users’ problem, it’s the application’s, and TXP should take care about wrong paths by itself.
Thanks
Adam
P.S. BTW all the README.txt or it’s part about the paths should be accessible on config page to be referenced in the browser, I believe…
P.S. II: Why not to treat “single site” as a multisite with one site set? it would, maybe, clean the installation process and all those paths, links etc.?
Last edited by AdamK (2011-09-08 14:19:12)
Offline
Re: Multisite installation: configuration process
AdamK wrote:
1) why should TXP not try to write config.php by itself?
PHP should have no reason to have write access to Textpattern directory. Only read.
there should be an option, maybe marked as an advanced, on the configuration page: “it’s multisite installation”, which would add the requested
The initial setup could suggest it to be added, but it shouldn’t write anything. PHP shouldn’t have access to write to PHP files, that could then be executed. Such would be security issue if anything.
P.S. II: Why not to treat “single site” as a multisite with one site set? it would, maybe, clean the installation process and all those paths, links etc.?
It would break backwards compatibility, and the multisite setup isn’t exactly seamless, I personally don’t even consider it complete. It’s not even compatible with all core features and plugins.
Also it potentially takes extra server resources and adds extra requirements. Not everyone has access to symbolic links, and not everyone wants to deal with symbolic links, and maintaining the extra configuration.
Some might just want to manage multiple installation differently, for example directly with Apache’s VirtualHosts, or by just adding domain specific conditionals to config.php which then change the database connection details.
TXP should take care about wrong paths by itself.
Currently Textpattern 4.x isn’t even exactly aware of anything. Only thing it would see is the resolved link.
Last edited by Gocom (2011-09-08 14:47:45)
Offline
#3 2011-09-10 21:35:15
- AdamK
- Member
- From: Kraków, Poland
- Registered: 2009-08-11
- Posts: 47
Re: Multisite installation: configuration process
Thank you. I was not aware that “It’s not even compatible with all core features”. Is there any list of core features not working as designed in multisite setup? It would be a key list for me, there are 6+ sites in one multisite set here working on my server :/
Adam
Last edited by AdamK (2011-09-10 21:36:59)
Offline
Re: Multisite installation: configuration process
AdamK wrote:
Is there any list of core features not working as designed in multisite setup? It would be a key list for me, there are 6+ sites in one multisite set here working on my server :/
Not really. Everything will work just fine. It pretty much just symbolic links after all. An additional script, added later on without any tie-ins.
But as you probably have noticed, for instance Textpattern 4.x doesn’t offer option to set an URL that would point to the admin-side. It always expects that Textpattern is installed to /textpattern directory, relative to the site_url. Then when you use the mailing features (password resets, new account mails etc), links in the mails they point to incorrect location.
Also things like themes, as they are inside textpattern directory, and the location isn’t really movable (by default), are shared across sites. If a sub domain is used, public side login cookie isn’t created.
Last edited by Gocom (2011-09-10 23:40:06)
Offline