Store metadata to the image backend with "unique identifiers".

[bago]

One complex part of mosaico is that it doesn't simply let you simply "edit an html" but it needs more stuff: input <-> output is not HTML but JSON and HTML is an "export format".

With a traditional "editor" you have:
Empty => Tinymce => HTML => Tinymce => HTML

With mosaico io have
Choose template => Mosaico => Metadata+HTML => Mosaico => Metadata+HTML

Also, you have to put images somewhere...
Given we already need an "upload backend" for images, what if mosaico stored/loaded Metadata to its own image backend and then include a "reference" to the metadata in the output HTML? This way you could take the reference from an HTML and start editing the image from source and produce new html.

When you "export" your email it should compute an unique identifier, upload the metadata JSON with this identifier to its own backend, insert this identifier "hidden" in the output HTML (e.g: HTML comment or meta tag) and "give you" the HTML. It could also compute an md5 of the html and include this data in the metadata, so that when you try to edit again the html it can alert you if you altered the HTML outside from mosaico.

This way you could integrate mosaico with any "textarea", like Tinymce does and simply have an external service (mosaico backend) to store images and metadata.

[bago]

Once you have this and #58 then we could have a "textarea plugin" that give you the option to open an iframe-popup modal in the page with mosaico to edit the textarea content.

[bwl21]

Indeed, storing the work (Metadata + HTML) is a big issue and should be done through the server. The approach with the unique ID is cool. But usually HTML is exported pretty often (testmails etc.). So I wonder if every export should be recorded. We could add a kind of "Baseline Me" which would save the current work to the server and also create the ID.

Intermediate editor steps could still be kept in localstore to protect against loosing date because the browser window is closed.

see also #50

[bago]

Well, I think we can only store the metadata beucause the HTML can be generated again starting from that metadata. So it is a small file and can be also saved a new file for each "export".
The resulting html, instead, will be uploaded in the "textarea" (or anywhere you decided to export it).

Maybe we just need a "" comment inside the resulting html in order to be able to read the "source metadata" (samehash + ".mosaico" extension) from the mosaico backend (the rest of the HTML will be ignored, or, at most, checksummed to check it "matches" the metadata file).

When you export one more time then a new uniqid will be computed a new HTML generated including a new comment, then the HTML will be checksummed so that the metadata will be saved including the checksum.

[bago]

About #50, it is related but a different approach: here I'm thinking to a simpler scenario where mosaico is invoked to edit an HTML and gives you an option to export the result once you are done. So you don't save to the backend, you just "close&export" (in the interface this could be done with an "update and close" or "save and close" button).

[bwl21]

If we do this, then we also should maintain time stamps and a sequence number. Then the user can retrieve former versions.

Please do not use a SGML/HTML comment. They are not well accessible by parsers. a simple approach would be

<script id="mosaico.metadata" type="application/json">{"md5": "...", "mosaico_id"="...", "time": ".." ...}</script>

[bago]

a script tag in the html is a NO GO: it would make them blocked by spam filters. The only sequence we can use is an html comment, because others tags will depend on the "master template" and we have no control over their content.
We don't need to parse it with an html parser, on the countrary, we want to find it with a simple regexp, without the need to parse the html (as we don't care of what the html is).

[bwl21]

If we go this path, we could go further and add a link to the editor in test newsletters sent out. Next step then would be an annotation feature in the editor. This would allow to handle an integrated review collaboration process. Of course it needs to be supported by the backend. This could save comments in the database and editor could load comments via ajax and display the same.

To do this, newsletters need to be stored in the backend as "id" + "versionNr". Editor can then retrieve all comments for a given "id" or for a specific version or even for a range of versions.
The editor model also would require unique Identifier for Blocks such that the comments can be attached on block level.

[bago]

This sounds a little bit offtopic and overheading for this issue.

This issue is about making it easy to "drop in" mosaico where you edit html email content using a textarea, so for most CMS that currently simply add tinymce or ckeditor with their "fullpage" plugins and run them over a simple textarea.

This very specific solution is already big enough for me (as I don't need it for my embed use case) so the only chance I'll do that is that we keep its scope very narrow ;-)

[bwl21]

Sorry, I did not understand this particular focus. At the moment I am a bit desperate since I have no clue how I can setup an environment which stores/retrieves the edited newsletters on my backend and not in localstore. I also feel that index.html and editor.html is one html file too much :-)

It would be glad if the editor could be embedded pretty simple in an existing HTML or app which does all the save / provide template / test / ...

In such a scenario I would handle my use cases outside of Mosaico and use Mosaico for editing (and only for editing).

I will think about it and open another issue if needed.