 Hi everyone, welcome to the session Autosafe and concurrent editing in Drupal 8. My name is Christo Czonov, I'm a senior software developer and one of the official commentators of the Drupal 8. I'm a senior software engineer and one of the official Drupal 8 core commentators for the entity API. I am the author and main maintainer of several Drupal modules including the two that I'm going to present now, Autosafe Form and Conflict, branch 2.x. I work for Biologis Genetic Information Management, a company based in Frankfurt, Germany. We are a Drupal contributor and stated us in the survey made by Dris in his blog post who sponsors Drupal development. We are one of three Drupal end users who are sponsoring the Drupal development. So let's start with Autosafe Form. It's basically like the name suggests, a module that takes care of continuously autosaving an entity form. It basically consists of the user input and the state of the form. The module works out of the box but there are several configuration options like the Autosafe interval, how often the Autosafe submission will be triggered or to enable it only on specific entity types. Currently we support only content entity forms but with some custom content it's possible to add support for config entity forms as well. It basically works like when it decorates the form builder in order to turn off all the form functionality of Drupal because we basically need a raw input and we want to prevent all kinds of validation or hook invocation. We just need the raw input and we want to prevent the multi-step forms, updating the form build idea and all the complexity. We just turn all that functionality off and we create Autosafe states. They are based there per user which means they're not shared and they represent drafts. A new state will be created each time a change is made so it means if there are multiple Autosafe submissions but the page hasn't changed then there will be no new Autosafe states. This makes it possible to implement an undue array of functionality on top of it. The module behaves differently on entity saves dependent on that whether the conflict module is enabled or not. If it's enabled then only the Autosafe session for the current user and the current entity will be deleted otherwise all Autosafe sessions for this entity will be deleted because otherwise the user will not be able to save the form anyway because there will be conflicts and without conflict we cannot resolve conflicts concurrently it is not possible. Some of the future tasks that are on our plan are to make it possible to save Autosafe states in the browser local storage so that we preserve bandwidth and also make it possible to save Autosafe states without an active internet connection for example when somebody is in the train and is working on an article. There are some core conversations about implementing Autosafe states as forward revisions which unfortunately have a lot of technical limitations like not no constraints in the database for like missing values in specific fields or what about non-revisionable entity types currently AutoForm doesn't care if the entity type is revisionable or not so there like I've mentioned there is a core conversation and it's being considered for inclusion in core and for sure your ideas are welcome. Conflict it makes the concurrentity possible we support all kind of content entity types no matter if they're revisionable or non-revisionable and we like with Autosafe we haven't added support for conflict entity types the reason is that we mainly work with content entity types as well as the most of the Drupal users at least we think so that must not be necessary it's built basically as an entity handler which you can exchange and adapt to your needs but basically it offers it registers conflict entity builder in the entity form and then conflict detection is being performed using a three-way comparison and for that we use three entities the one is the initial entity that was has been used to generate the form the other one is the entity that is being built from the current form values and also the entity from the storage which might be already in a newer version that's concurrent editing we are talking about so after that we offer some default auto-merging and we have introduced recently on an event system for extended conflict discovery and resolution what we can auto-merge our fields that are not enabled in the currently used entity form displays fields that the current user doesn't have access to even if they're enabled in the form display because they're not being shown and the user basically cannot change them translatable fields from other translations to make it possible that different translators edit different entity translations which hasn't been possible in core until the introduction of conflict 2.x we auto-merge also entity metadata such the change timestamp revision metadata and all kind of stuff that actually happens under the hood in the entity API and at last we also merge the fields that have been changed in the current form or in the newest version but we do not merge such fields if they have been changed at both places why because this is actually a conflict so and the extended mechanism for conflict discovery and resolution is the event system that we use we have two events we have introduced two events for that first we fired entity conflict discovery event where we have the three entities that I've talked about named here left right and base and we add also a context for example the form form state from display and eventually you can add revision branch metadata the idea is that this system could be used also not only for concurrent editing but also for merging different revision branches so actually there is an issue on Drupal orc about something like this and it's been made a patch out of conflict to include it in core this system this exact way system so during that event we built a list of conflicting properties and after we are ready then we fire another event for automatic conflict resolution named entity conflict resolution when there we have the same as in the previous one but we have additionally the result entity on top of which we apply the changes and we also have access to the conflict list from which we can remove the conflicting paths or fields after we successfully resolve the conflict automatically or in some way semi-automatically or whatever so we have basic support for manual resolution we have dialogue based conflict resolution and in one base dialogue based is mainly for in one nested in one entity forms where like in a dialogue the user is offered with multiple steps to resolve the conflict for each of the entities or in one base which is mainly for regular entity forms however this is still working progress it works for us but if you need like a better user interface then I'm going to need your help something that has been suggested a while ago for conflict but unfortunately I haven't had the time to work on that but I still want to find that time is to make it possible to auto-merge text fields with defy lighting thanks to this library jQuery merge for DHPD it's being considered I've told you already for core inclusion a patch has been made and that's as part of the workflow initiative so after I've talked a little bit about that I'm just going to show it how it works I've enabled both just both of the modules on my day 7 8.7 installation and I'm working with two different users Margaret and Grace so I just go on the same entity form and I make some changes for example the preparation time Grace thinks it should take 20 minutes but no Margaret thinks it should take 20 minutes but Grace thinks it should take only 10 minutes so like we see when I exit the page and re-enter the edit form I can resume the editing the same will be offered to Margaret as well so when I resume here I have 20 and here I have 20 10 now when I save the form the other user could theoretically still edit the form like we see in the right corner right down corner how to save submissions are being triggered and now when I save there is conflict and I can either resolve the conflicts or start over and if I want to resolve the conflicts then I have this overview of the three versions that we had for the field and I can decide which one I have I want to have and just enter it or I could enter like value in between like for example 7 17 minutes and I have to confirm that I've reviewed this change and then after that I can save successful so that's basically how how to save and conflict work together in order to offer this editorial benefit there was recent like I told you I the question was about some more complex cases like when using paragraphs or next to the inline entity forms in general and we have our custom entity inline module which is also on Drupal work entity reference inline it's in a developer state but we tested it with it and it works perfectly there is some custom code that has to be added but it's just a whole implementation and recently there was an issue on the issue queue of conflict 2.x about paragraphs and somebody mentioned that it works when the paragraphs are open open but it doesn't work when they're closed I'm not really sure how the cost functionality is implemented in paragraphs but it might be that there you don't have an entity form and then it doesn't work so in that case I might need the support of the paragraphs maintainers because I'm not really aware of the internals of paragraphs but if they're willing to we can work together in order to make the module available for all paragraphs use cases it also work when one user has multiple types of sorry when one user has multiple types of editing the same document for how to say for for conflict yeah that doesn't really work correctly right now because you have then different submissions I'm not really sure how it will behave but there was an issue that we support that and I think it will be hard I think I might be possible might not but it will be hard I haven't thought on such issues case so layer builder uses an entity form so does this work with layer builder I'm not familiar with the layer builder layout builder unfortunately so I cannot speak for that okay sorry probably what might be some people could help test that on Thursday or something yes exactly and I will be all around so if you want to if there is something that doesn't work feel free to contact me and we can work it out together yes please so the question is if there are a lot of fields yes sure it works with a lot of fields in order to spare time because I have only 20 minutes I've just shown one field but it works with every field actually so I can have conflicts on all the fields and still this in wine form will be shown everywhere yes please I don't hear you sorry it works for all kind of types yeah that's there was a problem for because of that because it was defined the route for now that was defined through the controller directive and I made an in a page for Drupal 8 8 and it was committed so we drew power 8 8 it will work out of the box for now that it should work out of the box but there is also a page for that on the issue field that you have to apply as well so this is a functionality that will be supported in maybe couple of weeks or you can support me and work with me thanks yes please or first the other one because you already had question yes please layout builder the question was set to place previously I'm not aware of the layout builder so I don't know do you mean content moderation unfortunately doesn't the question was if it works with content moderation and unfortunately it doesn't really work with content moderation but the problems are in content moderation I recently created an issue in content moderation for that but it's basically for when editing the published version and not drafts but I guess we might need to work with the content moderation people and developers in order to make it work between both because that basically both create drafts and it's just different way and that are different concepts so yes yes please yeah so I was just curious if you have tested it with our name assisted it with custom field types so as if you have a farm where there is fields which have been a module has defined like custom field type of the custom widget would it work automatically those are would you need to do some good eyes and develop or need to do some modifications or have some certain constraints for my field type to make sure it worked I would say we have one of the most complex Drupal sites out there so with a lot of custom widgets four meters and everything and it's better feel tested okay great and the question was if we've tested it with custom fields and custom widgets any more questions anyone wait wait wait wait wait if you want to learn more about what we do at our company then I would like to invite you on Wednesday at another session from our company which starts at nine o'clock there you are going to be see really amazing stuff about genetic and content management systems and also please come to our boot we have brought an arcade machine and if you play backman you or any game and win the highest score you can win genetic analysis for free thank you thank you that's quite a useful demonstration I've I've been looking at potential Thursday there's an issue to get a generic revision UI revision roots into core like the ones yeah so yeah sure