Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMS editor improvements #233

Closed
3 of 6 tasks
jimafisk opened this issue Nov 5, 2022 · 4 comments
Closed
3 of 6 tasks

CMS editor improvements #233

jimafisk opened this issue Nov 5, 2022 · 4 comments

Comments

@jimafisk
Copy link
Member

jimafisk commented Nov 5, 2022

CMS issues identified by @stephanieluz:

  • Delete is too easy (need popup confirm)
  • Ampersands written out in editor when using plaintext
  • Have to add a forward slash when uploading new images (not checking baseurl properly)
  • When uploading new images, if pane changes (e.g. switch to code view then go back to visual mode) the image disappears
  • Making edit in visual and then adjusting in code editor causes some changes to disappear (@stephanieluz needs test more to figure out exact details)
  • Resolve image name conflicts (there already exists a ticket for this: Naming conflicts for existing media files #221)
@jimafisk
Copy link
Member Author

I wrestled with fixing the plaintext fields to stop getting unwanted HTML and encoding artifacts. I thought it would be easiest to just use a regular text input, or more appropriately using a textarea since that's what these fields were made for, but getting this to resize correctly was maddening:

<script>
    import { onMount } from 'svelte';
    export let field;
    
    let textarea;
    onMount(async () => {
        setHeight();
    });
    const resize = () => {
        setHeight();
    }
    const setHeight = () => {
        //if (textarea.scrollHeight > 30) {
            textarea.style.height = 0;
            textarea.style.height = (textarea.scrollHeight) + "px";
        //}
    }
</script>

<textarea 
    on:input={resize}
    bind:this={textarea}
    bind:value={field}
></textarea>

<style>
    textarea {
        resize: vertical;
        width: 100%;
        box-sizing: border-box;
        border: 1px solid gainsboro;
        height: 30px;
        padding: 6px;
        font-family: sans-serif;
        font-size: small;
        scrollbar-width: none;
    }
    textarea::-webkit-scrollbar {
        display: none;
    }
</style>

This ^ generally worked, but there was weirdness around loading the appropriate height initially (once set, you could remount the component fine) and the padding caused a slight scrolling effect that was unwanted.

So I thought maybe we should stick with the original contenteditable element and on:input remove the HTML:

<script>
    export let field;
    const stripHTML = () => {
        // Remove HTML here...
    }
</script>

<div
    class="textarea"
    role="textbox"
    contenteditable=true
    on:input={stripHTML}
    bind:innerHTML={field}
></div>

<style>
    .textarea {
        background: white;
        border: 1px solid gainsboro;
        resize: vertical;
        overflow: auto;
        padding: 7px;
        font-family: sans-serif;
        font-size: small;
        white-space: pre-wrap;
    }
</style>

But that was over-engineering as well. Ultimately doing a simple bind:textContent instead of bind:innerHTML content was the way to go; sometimes I like to make easy problems hard 🤦.

@notramo
Copy link

notramo commented Nov 25, 2022

Deletion shouldn't display a popup: https://alistapart.com/article/neveruseawarning/

@jimafisk
Copy link
Member Author

I hadn't thought of using an "undo" function like gmail's undo send extension. It would be easy enough to implement with a timeout function.

I had also thought about using a multi-function, dropdown button that defaults to "cancel" instead of "delete." That way someone would have to consciously switch to the delete option before using it. Drupal uses dropdown buttons to group related operations.

I'd also like the success / failure on save to be more apparent. Currently the save button flashes "changes committed" or "could not commit changes" but you'd have to be paying attention to even notice. At the very least we could change the button from its default blue to green on success and red on failure to provide a visual queue.

jimafisk added a commit that referenced this issue Dec 28, 2022
@jimafisk
Copy link
Member Author

jimafisk commented Jan 3, 2023

Release v0.5.24 has:

  • Confirmation tooltips on delete actions
  • Ampersands and other characters are no longer getting encoded
  • Baseurls should be set properly when uploading new assets
Confirmation tooltip when deleting JSON content

json_confirm

Confirmation when removing media assets and links to content referenes

media_confirmation


Remaining items from this ticket:

When uploading new images, if pane changes

This still needs to be addressed, I created a separate issue to track progress: #247

Making edit in visual and then adjusting in code editor causes some changes to disappear

I need more details on this, so @stephanieluz if that's still an issue can you please open a new ticket with details

Resolve image name conflicts

As noted previously, there's already a separate issue for this: #221

@jimafisk jimafisk closed this as completed Jan 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants