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

Format is already registered to handle class name error log #13776

Closed
phpbits opened this issue Feb 8, 2019 · 7 comments · Fixed by #15072
Closed

Format is already registered to handle class name error log #13776

phpbits opened this issue Feb 8, 2019 · 7 comments · Fixed by #15072
Labels
[Package] Format library /packages/format-library [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.
Milestone

Comments

@phpbits
Copy link
Contributor

phpbits commented Feb 8, 2019

Describe the bug
Custom formats are logging this error :

`Format "${ formatTypeForBareElement.name }" is already registered to handle bare tag name "${ settings.tagName }".`
even when classNames were defined.

To Reproduce
Steps to reproduce the behavior:

  1. Install https://wordpress.org/plugins/coblocks/
  2. Load editor with 5.0
  3. Uppercase and code formats are working perfectly but those errors were logging

Expected behavior
No error logs

Screenshots
screen shot 2019-02-08 at 12 57 06 pm

@aduth aduth added [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes. [Package] Format library /packages/format-library Needs Technical Feedback Needs testing from a developer perspective. labels Feb 8, 2019
@aduth
Copy link
Member

aduth commented Feb 8, 2019

Related Slack conversation (link requires registration):

https://wordpress.slack.com/archives/C02QB2JS7/p1549632859321200

The curious thing to me is that it gets this far under a condition of className === null, despite a class name being defined in the settings of the source format type:

https://github.com/thatplugincompany/coblocks/blob/ded312447bb9b0ab89f45f532d8c1580c87b5579/src/formats/code/index.js#L23

@phpbits
Copy link
Contributor Author

phpbits commented Feb 8, 2019

@aduth Yeah, same here.

@gziolo
Copy link
Member

gziolo commented Feb 8, 2019

export function getFormatTypeForBareElement( state, bareElementTagName ) {
return find( getFormatTypes( state ), ( { tagName } ) => {
return bareElementTagName === tagName;
} );
}

This might be an issue in the implementation, I see the following happening:

  1. Format type with a class name A and tag name B gets registered.
  2. Another format type without any class name but the same tag name B gets registered.

/cc @iseulde

@phpbits
Copy link
Contributor Author

phpbits commented Feb 8, 2019

@gziolo Most of us will probably use span since it's easier to control inside divs and paragraphs. getFormatTypeForBareElement should check classNames too.

@phpbits
Copy link
Contributor Author

phpbits commented Feb 25, 2019

@aduth @gziolo I hope it's fine to follow this up :) Thanks!

@pascalknecht
Copy link

I have the same issue while registering a custom format for links. Still does not work with the current version of gutenberg. Also the link toolbar button gets lost when registering this custom format. @aduth @gziolo
Example code:

const { registerFormatType } = window.wp.richText;
const { RichTextToolbarButton } = window.wp.editor;

registerFormatType( 'wk/no-icon', {
	edit( { isActive } ) {

		return (
			<RichTextToolbarButton
				icon={ 'editor-link' }
				title={ 'Link ohne Icon' }
				isActive={ isActive }
				/>
		);
	},
  	tagName: 'a',
  	className: 'without-icon',
  	title: 'Link ohne Icon'
} );

@gziolo
Copy link
Member

gziolo commented Apr 19, 2019

I opened #15072 which tries to address this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Format library /packages/format-library [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants