Rename edit module to quickedit

"Inline" is rather vague too. What about "Inline editing" or "In-place editing" which are more descriptive of what the module does?

Inline editing - would be good. I don't think "In-place" has any meaning?

Originally, this was called ipe.module, the human-readable name being "In-Place Editing". But, as implied on the project page, it was renamed to "Edit" to not conflict/confuse people with Panels' pre-existing "Panels IPE" functionality.

That may have been a reasonable justification for Drupal 7, but as a Drupal core project, core should use the most logical namespace and contrib should adjust. I remember we had the same discusion about what to do because we needed a name for the Image module. Of course there was a contrib project named Image already. Though the contrib Image module was dying already, I don't think anyone regretted that core got the proper namespace. Panels IPE and IPE aren't in direct conflict anyway.

However, even with that whole argument, I don't think IPE is a good name anyway. It would be preferable to avoid obscure acronyms that require people either open the .info file or Google it.

I'm also a proponent of "Inline editing" module, using "inline" for the machine name. The current project Inline would be better named as "Inline filter" IMO anyway. We should probably ask @sun about this, since it's one of his modules.

#4: the machine name would have been "ipe", as in ipe.module; the human-readable name would have been "In-place editing". That is pretty much the same as what you propose: "(Inline|In-Place) Editing" as human-readable name, (inline|ipe) as module name. Note that the Inline module is moving away from being a filter (but that's a whole other story), so it will likely be inappropriate to rename it to "Inline Filter".

I agree that "Panels IPE" and "In-Place Editing" could hardly be considered conflicting names, but that's the way it went.
Your point about acronyms (which is against "IPE") is a good one, though I very much like the brevity (of "IPE").

Personally, I don't have strong feelings about this. I also don't think we should spending our energy on this right now. I propose to postpone this until after Feb 18; unless strong consensus is reached here and there are solid reasons to do it sooner.

I would like to see inline_edit.module. That way it doesn't squat on http://drupal.org/project/inline, which does something entirely different, or ipe.module from Panels.

This has become even more confusing with the addition of editor.module

In the UI it is called "Quick Edit". So I'd definitely prefer quick_edit over inline_edit. Even more so because we've standardized on "In-place" editing, not "Inline" editing.
Also: AFAIK there's a strong preference for 1-word module names (i.e. no underscores). Neither makes that possible.

Overall, I still prefer "ipe": an abbreviation for "in-place editing" (also see #5).

So over in #1987140: Add a dedicated @InPlaceEditor plugin annotation, it's shaping up that our annotation namespace is going to be @InPlaceEditor, which is descriptive and accurate. With the reduction of procedural code, longer module names aren't as inconvenient as they were previously. Edit currently only contains 10 procedural functions in the whole module. And now that the module name is no longer repeated in the plugin namespaces (and likely to be removed from the /lib directories when the dust settles in #1971198: [policy] Drupal and PSR-0/PSR-4 Class Loading), the module name being used anywhere other than in the namespaces and file names is becoming a rarity.

Basically all of that is to say we should probably not use an acronym. Unfortunately if we used underscores to match the camel-casing, this would end up being "in_place_editor", which is an awkward use of underscores. How about "inplace_editor"?

@WimLeers if you're really strongly in favor of ipe, that's still an improvement in my mind. I just don't see short module names as much a necessity in D8.

#1987140: Add a dedicated @InPlaceEditor plugin annotation brings us \Drupal\edit\Annotation\InPlaceEditor. Which means hook_edit_editor_alter() should probably be renamed to hook_edit_inplaceeditor_alter() (thanks to @tim.plunkett for pointing that out!). But at the same time, edit.module might be renamed here. So let's do that in one patch here.

Something like 'inplaceeditor' would be okay. It should probably be 'in_place_editor' though, even though that's a bit bulky. 'inplace_editor' seems inconsistent and therefore slightly error-prone.

So maybe Wim's proposal 'quick_edit', which I liked very much, remains an alternative, if we also expose it to the UI. It seems even preferable to suggest that this is meant to be only for quick edits, not a full replacment of the edit page.

However, all of these are better than the current name 'edit'. I just want to stress the DX (and partly even UI) importance of the filesystem name matching the UI name. It's really confusing otherwise.

Note that we'd might also want to rename the module currently simply called 'editor' (UI: Text Editor), making the differences a bit clearer, possibly 'rich_text_editor' or 'text_editor'.

I like the idea of making it simply quick_edit.module, so long as there aren't any hook_edit*() or theme_edit*() out there that we have to worry about colliding with... There didn't seem to be, searching api.d.o and drupalcontrib.org, at least. Still, maybe quickedit (as one word) would be safer?

quickedit +1
Lets please just do this

Also +1 to quickedit.

One more +1 to quickedit. It's distinct, obvious and nice.

Incoming!

First pass. I deliberately did not rename PHP or JS classes, interfaces, or methods. I also left some instances of foo.edit in the JS that looked to be something other than the module's namespace, but I don't know enough about JS to be positive.

Please review carefully.

Protip: git diff --color-words --staged

Mmm. There also needs to be a change made in standard profile, at least.

Yeah, #22 is broken when testing manually. Maybe let's just start with the module itself and its PHP namespace.

Alright, so the attached is at least functional for quick-editing the body of an article. No interdiff because it's a new patch. It changes:

• The module name.
• The service names.
• The namespace for PHP classes.
• The tempstore and cache keys.

The fact that this is a royal pain in the backside to roll is another good reason to make this change.

Cumbersome task, but as said in #27 that's another good reason to make it distinguishable.
Besides: Should the user-facing name be 'Quick Edit' or 'Quickedit'? Slightly preferring the latter, so it maps 1:1 to the machine-name, but in the end I don't care much.

We shouldn't map user-facing strings to machine names.

Re: the fails above: currently, stuff isn't getting attached to the page in EditController::attachments() because some dependency check is failing in drupal_process_attached().

Attached also doesn't resolve the issue.

This too.

Aha. This still fails, but later. The dependency check works at least.

Here we go. Missed updating the form callback name, which EditController uses directly with drupal_build_form(). We'll want to fix that at some point. I think @tim.plunkett might already have an issue for it.

I also changed the route names so that they're namespaced correctly while I was at it.

Manually tested--updating an article body works, with widget and everything. Yay.

Oh. Yeah. I haven't changed the class/interface/method names, but this still involves renaming callbacks, routes, services, and such, not to mention the module itself.

As the edit module is entirely new to Drupal core I think this is an acceptable post API freeze change as long as this is before beta releases.

With regards to the change - I agree that edit is a bad name for a core module (well any module) and quickedit is better

added why

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Re-namespacing the CSS classes is another whole can of worms, because the prefix edit- is used all over the place, and it's going to be just fabulous to untangle that and find out what is specifically related to this module. For the following reasons, I think we should defer updating the CSS classes to a followup:

• It's desirable to have the PHP-facing parts of this change done by Beta 1.
• The CSS and JS changes are not bound by API freeze.
• Efforts for #1921610: [Meta] Architect our CSS are still underway anyway.
• I don't think having the same CSS class names as before moves us any farther from a releasable state.

Same probably goes for the JS API. At least, I'd want @Wim Leers to review the JS changes himself, and he will be on vacation for the next two weeks.

Meanwhile, I'm going to take a crack at renaming the PHP classes, interfaces, and methods now.

Attach renames the following classes and interfaces:

Note there were some existing documentation bugs where Editor* was referred to as EditPlugin*, but fortunately most of them can just be replaced with {@inhertidoc} anyway.

I started to rename the EditEntityAccessCheck* family, but then looking at the code, it looks like these might refer generically to permission for editing entities and fields, rather than to quickedit specifically. So, I've left them for now.

More later.

Updated issue summary.

Great work xjm! Thanks for undertaking this. Another +1 for "quickedit".

If we want to go with 'quickedit' and not 'quick_edit', than those class names are not correct, they should be QuickeditPluginInterface and QuickeditController..

@xjm, I can review JS changes if you need before Wim comes back.

If we want to go with 'quickedit' and not 'quick_edit', than those class names are not correct, they should be QuickeditPluginInterface and QuickeditController..

I was hoping no one would notice that. ;)

Changing QuickEdit to Quickedit. :P

Updated issue summary.

The rest of the class renames, unless we also want to rename EditEntityAccessCheck and friends.

derp.

Updated issue summary.

mkay, going to rename the URLs next:

[tesla:drupal | Sun 19:00:47] $ grep -r "edit/metadata" * | grep -v "~"
core/modules/quickedit/js/edit.js:      url: Drupal.url('edit/metadata'),
core/modules/quickedit/lib/Drupal/quickedit/Tests/QuickeditLoadingTest.php:      CURLOPT_URL => url('edit/metadata', array('absolute' => TRUE)),
core/modules/quickedit/quickedit.module:  $items['edit/metadata'] = array(
core/modules/quickedit/quickedit.routing.yml:  pattern: '/edit/metadata'
[tesla:drupal | Sun 19:01:31] $ grep -r "edit/attachments" * | grep -v "~"
core/modules/quickedit/js/edit.js:    url: Drupal.url('edit/attachments'),
core/modules/quickedit/lib/Drupal/quickedit/Tests/QuickeditLoadingTest.php:      CURLOPT_URL => url('edit/attachments', array('absolute' => TRUE)),
core/modules/quickedit/quickedit.routing.yml:  pattern: '/edit/attachments'
[tesla:drupal | Sun 19:02:04] $ grep -r "edit/form" * | grep -v "~"
core/modules/quickedit/js/util.js: *   '/edit/form/%21entity_type/%21id/%21field_name/%21langcode/%21view_mode'.
core/modules/quickedit/lib/Drupal/quickedit/Tests/QuickeditLoadingTest.php:      CURLOPT_URL => url('edit/form/' . $field_id, array('absolute' => TRUE)),
core/modules/quickedit/lib/Drupal/quickedit/Tests/QuickeditLoadingTest.php:      CURLOPT_URL => url('edit/form/' . $field_id, array('absolute' => TRUE)),
core/modules/quickedit/quickedit.module:  $items['edit/form/%/%/%/%/%'] = array(
core/modules/quickedit/quickedit.module:      'fieldFormURL' => url('edit/form/!entity_type/!id/!field_name/!langcode/!view_mode'),
core/modules/quickedit/quickedit.routing.yml:  pattern: '/edit/form/{entity_type}/{entity}/{field_name}/{langcode}/{view_mode_id}'
[tesla:drupal | Sun 19:02:14] $ grep -r "edit/entity" * | grep -v "~"
core/modules/quickedit/js/models/EntityModel.js:      url: Drupal.url('edit/entity/' + entityModel.id),
core/modules/quickedit/lib/Drupal/quickedit/Tests/QuickeditLoadingTest.php:      CURLOPT_URL => url('edit/entity/' . $entity_type_id, array('absolute' => TRUE)),
core/modules/quickedit/quickedit.routing.yml:  pattern: '/edit/entity/{entity_type}/{entity}'

Updated issue summary.

Updated issue summary.

Updated issue summary.

Also renaming the quickedit_test helper module.

Updated issue summary.

Took a stab at renaming the asset library and thence Drupal.edit. Astonishingly, it still seems to work when I test it manually. Actually, I somehow reverted my patch on my local install. It's broken. Should have sacrificed that chicken!

Edit: A few comments will need to be rewrapped.

That interdiff is a lie. This is the real one.

Updated issue summary.

Fatal error: Class 'Drupal\edit_test\MockEditEntityFieldAccessCheck' not found in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/editor/lib/Drupal/editor/Tests/QuickeditIntegrationTest.php on line 151

Oops.

Note to self: update MAINTAINERS.txt in the next patch as well.

I used firebug today! I'm very proud of myself.

drupalSettings.edit is undefined
 url: Drupal.quickedit.util.buildUrl(fieldID, drupalSettings.edit.fieldFormURL),

Which leads me to:

[tesla:d8git | Sun 23:25:49] $ grep -r "drupalSettings\.edit" *
core/modules/editor/js/editor.formattedTextEditor.js:    this.textFormat = drupalSettings.editor.formats[metadata.format];
core/modules/editor/js/editor.formattedTextEditor.js:      url: Drupal.quickedit.util.buildUrl(fieldID, drupalSettings.editor.getUntransformedTextURL),
core/modules/quickedit/js/edit.js:}, drupalSettings.edit);
core/modules/quickedit/js/util.js:      url: Drupal.quickedit.util.buildUrl(fieldID, drupalSettings.edit.fieldFormURL),

...and changing the latter two makes it work! I totally just debugged JS.

Attached fixes that, and also fixes the test failure (which was unrelated).

So it occurred to me that I've only been testing as user 1, and not as any user with restricted permissions. I checked and the access checkers are not unit tested, nor is there test coverage for a user who has permission to use Quick Edit, but not to update a particular entity and/or field.

I tested manually by creating a user on a standard install that had permission to access contextual links, quick edit, etc. but no permission to edit articles. The Quick Edit link was correctly not shown. I did discover an unrelated bug, though. This is what happens when you have contextual links with no options:

This is what happens when you visit quickedit/entity/node/1 directly as a privileged user:

Fatal error: Call to a member function save() on a non-object in /home/se26a64e32e6f6b9/www/core/modules/quickedit/lib/Drupal/quickedit/QuickeditController.php on line 199

As an unprivileged user (who can use Quick Edit but not edit articles), it properly gives access denied. So that's good, at least.

I didn't test per-field access or any entity access more sophisticated than toggling "edit any article content".

patch changes JS files.

Reviewed the JS, should we change the theme functions name as well? currently we have a bunch of: Drupal.theme.editFormContainer Drupal.theme.editBackstage shouldn't that be Drupal.theme.quickeditFormContainer Drupal.theme.quickeditBackstage. Same for an id used in some ajax mess: edit-load-editors to quickedit-load-editors as well as the JS event name and more importantly the name of data- attributes which are still data-edit-id?

Anything inside a *.js file is incomprehensible to me, so: If you say so? :) I didn't know what the data- business was, so I didn't change it. Googling, there are a lot of hits in things that aren't edit.module for attributes called data-edit-id, so I don't know if it's some standard thing?

Similarly, I had no way if those JS method names were related to the module namespace or not. They're all confined to the quickedit directory, OK, but some seem to correspond to IDs and classes that haven't been renamed yet, so maybe it would make more sense to do those along with the CSS? I can't tell how they're called, and I also don't know enough to recognize when they're being used as callbacks. E.g., I'm guessing the following would need to be changed as well:

  html += Drupal.theme('editButtons', { buttons: settings.buttons });

(Both these things are reasons that it's really important to do this module rename. Also, I'm really wishing we had the automated frontend testing integrated into our testing infrastructure about now...)

[tesla:drupal | Mon 06:09:39] $ grep -r "Drupal\.theme\.edit" *
core/modules/quickedit/js/theme.js:Drupal.theme.editBackstage = function (settings) {
core/modules/quickedit/js/theme.js:Drupal.theme.editModal = function () {
core/modules/quickedit/js/theme.js:Drupal.theme.editEntityToolbar = function (settings) {
core/modules/quickedit/js/theme.js:Drupal.theme.editEntityToolbarLabel = function (settings) {
core/modules/quickedit/js/theme.js:Drupal.theme.editEntityToolbarFence = function () {
core/modules/quickedit/js/theme.js:Drupal.theme.editFieldToolbar = function (settings) {
core/modules/quickedit/js/theme.js:Drupal.theme.editToolgroup = function (settings) {
core/modules/quickedit/js/theme.js:Drupal.theme.editButtons = function (settings) {
core/modules/quickedit/js/theme.js:Drupal.theme.editFormContainer = function (settings) {
core/modules/quickedit/js/views/ModalView.js:         passed to Drupal.theme.editButtons().
core/modules/quickedit/js/views/ModalView.js:   * @see Drupal.theme.editModal()
core/modules/quickedit/js/views/ModalView.js:   * @see Drupal.theme.editButtons()
[tesla:drupal | Mon 06:12:09] $ grep -rl "editBackstage" *
core/modules/quickedit/js/theme.js
core/modules/quickedit/js/views/EditorView.js
[tesla:drupal | Mon 06:15:25] $ grep -r "editModal" *
core/modules/quickedit/js/theme.js:Drupal.theme.editModal = function () {
core/modules/quickedit/js/views/ModalView.js:   * @see Drupal.theme.editModal()
core/modules/quickedit/js/views/ModalView.js:    this.setElement(Drupal.theme('editModal', {}));
[tesla:drupal | Mon 06:15:49] $ grep -rl "editEntityToolbar" *
core/modules/quickedit/js/theme.js
core/modules/quickedit/js/views/EntityToolbarView.js
[tesla:drupal | Mon 06:16:04] $ grep -rl "editFieldToolbar" *
core/modules/quickedit/js/theme.js
core/modules/quickedit/js/views/FieldToolbarView.js
[tesla:drupal | Mon 06:16:20] $ grep -rl "editToolgroup" *
core/modules/quickedit/js/theme.js
core/modules/quickedit/js/views/EntityToolbarView.js
core/modules/quickedit/js/views/FieldToolbarView.js
[tesla:drupal | Mon 06:16:35] $ grep -rl "editButtons" *
core/modules/quickedit/js/theme.js
core/modules/quickedit/js/views/ModalView.js
[tesla:drupal | Mon 06:16:49] $ grep -rl "editFormContainer" *
core/modules/quickedit/js/editors/formEditor.js
core/modules/quickedit/js/theme.js

(Edited to just list filenames.)

So I guess those are safe for me to change, if we're OK from them diverging from class/ID names for the time being.

umm ok, let's do it in a follow-up if that's still possible at this point in time. There is loads of JS and like you said, some of it is tied to the CSS.

Attached changes those method names, but this line makes me nervous:

 *   - Array buttons: @see Drupal.theme.prototype.quickeditButtons().           

I didn't see that anywhere else... is Drupal.theme.prototype a magic thing?

Also, I guess this is the "event name" you're referring to? The foo.edit stuff I was afraid to touch?

$formContainer
        .on('formUpdated.edit', ':input', function (event) {

I'm definitely not qualified to make those changes.

Crossposted with #61. Phew. :) I'll revert #62 in the next patch.

Attached finishes off the PHP-facing parts by renaming the CSS and JS files.

Remaining tasks:

• Confirm with a maintainer that it's acceptable to undertake the rather enormous task of changing names in CSS, JS, and markup in a separate patch.
• Decide whether or not EditEntityAccessCheck and similar should be renamed.
• File followups for the missing test coverage and the contextual link bug.
• Thorough manual testing.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

FIled followups:

• #2047649: Update CSS, JS, and markup names for quickedit.module
• #2047659: Add test coverage for edit module access checkers
• #2047671: Expanded contextual links look goofy when there are no items

Let's get some code review and manual testing, please. :) Also, feedback about the access checkers (see summary and #39).

Updated issue summary.

+++ b/core/modules/quickedit/js/models/EntityModel.jsundefined
@@ -64,9 +64,9 @@ Drupal.edit.EntityModel = Backbone.Model.extend({
-   *   The state of the associated entity. One of Drupal.edit.EntityModel.states.
+   *   The state of the associated entity. One of Drupal.quickedit.EntityModel.states.

@@ -187,10 +187,10 @@ Drupal.edit.EntityModel = Backbone.Model.extend({
-   *   The state of the associated field. One of Drupal.edit.FieldModel.states.
+   *   The state of the associated field. One of Drupal.quickedit.FieldModel.states.

+++ b/core/modules/quickedit/js/quickedit.jsundefined
@@ -83,14 +83,14 @@ Drupal.behaviors.edit = {
-    // All in-place editable entities (Drupal.edit.EntityModel) on the page.
+    // All in-place editable entities (Drupal.quickedit.EntityModel) on the page.

+++ b/core/modules/quickedit/js/views/AppView.jsundefined
@@ -13,20 +13,20 @@ var reload = false;
+   *   - Drupal.quickedit.AppModel model: the application state model
+   *   - Drupal.quickedit.EntityCollection entitiesCollection: all on-page entities
+   *   - Drupal.quickedit.FieldCollection fieldsCollection: all on-page fields

@@ -51,10 +51,10 @@ Drupal.edit.AppView = Backbone.View.extend({
-   *   The state of the associated field. One of Drupal.edit.EntityModel.states.
+   *   The state of the associated field. One of Drupal.quickedit.EntityModel.states.

@@ -366,9 +366,9 @@ Drupal.edit.AppView = Backbone.View.extend({
-   *   The state of the associated field. One of Drupal.edit.FieldModel.states.
+   *   The state of the associated field. One of Drupal.quickedit.FieldModel.states.

+++ b/core/modules/quickedit/js/views/EditorDecorationView.jsundefined
@@ -45,9 +45,9 @@ Drupal.edit.EditorDecorationView = Backbone.View.extend({
-   *   The state of the associated field. One of Drupal.edit.FieldModel.states.
+   *   The state of the associated field. One of Drupal.quickedit.FieldModel.states.

+++ b/core/modules/quickedit/js/views/EditorView.jsundefined
@@ -83,9 +83,9 @@ Drupal.edit.EditorView = Backbone.View.extend({
-   *   The state of the associated field. One of Drupal.edit.FieldModel.states.
+   *   The state of the associated field. One of Drupal.quickedit.FieldModel.states.

+++ b/core/modules/quickedit/js/views/EntityToolbarView.jsundefined
@@ -132,9 +132,9 @@ Drupal.edit.EntityToolbarView = Backbone.View.extend({
-   *   The state of the associated field. One of Drupal.edit.FieldModel.states.
+   *   The state of the associated field. One of Drupal.quickedit.FieldModel.states.

+++ b/core/modules/quickedit/js/views/FieldToolbarView.jsundefined
@@ -48,9 +48,9 @@ Drupal.edit.FieldToolbarView = Backbone.View.extend({
-   *   The state of the associated field. One of Drupal.edit.FieldModel.states.
+   *   The state of the associated field. One of Drupal.quickedit.FieldModel.states.

+++ b/core/modules/quickedit/lib/Drupal/quickedit/QuickeditPluginInterface.phpundefined
@@ -34,7 +34,7 @@ public function isCompatible(FieldDefinitionInterface $field_definition, array $
-   * Will only be called by \Drupal\edit\MetadataGeneratorInterface::generate()
+   * Will only be called by \Drupal\quickedit\MetadataGeneratorInterface::generate()

These are some comments that need rewrapping.

Updated issue summary.

1. I'm fine with renaming "edit" to "quickedit" if that makes everybody happy. I don't care much about the name. It was "ipe" first (short for "in-place editing"), only then "edit". (All of which I already said in the first few comments of this issue.)
2. It was Dries who found the current name "edit" to be the best. You should get his approval before anything else. I don't understand why that was not done first, before working on actually changing all the code…
3. I will point out that "quickedit" is inconsistent with every other module name in Drupal core, "quick_edit" would make it consistent. We always put an underscore between two words in Drupal core modules. So, please go with "quick_edit" rather than "quickedit".
4. I'm extremely firmly opposed to doing this in multiple patches. That will leave it in a messy state. That's also how this happened: "Editor* was referred to as EditPlugin*" -> tim.plunkett did this in #1391694: Use type-hinting for entity-parameters ;)

• #2047649: Update CSS, JS, and markup names for quickedit.module should be done as part of this issue.
• See #2047659-1: Add test coverage for edit module access checkers regarding why I think it is usless to add additional testing coverage for Edit's access checkers.

Need work for 1) "quick_edit" should be the name for consistency, 2) all the changes should happen in one patch.

Thanks @Wim Leers!

Need work for 1) "quick_edit" should be the name for consistency

The problem with this is that it causes namespace conflicts, e.g. like there has been admin_menu(). The word "edit" in particular is a danger. Fortunately, it's now an easy string replace for the changes in there either way.

I'm not capable of making the JS changes because I can't tell what's API and what's language keywords or whatever, so someone else will need to pick that up very soon if we want to get this in.

It was Dries who found the current name "edit" to be the best. You should get his approval before anything else. I don't understand why that was not done first, before working on actually changing all the code…

I used the name that you, as the component maintainer, suggested yourself, one that had a lot of consensus, and that's usually sufficient. Generally we only escalate to Dries in case of a disagreement. I did not know that Dries proposed the original name, and I also did speak to a core maintainer (@alexpott).

Updated issue summary.

Let's try to get some more feedback on quickedit vs. quick_edit. I'll replace with that name if there is consensus that I'm overestimating the risk of namespace collisions, but as someone who has been bitten by these problems in the past (just look at the contrib modules I maintain), I personally think that a slightly less "consistent" (but still entirely legible) name is a small price to pay for ensuring that doesn't happen. ;)

Meanwhile, re-incorporating the patch from #2047649: Update CSS, JS, and markup names for quickedit.module.

Oops, sorry, I missed that @Wim Leers asked that we still get approval from Dries on the name.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

Updated issue summary.

I'm totally for quick_edit over quickedit. Namespace collisions are a general problem that we failed to fix in D8 and should not block this. There's nothing specific that currently collides. If there's a quick.module in contrib or something, it will just have to be careful.

Thanks for looping me -- I care about naming. In this case, I'm ok with renaming the edit module to quickedit. I'd prefer quickedit over quick_edit.

I can't get the patch in #73 to apply at all. I tried applying to a commit to 8.x from 7 days ago, but that didn't work. I think someone who perhaps has a local branch with this patch applied will need to rebase that branch and bring it up to the current 8.x HEAD. The --reject version of apply is just to messy at this point for me to understand how to fix it.

Updated issue summary.

73: quickedit-1874640-72.patch queued for re-testing.

The Edit module has stabilized in early Q1 2014.

For more than two months now, edit.module has had the same set of ~15 issues. Therefore, if we are to ever do this rename, this is the time: when few patches get broken and beta is peeking around the corner.

We have Dries' approval in #77.

If the core committers give the sign, I'll work on the patch to rename edit to quickedit module. Tentatively adding the "beta blocker" tag.

More of a beta target, I think, but let's do it!

@Wim Leers said he can tackle this which makes a lot more sense than me doing it since he wrote the module. :)

Et voilà!

I failed at creating a patch. Here's the proper one.

Stupid!

87: quickedit-1874640-87.patch queued for re-testing.

#2240709: ConfigImportUITest::testImport fails when the module list changes

So per more recent chat shenanigans, #2240709: ConfigImportUITest::testImport fails when the module list changes is actually a hard blocker for this (and the test does fail locally with this patch as well).

87: quickedit-1874640-87.patch queued for re-testing.

The blocker #2240709: ConfigImportUITest::testImport fails when the module list changes landed, so retesting again. Yay!

I reviewed this locally by replacing all of "quickedit" "Quick Edit" etc with "edit" (which was a much easier task than I'm sure this was for you!)

The only remaining changes were doc block additions, line re-wrapping, and stale use statement deletions.

Looks good!

Nudging priority.

Committed 240392c and pushed to 8.x. Thanks!

Added a change record and updated:
https://drupal.org/node/2164623
https://drupal.org/node/1872284
https://drupal.org/node/2186583

#98: thanks! :)