Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
Drupal 8 is upon us and this feature didn't make it into the release. What are we going to do?
Proposed resolution
TBD
Remaining tasks
Lets start by figuring out what approach we want to take to port the current features to the new version. Opinions and patches will be accepted. I'll open a D8 branch once there's something to commit.
User interface changes
TBD
API changes
TBD
Data model changes
TBD
Comment | File | Size | Author |
---|---|---|---|
#13 | 2606820-13.patch | 11.36 KB | jecunningham2281 |
Comments
Comment #2
jstollerAdding reference to my failed attempt to get this feature in core. It's two years old, but maybe there's something useful there. And here's hoping we get there in 2.1! :-)
Comment #3
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedHI, i started to port publication date to D8. I switched to a field based architecture, this enables the possibility to add the field to other entity types. The repo is up on GitHub https://github.com/ueberbit/publication_date
Comment #4
jstoller@webflo: First of all, thanks! Appreciate the help. I haven't had a chance to look at your code yet, but here are some initial thoughts I have about the basic approach.
I like the idea of being able to add publication dates to other entities, but I do have some concerns about making it a field. For some background, you should look at #2362981: Why not just use a date field?.
However it's implemented, I think its very important that the publication date remain an entity-level property. There's no need to save separate publication dates with revisions of an entity and reverting to an older revision should never alter the publication date once it's been set. No matter how its content changes over time, each entity should have one stable publication date. The only two cases in which a publication date should change are:
Once it's been set, you should be able to edit, revert, unpublish, and republish the entity to your hearts content without that date every changing.
To be fair, it's been quite a while since I looked at the guts of D8. At one point there was talk of altering the field system so it could be used to efficiently store entity meta data, including non-revisionable data like the publication date, in addition to content data. If that's the case, then go for it. However, if the field system is still really just designed to hold content data, with all the overhead that entails, then it may not be the best approach.
I'd love to hear your thoughts on this after playing with the system.
Comment #5
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedIt sounds like we need a translatable, not-revisionable field because we want to have a published date for each translations independently. I added the field via code as base field. This means the fields has always the same name and it not expose via Field UI by default. But we could use Field UI to configure the position in the form and the widget (input field or datetime popup).
Comment #6
jstoller@webflo, I started looking at your port and I'm still trying to wrap my brain around it all, but here are a few other things that caught my eye.
I suppose the first issue is that the field on the edit form is always blank, so it doesn't maintain the published date between saves. It also isn't handling the date correctly if you put in a custom publication date.
You have the field in the "options" group, on the node edit form, but it doesn't seem like it belongs there. Right now I'm thinking "revision_information" feels most appropriate, content wise.
I see the "Published on" field on the "Manage form display" tab, but not on the "Manage display" tab, yet it's still displaying on my nodes, after the node content.
It seems like everything in publication_date_node_presave() should be moved to the preSave() function in the PublicationDateItem class. None of that is really node specific. The field should act in the exact same way on any entity.
Speaking of other entities, we should probably support publication dates on all core entities and maybe even some popular contrib entities, where appropriate. But how? Seems like each one will need some entity specific code governing how it's displayed, yes? Perhaps we should create a series of sub-modules within Publication Date—one for each entity. That way users can enable the date for just the entities they need it for. It would also provide an easy blueprint for how to add the date to your own custom entities.
Comment #7
webflo CreditAttribution: webflo at UEBERBIT GmbH commented@jstoller Thanks for the review. I agree with your comments. There are few bugs and rough edges. I plan to work on it during Global Sprint Weekend.
Could you create a 8.x-1.x branch? I think its a good time to open seperate issues.
Comment #8
jstoller@webflo The new branch has been created with all your commits to date. Lets continue to use this as a meta issue for general discussion and link to any relevant child issues in the summary.
Comment #9
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedComment #10
ultimikeSo what's the status of this port? I cloned the code down and enabled the module and it appears to be sort-of working, but not completely.
thanks,
-mike
Comment #11
jstollerI'm afraid I got a little behind on this, because life. :-)
I still need to test webflo's patch from #9, which has not been committed. I'll try to get to that soon, but as always, more help is welcome.
Comment #12
MiroslavBanov CreditAttribution: MiroslavBanov as a volunteer commentedThe github repo is still getting new fixes in. So anyone looking to use this should start there.
https://github.com/ueberbit/publication_date
Thanks for the port, webflo
Comment #13
jecunningham2281 CreditAttribution: jecunningham2281 commentedUpdating patch to account for latest commits to the drupal 8 port.
Comment #14
LiamPower CreditAttribution: LiamPower at Reading Room commentedWould be good to get this released
Comment #15
nothinghere CreditAttribution: nothinghere commentedCan't wait, I'll use https://www.drupal.org/project/scheduler :)
Maybe you can work together on the same module for D8 ?
Comment #16
dddbbb CreditAttribution: dddbbb as a volunteer commentedI'm also using the GitHub repo, so far so good. Thanks!
If you're looking for a snippet, the relevant bit of code in composer.json that I'm using to grab the module (at a specific commit hash) is as follows:
I'm no composer wizard so this can likely be improved :)
Would love to see a coordinated release soon.
Comment #17
dddbbb CreditAttribution: dddbbb as a volunteer commentedMuppetry. Removed :)
Comment #18
tsplash CreditAttribution: tsplash as a volunteer commentedThe published date was pre populated for new nodes. https://github.com/ueberbit/publication_date/pull/4 resolves this.
Thank you for the port webflo would be great to use this released.
Comment #19
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedHello everyone, @jstoller added me as a co-maintainer to the project. Thank you! I pushed the code from https://github.com/ueberbit/publication_date back to Drupal.org. The development will continue in the 8.x-2.x branch.
Comment #20
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedTagged 8.x-2.0-beta1 a few minutes ago.
Comment #21
dddbbb CreditAttribution: dddbbb as a volunteer commentedWhooop! Great news.
Now let's get it into D9 core :)