Write extend-deploy.txt

Summary update

A couple of thoughts on this:

a) We might want to cover both export/import of single config and the entire config system. Although a single config import can be problematic, because one config item can depend on others, so you'd have to import them in order (for example, a view could depend on a content type and its fields existing). I believe that the config system will tell you if something doesn't work on import though, so it's probably OK to cover it.

b) For the entire config system, you cannot export/import unless the destination system was "cloned" originally. See
https://api.drupal.org/api/drupal/core!modules!config!config.module/func...
for reference on that, although it doesn't really say what "cloned" means.

c) Presumably install-dev-making will give instructions on how to set up a "cloned" site that you can export/import full configuration with. I'll add a note to that issue about this too. #2541630: Write install-dev-making.txt Anyway, in this topic we can reference that one rather than explaining how to set it up.

Thanks. I rewrote the steps so that they cover the single item import.
I cover the full import in the Goals section. I am not yet satisfied with that, so your suggestions are welcome ;)

This looks good to me, for the single-item export/import, thanks!

The only thing I'd really change in the steps is the navigation: I think we can combine the navigation (in both cases) into one step instead of 3, like this:
In the _Manage_ administrative menu, navigate to _Configuration_ > _Development_ > _Configuration synchronization_ > _Export_ > _Single item_ (... path to this goes here...)

And maybe a screen shot or two would be helpful?

So... regarding the full export/import... The use case, I think, goes something like this:

a) You make a development clone of your live site.
b) On the dev site, you try out some config things, like making a new content type, with some new fields, and a view.
c) It works well, and you want to get all of that to the live site.

If you do this with single export/import, it will be very tedious. You'd have to figure out all of the components (fields, field instances, content types, display modes, etc etc etc), export them all one by one, and import them into the live site. Or you could use the Features module, which would give you a way to group the config things into a "feature". Or, you could use the full export feature: export the full config from dev, upload the zip to live, verify the diffs, and import/synchronize.

So... I think what I would suggest is that we make the following changes:

- Basically make this topic only cover single import/export, as it does now.

- In Goal: I think it should just say something like what you started with:
Take a view that you have created on a local development clone website and copy it the production website.

- Site prerequisites: I think we should say the dev site is a clone of production, not the other way around.

- Follow-on tasks: This is where I think it would make sense to mention what you'd need to do if you have multiple configuration items to export/import (such as a new or changed content type with new fields, as well as its default display and form, and mention the ordering that would make doing single export/import both difficult and tedious). Your choices would be:
* Full export/import - say it's similar to making a clone and direct them to that topic
* Features module https://www.drupal.org/project/features -- which lets you make a group of configuration to export/import/share together

Does that make sense?

Hm... Another thought...

Actually, making a full clone of a site means content + config, so I think you would do something like this: copy all the files to a new location, make a copy of the database, edit settings.php to point to the new database.

So that doesn't cover (I think?) later on copying all the config over. So I don't think we should just say "full export/import is similar to making a clone" and direct them to that topic. But I do think we could say "you can also do a full export/import and we're not covering it".

I processed your remarks in this new version of the topic.

We could add a site cloning to a list of future topics as it is not documented anywhere in the drupal realm.

Looking much better! A few suggestions still:

a) We don't want to refer to extend-module-install for installing Core modules like Configuration Manager. That topic is about downloading modules from drupal.org. We should instead refer people to language-enable, with text something like this:

See <<language-enable>> for instructions on installing Core modules.

b) In Site Prerequisites, since we're talking about a local dev site and the live site, I think we should be explicit about which site needs to have which prerequisites. So for these steps to work, I think both need to have Config Manager, the dev site needs to have the new view, and both sites need to have the Vendor content type that the view depends on, and all the fields that are used in the view.

c) At the start of follow-on tasks, I thought that the first paragraph was a bit confusing since it's not a task per se... So maybe start it with something like this, to replace the first two paragraphs:

The steps in this topic show how to export/import a single configuration item. However, often if you develop functionality on a development web site and want to transfer it to your production site, you will need to transfer multiple configuration items. For instance, if you developed a new content type with fields, you would need to transfer several configuration items for each field, one for the content type itself, and possibly multiple view mode and form mode items, and they would have to be transferred in the right order. Getting this right can be both tedious and difficult.

d) Site cloning is covered in install-dev-making:

How to make a development copy of your site, using a database clone so that configuration can be exported/imported between live and development. Cover settings.local.php for config overrides. Follow-on task: extend-deploy

Here's a new attempt. I changed the requirement for the Vendors view.

Looks good to me, thanks! Added to the guide.