Create new connector for Theme Editor
fjarrett opened this issue · comments
When changes are made to theme files via the Appearance > Editor screen these should be logged by Stream.
In fact, this could be one of the most important areas to track because it's the easiest place to completely break your site! 😩
- The connector name should be Theme Editor
- The file name should be stored in
stream_metaand appear in the Summary - The context should be the Theme name
Wouldn't it be cool if Stream included the diff? Wow, that's a slippery slope.
Yeah @westonruter has suggested this before, it would be quite involved! But awesome. 😎
I'm not sure if there is actions/filters for that, would probably need a workaround to log it.
I made it work this way:
- On client side, hidden textarea is created with
oldcontentname (as opposite ofnewcontentname of existing textarea) and contents of existing textarea - On
wp_redirectfilter, if it's Editor page and data is sent, real file contents are compared to$_POST['oldcontent']changes are logged.
I decided to do so, to make sure changes have been really saved to file, to prevent situation when there was some problem with the file while saving and we log unexisting changes.
Using wp_redirect filteris not most intuitive to use here, but it's the only one hook available after saving the file and I wanted to do it immediately.
I think showing changes is great idea - we would need to create space in database for that, because currently there are no fields of such capacity.
@fjarrett @shadyvb @lukecarbis I changed the way it works. It doesn't use client-side anymore. Instead, I made it use static field in the class, which keeps all needed data on load-theme-editor.php hook if only correct post data is found. Then, on wp_redirect this is compared to actual file contents and logged if it's different.
We would need to discuss keeping contents in database to enable showing diffs. My suggestion is to change type of meta_value field in stream_meta table from VARCHAR to LONGTEXT. This type is used in postmeta and usermeta anyway. That would be perfect place to keep contents or deltas - this is to be discussed.
Screenshot:
We would need to discuss keeping contents in database to enable showing diffs. My suggestion is to change type of
meta_valuefield instream_metatable from VARCHAR to LONGTEXT. This type is used inpostmetaandusermetaanyway. That would be perfect place to keep contents or deltas - this is to be discussed.
A concern with this is it would make stream_meta.meta_value largely unindexable, and so could slow down queries quite a bit. But I'm not sure how many joins are being done on meta_value fields.
@powelski @westonruter I don't envision Stream ever storing heavy amounts of previous values like this out-of-the-box. That type of functionality would probably best exist as a separate extension project.
+1 for @westonruter, this was decided on building the architecture, losing the index will slow down queries, was one of the reasons why we went for our own db tables.
Yea, so i guess just adding the record will be it for now, a filter would be great so others can hook in and see what changed.
@shadyvb Yeah that's right, I think the only requirement here (for now) is to add a connector and create basic records when changes happen.
Or what about storing the diff? Sure it would likely get truncated, but if you could at least see some context for what was removed or added, at least an excerpt of it, this could be useful. But yeah, also makes sense if this feature was deferred to something that could track the complete previous values.
@westonruter I think we should wait for the real extension then. 256 chars is very small to rely on, even for diff excerpts.
Guys, I'm opening pull request for this task. If you are thinking about any enhancements, please share your thoughts.
BTW, I needed to turn off similar feature of Installer connector. It logged jobs from Editor as well, but even if no changes have been really made.
@fjarrett Please review the pull request.