rdf_entity_info_alter() contains an old @todo and references to an UI which is irrelevant for core.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

scor’s picture

Status: Active » Needs review
FileSize
969 bytes
TR’s picture

Version: 7.x-dev » 8.x-dev
Component: rdf.module » documentation
FileSize
977 bytes

Needs to go into D8 first.

Reclassifying as a Documentation issue.

Re-rolled patch for the current D8, in -p1 format.

jhodgdon’s picture

Status: Needs review » Needs work
Issue tags: +Needs backport to D7

This looks like a reasonable change... A few suggestions:

a) Can you provide a link to some information on the RDF CRUD mapping API, or at least a function or two that are part of it?

b) "which" always needs a comma before it.

c) table names should be enclosed in {}.

d) Should this new text be a new paragraph? If so, leave a blank line. If not, you might need to move the word "Modules" up to the previous line to get all lines in each paragraph wrapped as close to 80 characters as possible.

Thanks!

marcin.wosinek’s picture

Status: Needs work » Needs review
FileSize
983 bytes

Implementation of #3 feedback.

jhodgdon’s picture

Status: Needs review » Needs work

Better! The link to @see rdf seems like a good way to provide a link to the RDF API, but I'm not sure which functions would be called to do CRUD really... Maybe saying "use whatever_the_function() instead" would be clearer?

I'm also wondering about the word "willing" here... Do you mean "trying"?

Also, this is not a hook that modules can implement... it seems to be a function that modules can call, right?

scor’s picture

The function to use to do CRUD is http://api.drupal.org/api/drupal/modules!rdf!rdf.module/function/rdf_mapping_save/7

rdf_entity_info_alter() is an implementation of hook_entity_info_alter(), which is the hook in question. Does the following make more sense?

Modules specifying or altering bundle mappings should not implement hook_entity_info_alter(), but instead use the RDF CRUD mapping API and in particular rdf_mapping_save(), which will store the mappings in the {rdf_mapping} table.

jhodgdon’s picture

To me, that doesn't make sense. Other modules that want to alter *entity info* would implement hook_entity_info_alter(). That hook is not anything to do with RDF per se, so why would anyone think to implement that hook in order to alter RDF mappings?

Instead, I think if we just remove the @todo section from the function doc here, we'll have the documentation clearly saying "This is a hook implementation", and it would be clear enough that no one should really call this function.

And I guess it wouldn't hurt to reword where it says "Adds the proper RDF mapping to each entity type/bundle pair." ... instead of saying "proper", it could explain where it gets the RDF mappings from (presumably from mappings that have been stored with the RDF save function, right?).

scor’s picture

that would work for me @jhodgdon.

jhodgdon’s picture

Cool, let's get a patch then. :)

sun’s picture

Hm. I actually think it would be good to add the originally suggested comment from the last patch, perhaps phrased a little better.

It seems like the intention was to clarify that other modules should not implement hook_module_implements_alter() in order to have their hook_entity_info_alter() implementation run after RDF module's, so they're able to alter the definitions being injected by RDF module.

Such a comment makes sense to me, because honestly, I think I would have done just that (if I had any need for doing so). ;)

So if that was the intended message, then I think it could be simplified into:

"Other modules should not attempt to alter the mappings being injected here. Use hook_rdf_mapping_blahablah instead."

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

TR’s picture

Version: 8.9.x-dev » 7.x-dev
Issue summary: View changes
Status: Needs work » Closed (won't fix)
Issue tags: -Needs backport to D7

... and back to D7, because this code no longer exists in D8 - it was removed by #1869600: Refactor RDF mappings to be inline with the new Entity Field API

And, to reflect reality, this should be "won't fix" after more than 10 years ...