irishetcher
Forum Replies Created
-
Forum: Plugins
In reply to: [Gutenberg] Back end editor needs to be more clearly defined.Ok. I tried the same layout in the classic block using Bootstrap and got a better result for the columns with proper padding. Having to enter into code view to do this though was cumbersome. It’s just easier to this type of work in TinyMCE and that says a lot.
Forum: Plugins
In reply to: [Gutenberg] Why comment tags for blocks?Thanks Birgit,
It was something I was thinking about today. As I said many page builders are using shortcodes to delineate the page structure. I am a fan of shortcodes for many use cases (interpolating values from custom fields into a block of text) but was never mad about the way they are used for layout. Seeing the comment tags I was wondering why the technology javascript/REACT just didn’t say output something like:
<div class="wp-section> <div class="wp-row> <div class="wp-column> <!-- content --> </div> <div class="wp-column> <!-- content --> </div> </div> </div>or for Gutenberg blocks
<div class="wp-image> <!-- 123.jpg --> </div>I had a quick look at the FAQ and seeing JSON files, perhaps for portability purposes, you wouldn’t want to be bringing wp-classes over to another framework if you were posting the same content in many places. But it would be neater in our WordPress only world if everything was HTML.
I see some having issues with say a gallery being peppered with the comment tags from the Gutenberg block when they try to work in code view. Where this was much more manageable in the current view it becomes less usable in Gutenberg. I like working with Divi most of the time, just because it is nice to work with. There are days though where I also need to work in a purely HTML way.
It might be usseful to be able to hide the comment tags for such jobs. Taking this further. Something I have wanted in the text tab of TinyMCE and surprised it wasn’t implemented years ago, is to make the code views much more like a fully immersive IDE experience. Like you see on CodePen and Codeacademy.
They have:
dark mode
sytax highlighting
respect for tab indentation
code completion/hinting
The option to take the code view to a bigger canvas size.Code mirror, recently introduced to WordPress seemed to be a step in this direction. I do see it used in the HTML block but it would be nice to see it elsewhere. And it would be a step up from the letter box format of TinyMCE, which I like, but suffered from some little handicaps.
Forum: Reviews
In reply to: [Gutenberg] EPIC FAIL and very aggravatingJan, I completely sympathise.
It’s a drag when you get ignored, especially when one stays positive, indicate pain points and make suggestions to improve Gutenberg. Encouraging others, who are having issues with the new editor, to outline in detail where its not working for them. Getting them to send feedback that is cogent, while at the same time giving every indication why they may stick with the current editor for w awhile longer so the dev team are aware what should be prioritise.
That’s why we are here and why appreciate all your support in preserving all our comments on our mission to make WordPress great again.
Forum: Plugins
In reply to: [Gutenberg] Block RespectThanks for considering this a super idea and for offering to pass it to the dev team.
Much appreciated.
Forum: Plugins
In reply to: [Gutenberg] Galleries are fundamentally broken@antermoia Looking at all those comment tags around the gallery don’t make it workable for your use case any more.
Agree being able to flip back and forth between the visual and code view is important and one of the aspects of editing in WordPress, the text tab in TinyMCE, which has needed some attention for a long time.
Having introduced code mirror recently, it needs to be developed further and pushed into more corners of WordPress. It is present in the HTML block but would be even more useful in the code view which needs to be more easily reached at any given time, wether that is just selectively the html in each block or a complete overview of the whole page.
Even making the code view on par with what you see in CodePen by making it a fully immersive IDE experience, with all the associated features, would be welcome. If it were possible to have a way to hide the comment tags, it would go a long way to making it more user friendly.
Forum: Plugins
In reply to: [Gutenberg] Back end editor needs to be more clearly defined.Ok, tested the function that allows you to adjust the width of the editor and that works.
Some observations though.
1. The title of the post should left align to line up and get the same width as the new content width. I’m just wondering if the theme doesn’t specify a content width should the that content area just fill the space provided by the browser window. I know it’s a hard choice to make. Everybody seems to have their own preference on this.
2. I tried the column block and while it affords a nicer canvas to work in with 2 columns, on the front end the content of the two columns is bunched up against each other. Any of the good page builders are well able to handle this with good preset defaults for padding and margins and controls to adjust further.
3. I used the classic block in each of the columns because it is the format I would work with generally in the future, wether there are blocks or not. (I am not suggesting that I will never work with blocks). I notice that when I switch to look at the post on the front end and then back to the editor the classic blocks in each column are now replaced with an advisory regarding it having been modified externally and would I like to either convert it to block, which I don’t or Keep it as HTML. I don’t want either of these just my content in the classic block.
I have seen this odd behaviour elsewhere, where Gutenberg makes a decision on what format my content should be in?
4. The classic block gets a grey title banner with the “Classic” title, unlike the other blocks which don’t. Why is the classic block get singled out like this. It interferes with what Gutenberg claims to be about, no clutter to detract from the content and writing experience.
5. The subtle tint of grey in used in the above, with the faint border. Could I suggest something like that to frame the metaboxes?
- This reply was modified 7 years, 9 months ago by irishetcher.
- This reply was modified 7 years, 9 months ago by irishetcher.
- This reply was modified 7 years, 9 months ago by irishetcher.
Forum: Plugins
In reply to: [Gutenberg] Back end editor needs to be more clearly defined.Good stuff. I saw mention of this, whereby the content can be set by the theme. Hopefully that will be used properly for theme layouts where a wider content width will be used to accommodate 3, 4, 6 columns. It ties is with my vision where blocks will eventually be used for the layout structure of the page -> sections/rows/columns, a basic foundation that page builders will be able to work with. Though at this stage you would be really getting into visual builder territory on the front end.
I will test out the function for the content width that you linked to.
Gettingt back to what I was actually talking about. The rest of the back end interface, outside of the content area. I know I have posted elsewhere on the functionality of the metaboxes. Here I am focusing on the aesthetics, the lack of something to differentiate where one metabox/group of fields starts and ends.
The Yoast mockup is just an example and by no means needs to be exactly like this. Perhaps some UI/UX designer will come up with something better. As an experiment I did have a local test site where I added some dashboard styling in the functions.php file that put a light grey behind the meta box title area, but it would not have been the prettiest thing to look at in all fairness.
And, for the purpose of demonstrating why I would like to see a bit more flexibility with metaboxes. Take the following.
I have a site of artist’s prints. I have a CPT for these prints. The very first thing (after the title) that I want to enter is an image of the print (Featured Image), then details such as dimensions and medium, which are in a custom field group metabox and, then the description. This best suits the data entry use case I have set up. On another day I decide I need to do some work on keywords, so I drag Yoast to the top of the pile.
I can do all this with the current editor in WordPress. This does not effect the template used on the front end which is applied through a Toolset/Divi integration. In fact I have the CPT configured so that the Divi chrome does not appear at all in the backend, just the appropriate fields that are labelled with instructions for data entry. Gutenberg in its current form does not lend itself well to this type of work but I am sure given time it is possible to find a way to do it.
- This reply was modified 7 years, 9 months ago by irishetcher.
Forum: Reviews
In reply to: [Gutenberg] All your editors are belong to usOn point 2, regarding Tags, Excerpts and Featured Image. These now have a fixed position in the interface and can’t be moved or arranged anywhere you want, like you can with the current WP editor backend.
Yes you can, to a degree, move third party metaboxes but they are limited. There is also a bug tha,t if you don’t have any metabox below the content editor area, you can’t move any metabox from the siebar to that location.
So, you start with a basic install, install Yoast, create a post. The Yoast metabox is in the left side bar. There are no metaboxes under content. The interface won’t allow you to place Yoast under content. As for returning a metabox to the sidebar…good luck with that. Suffers from the same “no metaboxes over here, I’m not taking any in syndrome”. To rectify the metabox arrangement, you need to, ironically, pay a visit to the classic editor, where you can arrange to your hearts content.
In fairness, this moving of third party metaboxes bug is noted and they are trying to fix it but there are other issues.
In addition you can’t collapse the content area, as you can in the current editor or, move a metabox to the top, under the title.
You may well ask why one would want to do all this furniture re-arrangement. Simple answer. It allows you to set up the interface for any given workflow. I have a site of artist’s prints. The very first thing, after the title, that I want to enter is an image of the print (Featured Image), then details such as dimensions and medium, which are in a custom field group metabox and, them the description. This best suits the data entry use case I have set up. On another day I decide I need to do some work on keywords, so I drag Yoast to the top of the pile. I can do all this with the current editor.
And, as a side note, the aesthetics. The overall whiteness of the Gutenberg editor is a killer, with very slight definition between all these control areas and metaboxes. We need the bit of grey between the metaboxes so they can be targeted and easily found on the screen. Yoast has a mock up of this on their blog and basically it suggests the Gutenberg interface should only have been a drop in replacement for TinyMCE.
Bottom line. While the Gutenberg interface has a lot of merit, has potential to address some issues where WordPress is lacking, potential to add some really intuitive and new functionality to WP, the single minded zeal of focusing on this one central content creation experience, to the determent of a lot of other use cases, ignoring them in fact, is its weakness.
- This reply was modified 7 years, 9 months ago by irishetcher.
- This reply was modified 7 years, 9 months ago by irishetcher.
- This reply was modified 7 years, 9 months ago by irishetcher.
- This reply was modified 7 years, 9 months ago by irishetcher.
Forum: Plugins
In reply to: [Gutenberg] Shortcodes Work?Thanks. Good to know and will keep an eye out for blocks. Toolset Views has a block for archive views but it’s good to know that we have a choice to use shortcodes in their original format where needs must.
Forum: Reviews
In reply to: [Gutenberg] Gutenberg ReviewHi @wickywills
I notice that you changed your rating of the plugin down after seeing some of the pain points of not being able to work the same way as you can with the current editor.
It’s funny, when I started using WordPress in 2009 I found the layout, TinyMCE and the general UX/UI a bit alien. Over the years I became so familiar with these that it has become like home, the only thing being TinyMCE needing some attention, especially in the text tab area. The years of development on the current backend interface has honed it to the point whereby it works rather well for almost any use case and workflow I have thrown at it. And this is where the change with Gutenberg is so painful for many of us. It doesn’t (and can’t be expected to at this early stage) to match the flexibility of the current editor in WordPress.
To this end I am, over the next while, doing a thorough appraisal of Gutenberg. I can see already that there a number of simple things that could be done to make it whole lot more attractive and usable to more users. This would be an incorporation of the current editor with Gutenberg and the option to work any way you liked. And in addition, some extra functional enhancements, long needed in WordPress which would tie in with these proposals. I will post in the support forums when done.
In the mean time, making Gutenberg default on only new installs, with the option to toggle on/off in the Writing settings is far better than having to use the Classic Editor switch plugin. It would quell a lot of the criticism.
@rpetges2 The above addresses some of your points regarding the classic block.
Forum: Plugins
In reply to: [Gutenberg] Metabox PlacementThanks, I will keep a look out for that in future updates.
Forum: Reviews
In reply to: [Gutenberg] Honest reviewYour CPTs are ok, probably because such things can be configured in a way that they don’t conform to certain requirements needed for Gutenberg to activate. In these instances WordPress will fallback to the current editor. From what I hear ACF is mostly compatible (maybe completely so) with Gutenberg.
What you are seeing now with Gutenberg, warts and all, is what is intended.
Forum: Reviews
In reply to: [Gutenberg] Haters gonna hateWhile it is always interesting to spend time debating these issues, and I have done a fair amount of it here already, I really can’t be spending too much time doing the job that the Gutenberg team should be doing themselves. And, many of us seem to be pushing against a door that won’t open wen it comes to suggestions.
Even a simple suggestion on how we do or don’t switch between Gutenberg and the current editor. As you know the current editor remains in WordPress 5 with Gutenberg as the default REACT override. Why we need to use a plugin to deactivate it when you can just add a toggle in the Reading settings would make one wonder. There even is a filter that you can add to a theme’s or child theme’s functions.php file to globally turn off Gutenberg.
Ideally it would be better if Gutenberg only activated as default on new installs, therefore leaving many sites unaffected by bugs and incompatibilities.
When I see Marius’s suggestion, about a week ago on another review:
We won’t be adding an option into core it self, that would go against our philosophy of decisions, not options.
…I lose a bit more faith in people being openminded and fair in the camp that is responsible for the future of WordPress.
So while I will continue to give feedback on Gutenberg, time permitting, I won’t be spending time in a GitHub repository. My stance, like many others, is final.
Forum: Reviews
In reply to: [Gutenberg] Haters gonna hateI was scared of unnecessary Divs and nested elements but it looks surprisingly lean.
This one thing that I was hopping would happen with blocks but so far has not been expanded to cater for complex layouts: sections/rows/columns, grid and flex. In fact, while not wanting to be a page builder, Gutenberg should be, albeit a basic one, acting as a foundational intro for new users/learners of “page building and also one with a good API that the page builder vendors can use to add there one features and interfaces. This would create a cleaner and more uniform environment for theme/builder switching and remove a lot of the unnecessary cruft.
Forum: Reviews
In reply to: [Gutenberg] Far far far too blocky…I agree, the blockiness can be disconcerting and even though having elements in blocks is generally a page builder approach, Gutenberg tends to take it to an extreme level. I use a page builder and initially the discovery of controls can be confusing and I can see why people find that bothersome.
The option of integrating Gutenberg as the third tab is an interesting but there is probably a rational why this hasn’t been done. The developers have gone for a complete override of the backend editor. It is probably an attempt to give lots of white space and distraction-less writing environment and to facilitate the AJAX reload/update experience. That being said there is merit in three tab solution to introduce a smother transition to Gutenberg. If you look at how many page builders on the back end are implemented, they generally only ever override the TinyMCE content area, leaving the rest of the backend interface intact, metaboxes and all. It is the least disruptive approach.
The implementation of Gutenberg misses a couple of opportunities.
On one side something overlooked for way to long in the TinyMCE environment, namely better treatment on the text as a work area for developers and HTML warriors. It badly needs some IDE qualities and features like what you would see in Codepen; proper respect for coed indentation, full screen(browser window), code hinting, colour coded syntax and dark mode. The recent addition of code mirror suggests that this should be possible.
On the other hand blocks suggests structure and I see a layout mechanism for sections/rows/columns and flex and grid all being possible. This mechanism could provide a basic foundation with an API for page builders add their own interfaces and features. And, this foundation would afford a less painful experience in switching between themes and builders, or for the less enthusiastic to turn off the structure all together and preserve content without the detritus of shortcodes.
Going back to the third tab paradigm, if there was a way to use each tab and on the fly afford it a bigger canvas when needed, it could be workable.
- This reply was modified 7 years, 9 months ago by irishetcher.