Rename admin/site-building to admin/structure

The following patch changes the name from Site Building to Structure in:
INSTALL.txt
simpletest.module
system.module
system.test

I wasn't sure whether to change the wording in INSTALL.txt and thought it was better to do so and then have someone else undo it later on.

I'm still really new at creating core patches so please let me know if I made any silly newbie mistakes.

OK this is good and nice catch on INSTALL.txt, but we also need to rename all admin/build URLs to admin/structure as well - you should be able to do a global find and replace on the whole Drupal directory for that.

Also, not introduced by this patch, but simpletest now lives at admin/development/testing instead of admin/build/testing - should probably change that since we need to change that line anyway.

Thanks for the quick feedback. I'll rename the admin/build to admin/structure and fix the simpletest path this evening and post an update tonight.

Here's a second try. When I tested the paths after clearing cache locally, I didn't see any remaining legacy admin/build paths.

Just wanted to add that the path for simpletest in INSTALL.txt should now be fixed as well.

The last submitted patch failed testing.

Setting to needs review because the last test never ran.

The last submitted patch failed testing.

Here's a re-rolled version of the same patch.

The last submitted patch failed testing.

Figured out that my code was out of date. Here's another try. Sorry for the confusion.

The last submitted patch failed testing.

Here's a fourth try.

The last submitted patch failed testing.

I'm gonna have a looksie in a few hours.

JuliaKM:

I am unable to explain why this patch should work when the previous did not. The tests pass on my setup so far, I'm 20% through and I've surely hit some of the changes with 0 failures. The only difference is the 'diff' lines that occur for every file:

Yours:

Mine:

I'm not an expert on what each line in a diff patch mean, so I don't know if this difference of the extra '-p' is significant. I also don't know if you have any control over it. I am making patches with this command from the Drupal root:

It's also possible that the test robot momentarily fell off the wagon!

Let's see what the test bot says about this one.

When in Paris, can someone take me to a tattoo parlor so I can have etched on my right hand a reminder to change the status to 'needs review' before I press 'save?'

The last submitted patch failed testing.

I am stumped! The patch applies cleanly. The tests succeed on my environment. The test bot blames us for it's failure to run tests. Has test bot gone on strike? Is this some kind of civil disobedience? WHAT ARE YOUR DEMANDS TEST BOT? We are prepared to meet them!

Chx showed me how to run tests from the CLI. I can verify that this patch does not break the ability to run tests from the run tests script.

The last submitted patch failed testing.

The test bot uses it's own simpletest script to actually install drupal and set things up before running tests - here's the patch to pifr which I think will stop tests breaking once this is in. Since it's never going to pass the test bot until it's actually in core, marking back to CNR.

#524954: Patch for admin/structure change

Could someone run the tests on their local host and confirm that this patch works? Once approved, this should be ready to be committed.

I'm running the tests locally (60% completed), and I pinged boombatower to be on stand-by to fix PIFR.

I am able to apply the bangpound's patch but get the following message during the process:
patching file modules/locale/locale.test
Hunk #1 succeeded at 1057 (offset -1 lines).
Hunk #2 succeeded at 1364 (offset -1 lines).

Does this still count as applying cleanly? Thanks bangpound for all of your help figuring out what was going on!

Committed to CVS HEAD and PIFR has been updated. Thanks!

Noone even pretends to justify this change in this issue. Thats not right. At least link to the discussion if it happenned elsewhere. Without any link, this looks just like a fiat and we don't work like that. I don't think this change is reduces UX or increases it. It does break thousands of web links and book pages and screencasts.

FYI juliakm, the offset notices are the result of HEAD source changes that were committed after the patch was made. The diff patch was "aligned" with line X but the patch applied at line X-1 for two hunks. Success is success even if it's a bit out of step.

Sorry to stray from topic. We now return...

I agree with Moshe and take some responsibility for posting a crap issue summary.

Here's brief background (I'm assuming Moshe actually knows where the stuff is and just wants the review process to work normally, but for the sake of anyone else coming in).

Main summary of discussions from the d7ux sprint (which I wasn't at) - http://www.yoroy.com/2009/reorganize-drupal-admin-items-within-d7ux-fram... and http://www.d7ux.org/d7ux-information-architecture-a-detailed-view/

#520444: Use a custom menu for top level toolbar links includes adding an alias for admin -> admin/config, we need to discuss how to make the other paths/sections work both in the toolbar and if it's disabled, I have vague ideas but need to summarize.

A few participants in usability testing have complained about Site building and site configuration being indistinguishable titles (when you configure a module, you're building your site, you build your site by configuring content types, views panels etc. etc.), I couldn't find a d.o. issue for this but one not very good example is http://drupalusability.org/node/50

I/A for config and modules is being worked on at #510110: IA : Configuration & Module - this doesn't include the structure path at all, but it will in the sense we need to move things in/out of structure from config and modules.

Automatically closed -- issue fixed for 2 weeks with no activity.

Adding tag.