vaughanprint
Forum Replies Created
-
Forum: Plugins
In reply to: [Disable Gutenberg] Custom Post TypesHi Jeff,
I am just testing the Manage Gutenberg plugin and it lists and allows disabling all CPTs but, doesn’t do so on a user role basis.
Forum: Plugins
In reply to: [Disable Gutenberg] Custom Post TypesHi Jeff,
I did some investigating and just so you know this is all for testing purposes. I have no live project depending on this.
I am not sure if you are familiar with Toolset Types and Views. When you set up a CPT with Toolset you get a vast a rray of settings. As you suggested, if you disable the editor, yes Gutenberg doesn’t detect the post type as it is not conforming to what Gutenberg expects. The other requirement is that show_in_rest must be set (checked) to true. Regardless of what combination I configure, my custom post types are not listed in the Disable for Post Types list.
I think this is specific to CPTs made with Toolset. Initially I was seeing three post types: Posts, Pages and Projects. The Projects type is from the Divi theme.
I am also seeing a fourth which is a special intermediary post type that Toolset now creates if you set up a many-to-many relationship between two post types. The intermediary type is not backed by a post that you view but is used to bridge between the two parent types and in some instance has fields that can be either of the parent types.
I made such a relationship on my test site in the last day. So, its strange that this intermediary type can be seen on not the general Toolset CPTs.
The work around for the moment is to uncheck for your user role and check for the post types you can see and for Toolset types either don’t use the editor or disable show_in_rest. Not ideal if you want to use the editor or want to use any RESTful feature.
But, it is an option and with the Gutenberg project shifting goalpost and not getting anywhere fast, no panic.
It would be nice if we could ultimately switch on/off Gutenberg from the administrator level on a CPT by CPT basis and by user role to match up various use cases where each editor has its merits but I am not sure Matt and the Gutenberagedon team really know why they are doing all this.
The one aspect that they seem to be overlooking is structuring blocks to reflect the structure of layouts built in a section/row/column/module manner. With such a basic mechanism Gutenberg would have an api that would allow page builders to sit on top of. This would take away the concerns and criticisms of builders that make changing themes a pain point (the detritus of Divi shortcodes etc.).
As it is the Gutenberg team are falling between stools, saying this is not a page builder it’s for managing content, when really what they are trying to do is push everyone out of the way with a single minded approach. Just make is a page builder, albeit a rudimentary one that basic themes can use and new users will be comfortable with till they are ready to move onto more sophisticated builders.
Anyway I will leave it with you to investigate further.
Forum: Plugins
In reply to: [Gutenberg] Suggestions: Metaboxes and Contextual InterfaceNow on version 2.8 and still can’t move blocks back in to the Extended Setting area if all panels have been moved to the main area. You need to keep at least one meta box in Extended Settings for it to work.
I am presuming this is a bug that will get fixed eventually. The current workaround is to go into the classic editor where you can move meta boxes back into the right side of your interface.
Forum: Plugins
In reply to: [Gutenberg] Editing the permalinkAha! Good to see that.
Some of the comments on that GitHub issue are interesting. It shows the different expectations each user has of a user interface. Personally, for me, the discoverability of controls is not not an issue as you kind of find these things fairly quickly and the permalink is not something I want to look at all the time, unless I need to change it because I need to change the title or I mashed that title on the keyboard when I entered it the first time. Out of the box Gutenberg is shaping up to be pretty good for general pages and blog posts.
And! You’ll be happy to hear this, I have managed to use a function that injects CSS styling into the backend dashboard of WordPress to put a bit of shape on Gutenberg when using it for custom post types with their own specific fields and layouts. You can see my rudimentary results here:
- This reply was modified 7 years, 12 months ago by vaughanprint.
Forum: Plugins
In reply to: [Gutenberg] Suggestions: Metaboxes and Contextual InterfaceUPDATE: Gutenberg 2.6.0 now detects when you move between blocks and out of blocks completely and reflects this in the side bar by contextually showing the controls for that block.
Nice one.
For specific styling, you can customise the the look of Gutenberg with a script, in the functions file of your child theme. I won’t give the function code here as things are subject to change as Gutenberg progresses, but here is a screen shot of something I was able to come up with:
Forum: Plugins
In reply to: [Gutenberg] Suggestions: Metaboxes and Contextual InterfaceUPDATE: If you remove all the meta boxes from the Extended Settings area you can’t put any back. You need to have at least one in there to move others back. A bug that needs attention.
Also would be nice to be able to move the Featured image into the main area wherever you want. I currently have a configuration where the Feature Image meta come immediately after the page title fields in my workflow.
Forum: Plugins
In reply to: [Gutenberg] Suggestion: HTML blockAlso, and this one is really a code mirror suggestion, in SublimeText with the appropriate package installed, code hinting and completion is a bit smarter. If I want to add a paragraph tag all I have to do is type p and the p tag suggestion appears and can be activated by hitting return. Currently in the HTML block I need to type the complete <p> before I automatically get what I want.
No pressure, some time in the future will do for this one.
Forum: Reviews
In reply to: [Gutenberg] Have both: Classic and GutenbergSome good suggestions from YOAST
https://yoast.com/gutenberg-alternative-approach/
Forum: Reviews
In reply to: [Gutenberg] Have both: Classic and GutenbergHi Tammie,
I will dig in a bit more at risk of either digging a bigger hole for myself or yourself.
The issue here is the right tool for the right job and before getting to answering your questions and going into more detail I would like to recount an analogy (albeit an agricultural one) to demonstrate why you might be getting a lot of one star reviews here.
There is a company called John Deere that makes tractors to a high specification. These tractor typically have a PTO (Power Take Off), to which farmers can attach all sorts of machinery to do all sorts of jobs on the farm and big wheels with chunky tyres to get around all sorts of rough terrain. On top of this, inside of the cab is full of mod cons and is very comfortable, making John Deere tractors very popular.
One day a boffin in the marketing department notices that sales of John Deere tractors have exploded in Ireland. Thinking that everybody in Ireland is a farmer and wondering if the appeal of the John Deere brand can be broadened he suggests that the company should produce a family saloon. The farmer’s kids would love it and it would drive up sales further.
So off to work go the engineers and designers on this top secret project. The first thing to be dropped is the PTO, on the health and safety grounds that it is a threat to life and limb. Obviously those chunky wheels go too. At the end of this process John Deere has produced the most dramatic semi-autominous car to come to market and all electric to boot.
The big launch day arrives and it is in Dublin with farmers invited from all over the country. When the veil is lifted there are gasps, this is not what they were expecting.
In reaction to this shock and awe, Paddy from Kiltemagh pipes up:
“When will we see an update to the 6120M.”
The CEO of John Deere, who happens to be on the podium, responds:
“We have no new tractors in the pipeline at the moment. Looking to the future, we will be focusing on road based vehicles. We are so confident that this car will be successful that we currently have a sports coupe V8 in development. Next question please.”
Paddy turns to Tom standing beside him:
“Well I wouldn’t drive one of those around Dublin.. All those computery lads from Facebook, Google and Microsoft would laugh me off the road and call me the parrot.” (incidentally the car comes in John Deere livery only, all green with yellow branding down the side.) “It’s of no use to me on the farm and the nearest charging point is 40 kilometres away.
“Well that’s that then” says Tom “No more American imports for me, what with Trump, tariffs, trade wars n’all. I’m going to check out one of them German Deutz-Fahrs.”
This sums up why there is a lot of concern and upset at the way the Gutenberg is being promoted. A lot of developers depend on the current editor interface and, forcing the Gutenberg interface on them will break and disrupt their workflows.
Let me explain a bit more. I have added links below to websites and pages with screenshots to illustrate the point I am making. The Gutenberg editor has some merit and potential and will be useful in certain scenarios which I will highlight as we go along. The interface is very clean and the introduction of blocks has some appeal but as an interface it is static and lacking the complexity required for certain workflows. By static I mean the interface elements can’t be moved.
On the other hand the current editor allows you to rearrange panels in whatever way you want. This would be a good point for me to define what the editor is:
From what I can see you define this as the TinyMCE editor whereas I would define the whole webpage on the back end as the editor. I see that there is indeed a block in Gutenberg called Classic for those who want to use it. I use the TInyMCE a lot and it does a very good tool for certain jobs. My understanding is that is a separate module developed for other platforms other than WordPress and there are many versions of it. In fact I use a plugin called TinyMCE Advanced that adds extra functionality. In fact when I use the Classic block in Gutenberg I get this advanced version of that editor, which is a good thing. The one fly in the ointment with TinyMCE (at least the version in WordPress from what I can see) is that the text editor tab is hopeless at rendering formatted code, has no colour coding for highlighting syntax, and makes a balls of indentation. It could do better and aspire to function like a proper IDE text editor. The other thing the text editor lacks (like a lot of other plugins, page builders, and Gutenberg blocks) is a decent canvas area, when called upon, to do intensive coding/HTML markup work.
Back on topic, I want to illustrate why the current editor page is so important to my workflow with the following screenshot:
http://portfolio.vaughanprint.com/wordpress-editors/
That layout is setup for a custom post type and custom fields for boats on a site I build two years ago. I am using Toolset Types plugins for this and while I am using the Divi theme for the overall site pages, in this case I am using Toolset’s templates on their own. Looking at this layout I have a set of Product fields that does not include the text area that is default for the general content loop. This is turned off through Toolset settings for this post type. I created a Description custom field for the text are instead and it is placed in a specific order after other fields to suit the workflow for data entry. This is important as I was tasked to pre-populate the site with a an inventory of hundreds of products that included items other than boats. Making the layout as logical and streamlined as possible were factors to make this job as efficient and cost effective as possible.
Moving on, the Boat fields are linked to the boat products only, Oar products get their own post type and their own specific set of fields.
Then at the bottom I placed the Boat Categories panel. I add a small css hack so that the panel is made larger so as to see all the boat categories at a glance.
What I want to emphasise here is that this layout is optimised for the job at hand. It may look intimidating to the uninitiated but it conforms to Larry Tesler’s Law of Conservation of Complexity. Larry was part of the team that developed the Macintosh and he stated:
“Every application must have an inherent amount of irreducible complexity. The question is: who will have to deal with it?”
Well the answer is the person who is accustomed to or trained to use the interface. In my screen shot of the editor set up for boats everything is on the table and clearly labelled. Trying to do the same thing with Gutenberg interface as it currently works would entail a lot of wasted time hovering over elements to make them visible and of course I can’t put things where I want them.
This brings me on to some words on WordPress. I started using it about ten years ago and initially it was a challenge. I jumped in at the deep end and a the time the hosting I was using didn’t have one click install so I was left to figure out how to create the mySQL database, FTP up the files and then configure everything to link up. I remember it being a painful experience, digging around on the internet to find good clear documentation. In all it took me the guts of a week to get my head around it. Nowadays I could do a manual WordPress install blindfolded in five minutes. Then there was a learning curve of acquainting myself to where everything is in the dashboard.
The point I am making is that WordPress is a complex beast; not for the faint hearted. Its built to a certain degree for professionals. For this reason we see platforms like WIX and Squarespace pitched at amateurs and I am using the word according to its original and French definition: enthusiasts. These are solutions for people who want to built a site quickly without the complexity of rolling their own HTML or wrestling with WordPress. Yes there are limitations to what can be done with WIX et al, but they do a reasonable good job for those who don’t want too much fuss.
Back to some observations on my testing of Gutenberg and other configurations I use.
I spent a few days looking at some betas that Toolset have released for working with Gutenberg. Please read the following so that the comments that follow make sense:
https://wp-types.com/2018/03/preparing-toolset-plugins-for-gutenberg-new-documentation-is-online/
And
https://wp-types.com/documentation/user-guides/how-toolset-plugins-work-with-gutenberg/
Following the article and documentation you can see what work is being done for the templates and views blocks. I like the way when you set up a view block how it has controls for some of the filters.
One thing I noticed though, on a test site where there are custom post types I previously made, the Gutenberg editor doesn’t appear and instead defaults to the classic one. Toolset has in settings for types a checkbox for show_in_rest, as you will have seen in their documentation. Even with this set Gutenberg didn’t kick in. Then I realise that fallbacks are in place when things aren’t configured in a specific manner and I often don’t use the editor on custom post types, using only custom fields. By editor, I am referring specifically to the TinyMCE text area which represents the standard content loop. My non conformist elimination of the editor must be triggering one of these fallbacks to the current editor interface.
Looking at that show_in_rest option triggers another insight on what is happening with Gutenberg. I read in other reviews and comments that the React framework is being used. Again a good application of this technology and Elegant Themes use it for the visual builder in Divi. So I deduce what really is happening with Gutenberg, in its current guise as a plugin, is it is using the rest api to override the current interface with its own interface. Again all very good stuff and seeing custom interfaces like this is a welcome addition to WordPress. To clobber the Gutenberg interface we need your Classic Editor plugin. In effect that plugin doesn’t actually contain the classic interface, it is just a switch and more on this in my conclusion.
Moving on to one more concern. How this effects my work with Divi, and Divi using the Toolset integration. Have a skim through the following pages to see how this works:
https://wp-types.com/documentation/recommended-themes/toolset-divi-integration/
And
When using the Gutenberg plugin and let say in theory we don’t have access to the classic editor anymore you end up with a pile of Divi shortcodes which really isn’t something you can work with. Yes you can still work with the Divi Visual Builder on the front end for regular posts but when making templates through Toolset’s integration for Divi you only use the back end.
Here is how the editor should look like when making a template:
http://portfolio.vaughanprint.com/wordpress-editors/#nice-template
And when Gutenberg is in charge:
http://portfolio.vaughanprint.com/wordpress-editors/#useless-shortcodes
This give you an idea of how terrible wrong things can go when you introduce something as disruptive as Gutenberg. All the developers out there need to firefight situations like this. I have to depend on venders like Toolset not throwing in the towel on the Divi integration because it all becomes to taxing with all the other theme integrations they are working on.
In conclusion I can see some merit in the Gutenberg editor. It has a clean interface and would be useful if we could use it for end user clients for simple data entry and trivial post and page publishing. But as I have illustrated, Gutenberg on its own is a hornets nest of pain when shoved into the complexity of established workflows and theme/plugin integrations.
There is of course a simple and elegant solution to all this. There is no reason why both interfaces can’t be used in WordPress. It could be a healthy symbiosis with certain features and design bleeding from one interface to the other. By all means, you can make Gutenberg interface default on installation of WordPress but just show us the checkbox to make the Advanced Editor default. Don’t make Classic Editor a plugin and actually change the name form Classic Editor to Advanced Editor. Both plugin and Classic title stink of deprecation and abandonment sometime in the future.
Tammie if you have got this far your a star and thanks for considering my suggestions and observations.
Forum: Plugins
In reply to: [amr shortcode any widget] Highlight current active pageJust figured this out, for anyone else may encounter the same issue.
You can add the following to the functions file of your child theme:
function special_nav_class ($classes, $item) { if (in_array('current-menu-item', $classes) ){ $classes[] = 'highlight-active-page'; } return $classes; } add_filter('nav_menu_css_class' , 'special_nav_class' , 10 , 2);In my case I created a class called: ‘highlight-active-page’ as seen above. So make sure to name and add accordingly for your needs.
My solution did not straight away work due to the vagaries of my WordPress configuration with Pagelines Platform 5 so you may need to do some extra leg work, like I did to get it working.
Forum: Fixing WordPress
In reply to: Seeing Add New User page, not dashboard on Log inResolved.
For shame!
Using One Password, the url for the login was to the create New User page for some reason.
Only just spotted this. So be forewarned. Be careful of copy and paste!
Forum: Requests and Feedback
In reply to: Gallery improvementActually…
Why not just have the Select Files Button directly above the Media Library thumbnails in the Insert Media banner. There is certainly enough space for this. Having to click between Upload Media and Media Library seems pointless. It doesn’t seem like efficient design.
Forum: Requests and Feedback
In reply to: Gallery improvementOh. And When we click the Insert media button an option to make select files the default. It is what I would use most in my workflow. Having to click more makes the job slower.
Is there a direct feedback link to the WordPress Team where I can post these ideas?
Forum: Requests and Feedback
In reply to: Gallery improvementYes. I like the design and its neatness but it needs just one thing. There should be an option to move the divider between the thumbnails area and the Edit Details area. The Edit Area is very to the right and too narrow making the fields for Title, Caption and alt text too mean and clumsy for practical use. A small issue but fixing this would make the change to te new media uploader/manager better.
Forum: Plugins
In reply to: eShop and Stock levelsHi Elfin Esmi.
Great news. Got back to working on the cart plugin after several weeks on other jobs and configured it to work. Anybody having issues with the IPN and Stock control/no stock available (PayPal) should follow the setup and configuration instruction given by the developers of eShop at this link:
http://quirm.net/wiki/eshop/setting-up-merchant-gateways/paypal/
All ducks must be in a row.