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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jstoller created an issue. See original summary.

jstoller’s picture

Adding 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! :-)

webflo’s picture

HI, 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

jstoller’s picture

@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:

  1. An unpublished entity without an existing publication date is published, causing the date to be set automatically
  2. A user with the appropriate permissions manually sets the publication date

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.

webflo’s picture

It 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).

jstoller’s picture

@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.

webflo’s picture

Issue tags: +SprintWeekendBerlin

@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.

jstoller’s picture

Version: 7.x-2.x-dev » 8.x-1.x-dev

@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.

webflo’s picture

Status: Active » Needs review
FileSize
3.82 KB
ultimike’s picture

So 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

jstoller’s picture

I'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.

MiroslavBanov’s picture

The 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

jecunningham2281’s picture

FileSize
11.36 KB

Updating patch to account for latest commits to the drupal 8 port.

LiamPower’s picture

Would be good to get this released

nothinghere’s picture

Would be good to get this released

Can't wait, I'll use https://www.drupal.org/project/scheduler :)

Maybe you can work together on the same module for D8 ?

dddbbb’s picture

I'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:

    "repositories": [
        {
            "type": "package",
            "package": {
              "name": "ueberbit/publication_date",
              "version": "dev-2.x",
              "type": "drupal-module",
              "source": {
                "url": "https://github.com/ueberbit/publication_date.git",
                "type": "git",
                "reference": "8.x-2.x"
              },
              "require": {
                "composer/installers": "^1.2.0"
              }
            }
        }
      ],
    "require": {
        "composer/installers": "^1.2.0",
        "ueberbit/publication_date": "dev-2.x#412fa4e"
    }

I'm no composer wizard so this can likely be improved :)

Would love to see a coordinated release soon.

dddbbb’s picture

Muppetry. Removed :)

tsplash’s picture

The 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.

webflo’s picture

Version: 8.x-1.x-dev » 8.x-2.x-dev
Status: Needs review » Fixed

Hello 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.

webflo’s picture

Tagged 8.x-2.0-beta1 a few minutes ago.

dddbbb’s picture

Whooop! Great news.

Now let's get it into D9 core :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.