In Context UI, I created a content title of "Header / Footer" without really noticing it's a machine name.

This generates the edit URL of "/admin/structure/context/list/Header / Footer/edit"
Which leads to a "Page not found"

The simple fix if someone makes this mistake is to rename the "name" of the context in the database to not include / characters.

I suggest making machine names follow the other the typical list of I see in CCK - upper / lower letters, hyphen, underscore.

(A feature request to consider would be to add the CCK feature were it auto-generates the machine name as you type the normal name)

Thanks

Comments

febbraro’s picture

Status: Active » Closed (fixed)
Mark Trapp’s picture

Status: Closed (fixed) » Needs work

The fix for this issue caused a regression: #1170780: Edit context: A context with this name already exists...

febbraro’s picture

Status: Needs work » Closed (fixed)
damien_vancouver’s picture

After updating to from 7.x-3.0-beta1 to 7.x-3.0-beta2, none of my context names are legal any more - all of them contain spaces and mixed case. Looking at the commit from #1 I don't really see how it ever allowed spaces before, but it did!

So now -

If I open a context and try and edit anything, I can't save it, because I receive the error:

Error: The name can only consist of lowercase letters, underscores, dashes, and numbers.

On the Name field. Unfortunately I can't edit the name field, so I'm unable to modify the context at all.

There's two workarounds to resolve this issue:

-One workaround is to delete and recreate the context with a valid name.

-Another is to modify the context names in the database using the SQL query:

update context set name = lower(replace(name, ' ', '_'));

You must hand edit any remaining illegal characters, like / or : , that are in your context names. This is easiest done with a tool like phpMyAdmin where you can browse through the context table looking for invalid characters, after you run the above query to clean up spaces and case.

After the above, my contexts were editable again.

febbraro’s picture

So should the release have an update hook to run that SQL to make sure that is anyone made a bad context name it would get at least transformed into a valid name?

damien_vancouver’s picture

@febbraro - yes, that would definitely be helpful, but I think it's a more difficult problem than it may at first seem.

We'd want to make it handle absolutely any bad characters, which would best be done using database-specific RegExp functions. That probably isn't something we can easily do via the DB schema API. Even simple replacing of characters without regular expressions is a database specific thing. MySQL vs. PostGRES, vs. MSSQL etc. all handle it with different functions and syntaxes.

One option I thought of is just parsing through the contexts in the database using PHP. The Schema API will definitely allow for that, and we could just do the regexp replacement of each context's name one at a time during the update. It may be slow or prone to timeouts for sites that had a large number of contexts, but it'd definitely work (and probably fast for 99% of people).

damien_vancouver’s picture

@febbraro Another thought - could we just make the name editable in the context edit form (currently it's not)?

Then if people had invalid names, they would get the field validation error and could just fix it manually. Old contexts would continue to work until you edit them, at which point you'd have to fix the name to continue working.

mattyohe’s picture

I too was caught in the migration with spaces in each of my context names. As a temporary fix for those looking for one... you can likely just clone your contexts and give them appropriately titled names, then delete the older contexts.