Child sites are named with MAIN_ENV_NAME, not with child site name

[waldoj]

If I set MAIN_ENV_NAME to Acme Hosting, and stand up a CKAN child site named Ontario, that CKAN child site is named Acme, not Ontario.

[JackMc]

Hmm, the MAIN_ENV_NAME is something that I hadn't thought about people actually changing, to be honest 😊. It should be a valid datacats environment name (no caps, no spaces, etc) and will currently break the run.sh script if you change it. It doesn't really have that much impact on the actual thing that the users see, it's more of a detail that that environment is called multisite. I would love some input on how to make this more clear.

If you want to actually change the name of the site that's displayed to users, that setting is in the environment's development.ini file.

[waldoj]

Sure, the environment is called multisite, but so is every CKAN repository. They're all labelled multisite in big letters, no matter what you've chosen to name the repository:

That seems like bug. :)

[JackMc]

Oh. In the development.ini file, you can change the name of the site (site_title). (Line 107)

For changing individual site titles we need CKAN 2.4 which means we need a new release of the datacats tool (it's already in our master branch, but I want to keep this using only released versions of DataCats).

[waldoj]

Huh, so any site that's launched will have to have its Docker instance's development.ini file edited to keep it from being named the same thing as the hosting service? That's a big ol' speed bump in the path to automated deployments. Is the only publicly-visible effect of a child site's name in its URL's subdomain, then?

[deniszgonjanin]

There are a couple of ways to go here. The underlying problem is that too much CKAN configuration is stored in that ini file. Proper solution would be this: ckan/ideas#88

Other solution would be a temporary hack in multisite/datacats to allow changing ini settings easily.

[JackMc]

Not really. The site title (once we have a new release of Datacats) will be editable in the admin interface. The reason we need this for this to work is that it's a new feature in CLAN 2.4 to be able to edit settings in the database and the new Datacats release will include that
Sent from my iPhone

On Aug 7, 2015, at 4:47 PM, Waldo Jaquith notifications@github.com wrote:

Huh, so any site that's launched will have to have its Docker instance's development.ini file edited to keep it from being named the same thing as the hosting service? That's a big ol' speed bump in the path to automated deployments. Is the only publicly-visible effect of a child site's name in its URL's subdomain, then?

—
Reply to this email directly or view it on GitHub.

[waldoj]

Sure, I get that your powers are limited here. :) Hmm. So, at the moment, when you launch a new CKAN instance, you're not doing anything within that Docker container, right? You've just got a stock Docker container that you're replicating, and pointing Nginx at the port for that container. Do I have that right?

[deniszgonjanin]

@JackMc ah, are you talking about the new paster config-tool command?

That would let you run commands to change any config setting, so that would definitely do as far as automating site configuration.

[wardi]

Admins can configure their site name, even in ckan 2.3, from the ckan-admin config page http://(host)/ckan-admin/config

[waldoj]

@wardi, thanks for the reminder of that bit. Having a weird default site name isn't ideal, but the fact that it can be fixed by the user, without anybody delving into editing a config file, seems well within the confines of an MVP. :)