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

Adding block in Code Editor mode produces placeholder markup #9807

Closed
iandunn opened this issue Sep 11, 2018 · 19 comments · Fixed by #9815 · May be fixed by makbarGroup/gutenberg#31
Closed

Adding block in Code Editor mode produces placeholder markup #9807

iandunn opened this issue Sep 11, 2018 · 19 comments · Fixed by #9815 · May be fixed by makbarGroup/gutenberg#31
Labels
[Feature] Code Editor Handling the code view of the editing experience [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Enhancement A suggestion for improvement.

Comments

@iandunn
Copy link
Member

iandunn commented Sep 11, 2018

In the Classic editor, if you're in Text mode and you click on the Add Media button, the media modal pops up. You can then select an image, and its raw markup will be inserted into the post content. You get the same markup as you would performing that operation in Visual mode.

In Gutenberg, however, if you switch to the Code Editor and add an Image block, you just get placeholder markup:

<!-- wp:image -->
<figure class="wp-block-image"><img alt=""/></figure>
<!-- /wp:image -->

If you select a table block, all you get is <!-- wp:table /-->

Reported on the forums.

I'd expect the block GUI to pop up and allow selection of options, etc. Then, the proper markup should be inserted into the post content.

@iandunn iandunn added [Type] Enhancement A suggestion for improvement. [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Feature] Code Editor Handling the code view of the editing experience labels Sep 11, 2018
@youknowriad
Copy link
Contributor

youknowriad commented Sep 11, 2018

I personally, think the "Add block" button doesn't really make sense in the Code Editor. It's not possible to show the block's edit GUI in the Code mode because that's the visual editor's representation.

I'd be in favor of disabling the button in the code editor as one of the goals of Gutenberg is to make the "Code editor" less important in favor of block manipulation.

@iandunn
Copy link
Member Author

iandunn commented Sep 11, 2018

Ah, yeah, removing the Add block button makes sense then.

I wonder if it'd still be good to provide a way to add a few basic things, though, similar to how to Classic editor's Text mode has a few basic buttons. There are a lot of power users who use the HTML mode, and having feature parity will ease their transition to Gutenberg.

@blueclochard
Copy link

I would welcome the return of some basic buttons in the Code Editor. The old Add Media button is one, but also the Quicktags just below that are very useful. For example, I don't know the exact URLs of all pages on my sites. Being able to just click the link button and select the page I want the text to link to is a real time saver.

I'm not a fan of Gutenberg, but I also never liked the old Visual Editor. Some of us simply prefer the Code Editor because it gives us more control. Coming from the old Text Editor however, Gutenberg's Code Editor is a downgrade because functionality has been removed.

@youknowriad
Copy link
Contributor

Some of us simply prefer the Code Editor because it gives us more control.

I'd say you argue that you have more control with the visual editor of Gutenberg. The block's markup is strict and if you want to do something that doesn't match the block's markup, you can use the HTML block which is basically a code editor inside the visual editor which means in the end, you have the best of both worlds. The ability to use GUI to insert things like media, images, galleries etc... and the possibility to control the markup of parts of your post.

@blueclochard
Copy link

@youknowriad I understand if there are people who prefer Gutenberg's visual editor and that's perfectly fine. There are however a lot of people, myself included, who prefer to use Code Editor. If you look at this survery, you can see that 35% always use the Text Editor.

Is there a technical reason which makes the return of basic functionality to the Code Editor difficult to implement? Because I don't really see why it was removed. I'm sure a lot of users would appreciate the return of Quicktags and the Add Media button.

@youknowriad
Copy link
Contributor

There're no technical reasons, it's more a design (not visual design) decision. The idea is to lower the 35% in the survey (also noting that the survey is in general very developer oriented because it's easier to find for developers than the regular WordPress users).

I understand that a lot of people will still prefer to write in Code and I think that's fine and there will probably be advanced Code Editors Plugins or Markdown Plugins too for these use-cases. But we do think a lot of these use-cases are better addressed with the visual editor + HTML block (or custom HTML blocks)

But for Gutenberg, if we allow people to use quicktags in the code editor, it will create more frustraction than it solves because people when coming back to the visual editor will notice the "Block has been modified externally" error way too often. Also one of the principal goals of gutenberg is to unify the way we create content: media, text, embeds... everything is inserted using the inserter and the concept of blocks, having an Add Media button doesn't really make sense with this in mind.

@blueclochard
Copy link

Okay, fair enough. Unfortunately Gutenberg is not for me then. I don't like playing with blocks ;-)

I was the one who mentioned this on the Wordpress support forums, but the problem @iandunn mentioned about the + button adding placeholder markup would still be valid though. Either adding proper markup or removing the button would make sense.

@iandunn
Copy link
Member Author

iandunn commented Sep 12, 2018

That makes sense, thanks @youknowriad :)

@iandunn
Copy link
Member Author

iandunn commented Sep 13, 2018

I also want to say that, while I don't always agree with the design decisions y'all make, I appreciate how much thought you put into it, and the way you work to maintain a strong and consistent vision for how the project should work.

cc @youknowriad, @tofumatt, @jasmussen, @mcsf, @karmatosed

@mcsf
Copy link
Contributor

mcsf commented Sep 17, 2018

Okay, fair enough. Unfortunately Gutenberg is not for me then. I don't like playing with blocks ;-)

I like this thread. I just wanted to mention that respectful disagreement is not common and is deeply appreciated, @blueclochard. :)

@jasmussen
Copy link
Contributor

Is there a technical reason which makes the return of basic functionality to the Code Editor difficult to implement? Because I don't really see why it was removed. I'm sure a lot of users would appreciate the return of Quicktags and the Add Media button.

Riad is right on the money, that for now we've designed with a focus on the visual editor, and making sure the code editor is solid, but we haven't had time to add too many features to the code editor.

However, if a well-designed pull request, that considered the features proposed in #9445 (comment) but managed to still add back quicktags, there's a good chance it would land.

It's important to remember that right now we are sprinting towards the 1.0 version. Gutenberg will continue to evolve beyond that.

@Chris01123
Copy link

Finding myself apparently trapped in the horrible Block Editor, I use Code Editor (CE). With no toolbar, there's no easy way to insert media. Warning: don't think you can switch to Visual Editor (VE), insert media, then switch back to CE. Doing that stripped out my internal link "<a id..." code. This is my workaround:
• Open dummy post. In VE, insert media
• Change to CE. Copy code.
• Paste into orig post
• Delete dummy post

@iandunn
Copy link
Member Author

iandunn commented Sep 18, 2020

Hi Chris, would using a Classic block or an HTML block in the original post be an easier workaround for you?

@Chris01123
Copy link

Thaks for that, Ian. Quite possibly, but I find block editing utterly abhorrent for editing posts made BBE using a happy mixture of HTML and Visual Editing, so I'm afraid I don't even know what you mean! Sorry. I was patheticaly grateful to discover Code Editor and I cling to it for fear of something worse (Block Editor).

@iandunn
Copy link
Member Author

iandunn commented Sep 18, 2020

No worries. The Classic block is an instance of the Classic editor/TinyMCE inside the block editor. So, you can add a Classic block to your post, and then write the whole post inside that, using all the same tools that you'd have in the old editor. You don't need to add any other blocks, if you don't want to.

There's also the Classic Editor plugin, if you'd prefer that.

@Chris01123
Copy link

Quite possibly. Are there any problems with them?

@iandunn
Copy link
Member Author

iandunn commented Sep 19, 2020

I'm not aware of any huge issues with either of them, but beyond that it'll just depend on your personal preferences/requirements/etc. They're easy to test out, so I'd recommend doing that.

@Chris01123
Copy link

OK, thanks Ian, I'll try that. (I'm wary because of past experience of WP suddenly and inexplicably mangling my HTML. Once, it took me a week to unmangle it.)

@iandunn
Copy link
Member Author

iandunn commented Sep 19, 2020

Yikes, I'm sorry to hear that, that's gotta be really frustrating, and should never happen :(

You can always test it out on a fake/duplicate post for safety. If you notice any mangling bugs, please open a new ticket and paste the HTML in there, so we can reproduce it and fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Code Editor Handling the code view of the editing experience [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later [Type] Enhancement A suggestion for improvement.
Projects
None yet
6 participants