Meta Tags & WYSIWYG Incompatibility?

This is due to WYSIWYG's choice to make profiles an entity, which need a numeric value and not a string for entity IDs as per hook_entity_info().

See also #1003788: PostgreSQL: PDOException:Invalid text representation when attempting to load an entity with a string or non-scalar ID for a workaround in core.

Marked #1432568: wysiwyg entity id is a string and not in int. a duplicate.

The documentation states:

Every entity object passed to the Field API must have this property and its value must be numeric.

Nothing is stated about entities without fields, and no must-be-numeric requirement is enforced in code, or at least wasn't when Wysiwyg converted to using entities. There also seems to be other legitimate use cases for non-numeric entity ids, as fago said in comment #67: #1003788-67: PostgreSQL: PDOException:Invalid text representation when attempting to load an entity with a string or non-scalar ID.

I don't yet know how we can keep Wysiwyg's editor profiles as an entity without introducing bogus id numbers. This would force one to always take the detour via EntityFieldQuery to load profiles, instead of directly calling entity_load, when they don't need them all.
I'm assuming those bogus ids would also be exported along with the rest of the profile data, perhaps leading back to the export-mess we had when formats had numeric ids. I might be wrong tho.

First: Sorry for the duplicate, didnt found this first.

Nothing is stated about entities without fields

Ok, I see what you mean, but still, wouldn't it be better if there was an numeric id anyway? I mean you can have both an numeric id and a string id.

Then you can use entity_load_multiple_by_name (from entity module) instead.
You could actually alter the entity info and make this entity fieldable if you like.

We could add an auto-incremented id field so new profiles get a unique numerical id, but Wysiwyg or other modules wouldn't know which id belongs to which format. Since Wysiwyg ties each editor profile to a text format, and they use non-numeric names, we only need to use the format's id to load specific profiles. To know which numerical id corresponds to a format, we'd have to load the profile based on the format anyway as no other place in Drupal would hold those ids.

For entity_load_multiple_by name(), one would have to depend on Entity API.
The parameters for entity_load_multiple_by_name() are passed directly to entity_load() anyway, so we'd still have the same problem when using it.

Do you have a use case for fieldable profiles?

Marked #1448106: PDOException using PostgreSQL as a duplicate of this issue.

Is the problem that WYSIWYG tries to instantiate itself in Metatag fields, or that you can't edit e.g. a node page when both the Metatag settings load & WYSIWYG loads?

I posted a patch at #1448324: Only support entities with a numeric entity_id that solves the problem from the Metatag module.

@DamienMcKenna, Metatags can link meta-data to all entities, including Wysiwyg's editor profiles, and stores that data keyed by entity type and id in its own table. When it tries to fetch all meta-data for editor profiles it passes in the ids of those entities, which are strings, but the table scheme says the entity_id column should hold ints. Hence there's a datatype mismatch between the values used in the query and the table itself even if no meta-data has actually been stored yet.

I'd like to postpone this pending the result of #1003788: PostgreSQL: PDOException:Invalid text representation when attempting to load an entity with a string or non-scalar ID in core.