Closed (fixed)
Project:
Drupal core
Version:
8.3.x-dev
Component:
node system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
31 Jul 2014 at 10:55 UTC
Updated:
23 Feb 2017 at 11:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
l0keDo you mean to move only NODE_PUBLISHED, or may be to move all constants from node.module to NodeInterface?
Also i think STATUS_PUBLISHED is a little more consistent.
Comment #2
dawehnerYeah i guess other constants would be helpful as well.
Comment #3
l0keComment #4
l0keMoved. Named as:
Comment #6
l0keComment #8
dawehner+1
It would be great to write an issue summary and prepare maybe a change notice. Note: We node maintainer should probably have a quick look.
Comment #9
l0keComment #10
dawehnerI am fine with that.
Comment #11
alexpottYep we need a change record for this.
Comment #12
garphyDraft change record created at https://www.drupal.org/node/2316145
Comment #13
dawehnerSeems reasonable for now.
Comment #15
l0keReroll.
Comment #16
m1r1k commentedComment #19
l0keReroll.
Comment #21
umarzaffer commentedComment #23
l0keRe-roll the patch.
Comment #26
mrjmd commentedReroll attached.
Comment #27
rnield commentedDrupalConLA first time reviewer. Patch #26 appears to need to be re-rolled. Since this touches so many places I will not attempt to reroll.
Comment #28
umarzaffer commentedWhile re-rolling a new patch I:
1. Downloaded the most recent patch (#26) which failed to apply.
2. Created a new patch after checking out latest changes from 8.0.x branch.
Comment #30
umarzaffer commentedRecreating patch as previous one failed for having
use Drupal\node\NodeInterface;statement twice in a file.Comment #31
leeotzu commentedThe patch was applied successfully.
Comment #32
alexpottUnfortunately this change does not pass the beta evaluation. See https://www.drupal.org/core/beta-changes for more information. It would possible to deprecate the constants and add the new constants to NodeInterface - however even this would not be permitted in beta because it would still be a normal task with no tangible benefits at this point in the Drupal 8 release cycle. Given that doing this change is possible in a non bc breaking manner I'm going to postpone this to 8.1
Removing these constants will break existing Drupal 8 contrib.
Comment #35
berdirUnpostponing. We can deprecate them now.
Comment #36
claudiu.cristea.
Comment #37
claudiu.cristeaUpdated the IS. I didn't add an interdiff as is not relevant.
Comment #38
claudiu.cristea.
Comment #39
Anonymous (not verified) commentedI applied the #37 patch. Then I tried to find references to these constants:
They were only in the
node.modulefile. Careful work!Looks like we not use it now. But may be we can do changes like this:
Comment #40
claudiu.cristea@vaplas, thank you. Indeed those were unused statements.
UPDATE: interdiff-37-to-40.patch is in fact the interdiff
Comment #43
claudiu.cristeaThis patch revealed a bug in ModuleInstaller. The problem is that, on install, the module files "$module.module" and "$module.install" are loaded before the the module's PSR4 namespaces are registered. In this case, the code that is executed on file load (like constant declarations) cannot benefit from the new namespaces.
Comment #45
claudiu.cristeaOuch, forgot a full qualified namespace inside.
Comment #46
Anonymous (not verified) commentedCool solution! Looks like major fix for ModuleInstaller.
Comment #47
alexpottThis change is a concern because there's a small possibility of regression here. It is possible a container compiler pass might use code from the .module file. I can't see a way around this. Going to get other framework manager / release manager opinions. But this part definitely deserves its own change record.
Comment #48
berdirWe can easily work around this by simply keeping the actual values in the old constants, that's what we did before.
Then we can move that change into a separate issue.
Comment #49
catchYeah completely agreed with #48, there's no reason to get the constants from the interface for deprecated code and we've never tried to do that before.
It's worth a follow-up to look at the wider issue, but let's look at that separately.
Comment #50
catchComment #51
claudiu.cristeaHardcoded values for deprecated constants.
Comment #52
claudiu.cristeaChange record added: https://www.drupal.org/node/2843370
Comment #53
alexpott@claudiu.cristea I updated the old CR (https://www.drupal.org/node/2316145) with you improvements and deleted your old one. We only needed another CR for the module installer changes that no longer are a part of this.
Comment #54
claudiu.cristea@alexpott, but that needs also its own issue, right?
Comment #55
claudiu.cristeaSplit into #2843457: Provide PSR4 namespaces before loading the module code in ModuleInstaller.
Comment #56
Anonymous (not verified) commentedAll the proposed changes are made, thus RTBC again.
Comment #57
catchWhy do these need to be OPTION_PROMOTED and OPTION_NOT_PROMOTED? Just PROMOTED and NOT_PROMOTED would do?
Same with PUBLISHED/NOT_PUBLISHED too really.
Comment #58
claudiu.cristeaFixed #57. Back to RTBC as it was only a simple renaming. Fixed also the IS.
Comment #60
catchCommitted/pushed to 8.4.x and cherry-picked to 8.3.x. Thanks!