Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.http://staging1.drupal.org/admin/reports/event/66076
http://staging1.drupal.org/sites/staging1.drupal.org/themes/dmitrig01/bl...
http://staging1.drupal.org/admin/reports/event/66070
call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'drupalorg_home' was given in /var/www/staging1/htdocs/includes/menu.inc on line 348.
I am concerned that we aren't checking out the sandbox themes correctly so they can be selected by administrators. The implementers are waiting to start working, and we need to have their sandbox themes showing up on each site.
http://staging1.drupal.org/admin/build/themes
This shows only two copies of blue cheese, and I can't tell which one is the official branch of BlueCheese and which one is a sandbox. Can we put the path in the description?
Comments
Comment #1
Amazon commentedI toggled the themes and it's no longer giving an error, but it's not configured or set-up correctly.
Comment #2
rfay@amazon, we are *not* checking out themes correctly. Right now, there are two devs and they have "bluecheese" themes in their directory. Currently, their directories have the highest priority, and one of their bluecheese themes is the one that gets used. And it's of completely unknown lineage.
A critical element of our approach is to get developers to change their theme name to _bluecheese. That could sort this out. But we can't have multiple themes of the same name in different paths on the same machine and get much done. The highest-priority one found takes over the namespace.
Comment #3
rfaySee #644810: Process sandbox themes on staging.drupal.org so they are different per developer for my solution to the theme name collision issue.
A short-term solution is to get dmtrig01 to change the name of his theme. His is the one that is conflicting. I'll try to catch him.
For now I have deleted his directory, and since svn access is broken #644782: svn (subversion) access denied for everybody, it won't check out for the time being.
Comment #4
rfayWith dmtrig01's consent, I deleted his bluecheese theme in his sandbox in svn. So that issue is taken care of.
The front page is still broken on staging1, but calebg wants to preserve that database without changing it, so I don't really want to mess with it right now.
I tried to downgrade svn to the revision before branching (2002, I think), but it didn't exist in the new 'redesign' branch.
As soon as calebg is ready, we can reload staging1's db and run update.php and that should straighten this out.
Comment #5
rfayMarked staging1 as off-limits in the site status page.
Comment #6
calebgilbert commentedFyi, when we've decided that all the stuff on staging1 is no longer relevant, we won't have to worry about too much in terms of updating it. Well, just bring in the new db, svn up it, and enable the staging install module which will do most of the rest. I don't think it will even need update.php run after that. (this is the nice thing about bring in production db *and* files at the same time)
Comment #7
rfayUpdate.php will definitely have to be run, as we do have updates in our code tree which are not in production. In staging_drupal_org if nothing else.
So here's a proposed checklist:
1. Load the new db
2. drush enable staging_drupal_org
3. update.php
Comment #8
Amazon commentedI'd still like to see the front page configured correctly. We probably need to reach out to Todd or Katherine.
Comment #9
rfayStaging1 has been *deliberately* left broken per calebg. He's trying to preserve the old database.
When he's happy with our situation, it will be reloaded.
Staging1 is clearly marked on the status page as off limits.
Comment #10
rfayStaging1 has been reloaded and is fine now.