Use INameFromTitle interface from plone.base

[gforcada]

This is part of plone/Products.CMFPlone#3858

It needs plone/plone.base#51 to be merged, and released.

It first needs #378 to be merged first.

See the tracking issue for the overview of the changes and why.

[mister-roboto]

@gforcada thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

[mauritsvanrees]

I have released a new plone.base version and updated the constraints at https://dist.plone.org/release/6.0-dev/ so should be fine now.
I will test this together with plone/plone.app.content#271 on Jenkins.

[mauritsvanrees]

Actually, tox -e test fails, so that needs to be fixed first.

[mauritsvanrees]

Failure seems related:

Failure in test test_add_item_w_title_only (plone.app.dexterity.behaviors.tests.test_id.TestShortNameBehavior.test_add_item_w_title_only)
Traceback (most recent call last):
  File "/usr/local/Cellar/python@3.11/3.11.6/Frameworks/Python.framework/Versions/3.11/lib/python3.11/unittest/case.py", line 57, in testPartExecutor
    yield
  File "/usr/local/Cellar/python@3.11/3.11.6/Frameworks/Python.framework/Versions/3.11/lib/python3.11/unittest/case.py", line 623, in run
    self._callTestMethod(testMethod)
  File "/usr/local/Cellar/python@3.11/3.11.6/Frameworks/Python.framework/Versions/3.11/lib/python3.11/unittest/case.py", line 579, in _callTestMethod
    if method() is not None:
  File "/Users/maurits/community/plone-coredev/6.0/src/plone.app.dexterity/plone/app/dexterity/behaviors/tests/test_id.py", line 58, in test_add_item_w_title_only
    self.assertEqual(self.browser.url, "http://nohost/plone/id-from-title")
  File "/usr/local/Cellar/python@3.11/3.11.6/Frameworks/Python.framework/Versions/3.11/lib/python3.11/unittest/case.py", line 873, in assertEqual
    assertion_func(first, second, msg=msg)
  File "/usr/local/Cellar/python@3.11/3.11.6/Frameworks/Python.framework/Versions/3.11/lib/python3.11/unittest/case.py", line 1253, in assertMultiLineEqual
    self.fail(self._formatMessage(msg, standardMsg))
  File "/usr/local/Cellar/python@3.11/3.11.6/Frameworks/Python.framework/Versions/3.11/lib/python3.11/unittest/case.py", line 703, in fail
    raise self.failureException(msg)
AssertionError: 'http://nohost/plone/document' != 'http://nohost/plone/id-from-title'
- http://nohost/plone/document
?                       --  --
+ http://nohost/plone/id-from-title
?                     + +++  +++++

I did not dive in, and probably won't do that today. @gforcada ?

[davisagli]

@mauritsvanrees @gforcada I tried to take a look at this, but the tests pass for me in buildout.coredev, and when I try tox -e test I get a different, bizarre error:

Test-module import failures:

Module: .tox.test.lib.python3.9.site-packages.plone.app.dexterity.behaviors.tests.test_contrains

ModuleNotFoundError: No module named '.tox'

[mauritsvanrees]

@davisagli The tests pass for me in coredev 6.1, but not in 6.0.
I have not seen the ModuleNotFoundError: No module named '.tox' error.

Of course one thing that still needs to happen, is that this needs to be tested in combination with plone/plone.app.content#271. But even then, when I run the 6.0 tests with both branches checked out, it fails in the same way as here in gh-actions.

It seems to work fine in practice though: when I fire up an instance and create a new Image and a new Page, they both get a normalised id based on the file name or the page title.

So I wonder if something is wrong in test setup, that some zcml is not loading, but I don't see what it would be.

[mauritsvanrees]

Okay, I kind-of see what is going on, but not completely.

In plone/app/dexterity/tests/namefromtitle.txt we have created a portal_type and added some behaviors. At first this was plone.app.content.interfaces.INameFromTitle, which worked, but in this PR we of course change this to plone.base.interfaces.INameFromTitle.
This somehow does not work. But the previous setting no longer works either.

The way to fix this in the test, is to use the named behavior plone.namefromtitle. Tests then pass, case closed.

But the problem then remains: if there is a site that uses this behavior by interface, either the old or the new one, then it fails.

Maybe someone can come up with a combination that works, but I could not. I think we need to postpone this PR and plone/plone.app.content#271 until at least Plone 6.1, and maybe 7.0.

What might help, is one of the following, probably somewhere in plone.behavior or plone.dexterity:

• If someone sets the behaviors property of an FTI, automatically convert interfaces to named behaviors if available, and save this to the database.
• Do the same, but do this when reading the property. Could be expensive as this is used a lot when reading attributes from a content type. Possibly change it on-the-fly, but that would be a write-on-read.
• Have an upgrade step that goes through all FTIs and fixes this. But this is one-time only and then an add-on could still use an interface name and then it fails again.

Wait, would former_dotted_names in the behavior registration help? No, it does not. I tried it like this:

  <!-- Title-to-id -->
  <plone:behavior
      name="plone.namefromtitle"
      title="Name from title"
      description="Automatically generate short URL name for content based on its initial title"
      provides="plone.base.interfaces.INameFromTitle"
      former_dotted_names="plone.app.content.interfaces.INameFromTitle plone.base.interfaces.INameFromTitle"
      />

Ah but this is used in lookup_behavior_registration which is only called when you go the the Types Control Panel and go to the Behaviors tab of a type. And there it does not help either: when I have the interface in the behaviors in the ZMI, the plone.nameformtitle behavior is not checked in the Plone UI.

[mauritsvanrees]

@gforcada @davisagli We may need to revert the plone.base change: the INameFromTitle there has no effect if people use it, unless we merge these two PRs, but as explained I am currently against that... What do you think?

I would be happy to be shown an error in my logic.

[mauritsvanrees]

I have created a PR to make plone.app.content a conditional dependency of plone.app.dexterity, so at least the circular dependency is broken: #380

For the moment in Plone 6.0.8 we could revert plone.base to 1.1.4.

[davisagli]

@mauritsvanrees I think you are on the right track. Earlier I missed that the old interface location could be stored somewhere persistently.

There isn't much harm in leaving the INameFromTitle in plone.base, except for potential confusion. We could leave it there and update INameFromTitle in plone.app.content to extend it, so that we're at least moving in the intended direction.

[mauritsvanrees]

Closed in favour of PR #380.