#1753 - Improved cross-file editing

Identifier #1753
Issue type Feature request or suggestion
Title Improved cross-file editing
Status Completed
Handling member Chris Graham
Addon core_themeing
Description 1) Record meta-data tree

Have a new filesystem directory, themes/_meta_tree

The tree serves two purposes:
1) For convenient editing outside Composr (quickly finding related templates etc, double click to open files directly in text editor)
2) For storing relationships inside Composr, so we can show the navigation tree in the new themeing editor

This directory would be automatically constructed, and consist of a structure of directories and symlinks.

themes
<theme name>
_meta_tree
screens
<page-link>
<template name> (template tree encoded via directory tree, each tree node is a directory)
 {_self --> <template file for directory>}
_meta.txt (contains details of the node: for each time this template is a child of its parents what parameter name is it being inserted via and what GUID was used)
templates
_all
 {<template name> --> <template file>}
<addon name>
 {<template name> --> <template file>}
css
_all
 {<template name> --> <template file>}
<addon name>
 {<template name> --> <template file>}
javascript
_all
 {<template name> --> <template file>}
<addon name>
 {<template name> --> <template file>}
xml
_all
 {<template name> --> <template file>}
<addon name>
 {<template name> --> <template file>}
text
_all
 {<template name> --> <template file>}
<addon name>
 {<template name> --> <template file>}
templates-related
_all
 <template name>
 {<template name> --> <template file>}
<addon name>
 <template name>
 {<template name> --> <template file>}
css-related
_all
 <template name>
 {<template name> --> <template file>}
<addon name>
 <template name>
 {<template name> --> <template file>}
javascript-related
_all
 <template name>
 {<template name> --> <template file>}
<addon name>
 <template name>
 {<template name> --> <template file>}
xml-related
_all
 <template name>
 {<template name> --> <template file>}
<addon name>
 <template name>
 {<template name> --> <template file>}
text-related
_all
 <template name>
 {<template name> --> <template file>}
<addon name>
 <template name>
 {<template name> --> <template file>}

"<...>" denotes some variable property.
"{...} --> ..." denotes a symlink.

In summary the tree is recording a few things not easy to find in the current Composr:
1) Related templates (co-reference, e.g. FORM.tpl is seen on the same screens as FORM_SCREEN_INPUT_INTEGER.tpl)
2) Templates organised by addon
3) Direct symlinks to template files without worrying about where/if things are overridden
4) Permanently stored template trees on a per-screen basis
5) Extended contextual meta data the current template tree system doesn't show you

The tree would need to be automatically maintained with correct symlinks when anything was overridden.

The tree would 'grow' at run-time, as it picks up meta-data. However, only if an "Grow template meta tree" option was enabled or keep_grow_template_meta_tree=1 is set or special_page_type=edit_html_and_css is set. This option defaults to on and is filed under performance options.

In some cases 'templates' in the tree are actually Comcode pages.

2) Change page rendering tools

Remove the following page rendering tool links:
- Templates
- Template tree
- Contextual CSS edit: *
and replace them with an "Edit HTML and CSS" link

Remove all the code relating to the templates/template tree view modes.

As per the current "Contextual CSS edit", choosing "Edit HTML and CSS" will establish a preview-anchor.
It will also refresh the main page with special_page_type=edit_html_and_css before opening the child window (in fact, special_page_type=edit_html_and_css adds some special JavaScript code to open the child window, as otherwise we couldn't broker that through a refresh-operation).

The child window would be opened with knowledge of the page-link it is for. This will open the new themeing editor expanded to show opening links for screens\<page-link>

3) New themeing editor

Merge the CSS and Template editor code, and add support for page editing too.
Rip out editarea and add Ace Editor instead (contingent on this being implemented separately); page editing would still use CKEditor. The correct editor would be openable on a per-tab basis (i.e. you can have different files in different tabs).

Do a major revamp of the editing UI. Use jquery-ui for it.

Down the left would be a selection tree based on '1' above.
Hovering the mouse over a tree node would show info from _meta.txt, and also the current override status for the file, plus some other meta data (who last edited it, and when, and what the file size is, and what addon it belongs to).
Clicking on a selection tree node would open a new editing tab (using AJAX).

On the right would be the editing tabs.

You could continue to restore old versions of files, but these would load via AJAX rather than a page-refresh.
The "Original" version of the file would be removed, as this could be incorporated into the old versions of files UI (we already have tooltip-based display of file differences).

The toolbar for template editing help would continue to exist.
We would enhance the "insert parameter" UI by auto-scanning screen previews to find what parameters are used by the template (I think we currently can only auto-fill this by scanning the template file, which may not include all possible parameters; although this should still exist as a fallback if there is no screen preview available).

The list of GUIDs would continue to exist.

The help/advice bar would be removed, and instead this information would be incorporated into the main front page for admin_themes.
We may want to add some links into HTML tag references guides, and CSS references guides, on a per-editing-tab basis.

Saving would be done on an individual-tab basis. It would always be save and stay, there'd no longer be a 'save' button that navigates away. Save and stay would be reimplemented using AJAX. If people want to manipulate individual files without browser JavaScript support, they can use /code_editor.php -- put out an accessibility message about this.
Tabs would have to indicate with a '*' if they contain unsaved code. Navigating away would present a window.confirm, checking that you are okay with losing unsaved changes (only if there are unsaved changes though).

4) Previewing

There'd be a list of different ways to preview. Each screen preview a template is used in, and each page-link it is recorded used in, would be offered up as a preview option. The default would be what the addon_registry hooks recommend for the template -- or, if a preview-anchor exists, the page-link from that preview-anchor.

The explicit viewing of a preview would open in a preview window (a third window), NOT the preview-anchor window, regardless of the page-link for the preview-anchor is being previewed.

5) Live highlighting

The CSS editing tabs would inherit the existing live highlight code for selectors, and the live preview code for CSS changes.

The template editing would not have live preview, but hovering over the selection tree would result in highlighting of any HTML DOM nodes directly under the template being edited. This might work with a glow effect.

To establish the relationship between HTML output, and the templates, a special encoding scheme has been devised. We will use invisible unicode characters to wrap around the start and end of each template. Specifically this will work via a binary encoding scheme around the x200b and xfeff characters. We will put <template name>...</template name> around each template but encoded using the special invisible encoding scheme, so that the user doesn't actually see it, only our code does. The invisible markers will show if special_page_type=edit_html_and_css is set.

6) Template/CSS selection list

The list of choosing what template/CSS to edit, before getting to the template/CSS editors, would probably be removed. We would probably jump right into the editor.
Steps to reproduce

Related to

#1562 - Replace EditArea with Ace Editor
Funded? No
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".

Rating

Unrated