It’s funny, 4.x in Cascade & 4.x in Drupal seem to have been almost equally crazy, although in noticably different ways.
they came from home-grown CMS.
one of the presenters has a fairly noticable accent, another presentation I’ll have to do extra listening.
wonder if Luke was at the same early user conference that they were at.
default examples? (I’ve found some useful things in those files.)
I need to join the listserve(s). several ppl have mentioned it.
production & test – prod goes to 2 public load servers, plus a “QA” for seeing things in process. plus they have a test instance that also goes to QA server.
_common_ folder was for resources that actually go to the server, CSS, JS, etc. – with some aliases via httpd.conf
interesting image of their (old) folder structure. also, config setup diagram.
seriously, even with the “old” (global) way, their setup was pretty damn sharp.
[oh great. I need the damn access code to get online. thank goodness for the WP app.]
using PHP includes for some of their navigation? why use Cascade, then? Really.
wondering if I ought to have gone to the workflow session. it’s interesting, but I really want to see how they got to the next thing!
“Artemis” single source dynamic content delivery? Wonder what that’s about.
interesting analogy to his brother’s gas station moving from separate pumps to the single pump with buttons for different gas: a lot of time/work/money up front, but huge savings ove time.
they had ~390 templates, ~600 config sets, ~350 users. the hell? ok, even I know that’s crazy-pants.
test instance of cascade “took over” QA server for a while. Interesting.
still wondering if we could do site migration in stages.
started with shared assets site, moving _common_ to _assets site – again, for shared css/js/images – the underscore mostly just for alphabetization reasons. with global templates (2, could be 1), global content types/configurations, and sample content. still looks really complicated to me.
then the main sites and really complicated sites.
created site migration inventory spreadsheet. love that sort of thing.
new sites had their own content types and shared some of the common ones.
and a spreadsheet of users to create new roles & groups.
heck, if I can do what I want to do over the next year, I should submit a presentation proposal. I can’t be as mind-blowing as UCDavis, but I think I can do some pretty cool stuff.
data definition for google analytics keys, and then an index block, and data definition blocks. makes sense. although I’m honestly wondering if we should move all the e.e sites to the SAME GA key, since we don’t have as diffused needs. (OTOH, I bet there’s some groups that would really appreciate having their own separate thing. there’s a whole thing to talk about in re GA.)
should have gone to the workflow session. I still have no idea how the hell workflows are supposed to work.
now only have 2 templates, about 10 config sets, have increased to 450 contributors.
the common “site” thing was clever, but caused problems in test. not really sure what they did to fix, sounds like maybe they went back to aliasing. (altho we could probly get some speed boosts by having a subdomain for those sorts of assets.)
they were able to get schedules (time/day/room?) into Cascade. could I do something with R25 api? so that you wouldn’t have to log in to my.e.e? is that even a good idea?
q: share block content across sites? yes, like what they’re doing with the common thing. (this guy from alaska down the row from me was asking good Qs yesterday, too.) users to have to browse to the different site, but my instinct is that it’s like picking from a library.)
didn’t really understand the question.
q: did they investigate using web services to migrate? no, altho some ppl do.