HtmlArea for Publish Log


#1

Screenshot%20from%202019-10-16%2009-21-22

I don’t know if it would become too polluted but is it possible to change this field into a HtmlArea one? We would like to make more elaborated publish messages and the idea of having it direct in there is very appealing. That said, as the actual one is implemented, maybe a separated input that could be accessed via a button from there and would then on publish generate a content with the info about the node, the commitId and/or versionId and our rich text message in it would be great.


#2

Sorry Kainzen. This is intentionally made to be a simple text string. I have a hard time imagining why you would even need it to be an HTML input.?


#3

I’ve been working with HDIR and was asked if it is possible to make a more elaborated publish log and since they want that to occur at the time of publish I don’t think any workaround would do. Is there a way for me to add a second modal when clicking on publish? Like a pre-publish. I’ve could add a htmlarea for that in the content-type but that wouldn’t be the same.


#4

Nope.
Rather advice your clien on how to use a committ log effectively. :slight_smile:


#5

I too believe it isn’t the function of the commit log but, since it was added there and thinking on the purpose of the application that I’m working with, I see that some times when we publish a content, there is a good amount of changes that we would like to register, almost like a changelog.
And since the field is there it would make it simpler and easier to use if it was a htmlarea rather than some workaround (even though it would be a mess in the version history). But that aside, think it would be possible in the near future that we could have another form something like submit in a content-type and that would only appear either before save or publish?
Thanks for the consideration.


#6

There will be support for somting we call an “approval step”. Basically, when a user wants to mark an item as ready/publish - the approval steps may kick in and then enable custom handling and storing the result of the approval.

This sounds like something that might actually solve your problem.

PS! Approval is done on a “per content basis”…