We refuse to help anyone in a different proletarian camp.
No seriously, NEFAC's drupal expert moved to the western hinterlands, so we might need some help for the next upgrade.
Drupal and websites
If you wanted to be clever you could make it a multisite install with iww.org, share the server space and resources, allow for future multi-sites for different regions/sub sites later on all from one code base with separate databases, themes and module setups so you'd still have lots of control over each one.
This book looks interesting:
http://www.apress.com/book/view/1590597559
I got a book from them for work stuff and it was pretty good, so I'm gonna get a copy when I get paid.
fwiw, looks like a very large number of indymedia sites are going to move to drupal fairly soon. With a bit of luck they'll contribute code back to the community rather than doing some weird fork thing.
http://www.nymaa.org is drupal
catch wrote:
If you wanted to be clever you could make it a multisite install with iww.org, share the server space and resources, allow for future multi-sites for different regions/sub sites later on all from one code base with separate databases, themes and module setups so you'd still have lots of control over each one.
I have a plan do you want to help me with it?
PS: I <3 drupal.
Stripey:
http://drupal.org/project/domain
Most IWW sites are tiny, and duplicate stuff from the main one. This way, you can do all that with one drupal install, one database.
The developer is looking for testers so I'd dive in and start submitting bug reports. install profiles are a nice idea, but they're quite limited in the way they work at the moment and some developers are talking about abandoning the current system for something else, so might not be a long term solution and someone's going to have to update all of those individual installs one by one every time there's a security release. You may or may not know we got hacked 18 months ago - that was because we ran 6 different CMSes (one for each section pretty much) and didn't keep them all up-to-date effectively.
If you decide to stick with the install profile idea, you could at least use a multisite install - have your one codebase with the install profile in it, then each new site is just an extra database and apache virtualhost. It'd be a middle ground, and you'd still be able to split sites off later if you needed to more easily whilst saving $s on hosting. I reckon domain looks pretty damn nice though.
Either way means you can have us.iww.org biroc.iww.org iu620.iww.org iww-ottawa.org - all look different, all share as much or as little content as you want, all maintained on one server with one hunk of code to worry about.
edit: I just realised you may not have any direct control over iww.org, which is a whole 'nother issue. Anyway the advice stands.
Catch:
Yeah I have been pretty bonbaffled by the whole install profile thing. The more I learn about them, frankly, the less useful they seem. The multi site install has been lurking at the periphery of my thoughts, I will investigate further.
I had also given consideration to the nightmare that would be updates with not much by way of constructive solution.
I've kind of been plugging away at this alone, with an unfortunate absence of critical thought. You know how your own thoughts can wind themselves around themselves after a while eh?
I have no control whatsoever over iww.org That website is a whole different kettle of fish.
Yeah I thought install profiles were going to solve a whole load of problems with drupal core about 6 weeks ago, then I read up about them and sadly not.
Mutli-site install is a completely different thing - it takes 5 minutes per site (or less) and has been in Drupal for 2-3 years at least. It means only one lot of code, still different databases which you'd have to update.php on each time but a lot less work over all. Domain access module it's one database and code base pretending to be as many as you like though, hence why it looks handy..
Quote:
Audio settingsThe current PHP configuration limits file uploads to 4 MB.
There are two PHP ini settings, upload_max_filesize and post_max_size, that limit the maximum size of uploads. You can change these settings in the php.ini file or by using a php_value directive in Apache .htaccess file. Consult the PHP documentation for more info.
This is leaving me baffled in our Drupal install at the moment, it interferes with the rest of the file permissons we've created and is stopping me uploading a podcast on the CAW/Magna deal.
You don't need symlinks if you're running multisites as subdomains - unless your host does subdomains weirdly (which lots of shared hosts do).
Symlinks are weird, but yeah you can't make them via ftp. I've seen workarounds that do it via a cronjob (that you only run once) - could try that?
Also, if it's hassle setting up the symlinks, seriously, try domain access. It looks amaaazing.
I checked out the Domain Access project:
Quote:
Unlike other multi-domain modules for Drupal, the Domain Access module determines user access based on the active subdomain that the user is viewing, rather than which group or site the user belongs to.
That doesn't look useful to what I am doing. How would it be useful to you?
I think multi sites is the way to go for me... If it actually works.
Stripey wrote:
I checked out the Domain Access project:Quote:
Unlike other multi-domain modules for Drupal, the Domain Access module determines user access based on the active subdomain that the user is viewing, rather than which group or site the user belongs to.That doesn't look useful to what I am doing.
Instead of running a multisite install with a different database for each site, you can run one installation, and have completely different content in each subdomain - and share some content if you like as well. So it's like multisite, except it's actually one site that looks like lots of different ones. If you actually need them to be completely seperate sites though, just ignore me 
Also - never tried this, but relatively easy way to make symlinks when you don't have shell access: http://trac.symfony-project.com/wiki/InstallingSymfonyOnSharedHostNoSsh
Stripey wrote:
Except I used a separate database for the new site... I would like to be able to share users through different sites so different wob groups can share with each other... I'm going to try redoing it with the existing database see what happens.
That's what domain access makes really easy using just the one db.
To share users with multisite - you have to prefix some tables and not others, it's pretty complex.
Alternatively, you can use the OpenID module - people won't be logged in on every site, but they can use the same username/pasword.
OpenID is looking like one option... I've been reading a bunch of people saying Single Sign On module isn't worthwhile. Seems like there's a hack in settings.php to do what I want but I'd rather get someone who knew a bit more about mySQL and security to look it over before implementing...
I don't think it'd be too much of a security risk, but you could easily kill your site doing that and have a lot of trouble fixing it.
This one looks alright if you have MySQL 5 (and if you don't consider changing hosting): http://drupal.org/node/37075 Otherwise I'd very much steer clear of hacking your database schema unless you really, really want to learn loads about databases.
Otherwise probably OpenID or, can I say it again, domain access.
Hey I just got the sharing of user files but not others going for my test site... Use these instructions http://drupal.org/node/139968 and also gleaned a bit from http://osdir.com/ml/db.mysql.windows/2004-11/msg00178.html for instruction on how to rename already-existing tables.
Seems like it's working...
*knock on wood*
There's a few website help threads at the moment, figured it'd be worth creating one overall thread so the information is easy to find.
Also a large number of sites are now using Drupal (and I get occasional questions about bits we use on here) - off the top of my head, libcom, NEFAC, ICC, IWW, EKS, mute, also some indymedia sites and infoshop uses it. Obviously some of the groups on that list despise each other, but if there's common issues people are finding with it it wouldn't do any harm to discuss those.
I don't have time to give detailed tech support - that's what drupal.org and google are for
but if you have quick questions ask them here.