Editing post dates would be useful

[kevinmarks]

A key use case is gathering in items that have previously been published earlier - not being able to edit the post date means that order of posts can't be changed, and that they all look current rather than historic. eg andrewmarks.media and the music mixes

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[benwerd]

Agree completely. Editing them to be in the future also seems like a handy feature.

[gtrias]

+1 Set post order would be much appreciated

[danito]

" Editing them to be in the future also seems like a handy feature."
another new status for #937 : publish on dd/mm/yyyy

[pierreozoux]

Is this "feature request" for past and future, or should we have 2 feature requests?
(I want to post a bounty on it, and I'd like the 2 features actually)

[benwerd]

Past and future are different problems - past is simply a different
country, whereas future requires scheduled posts and some kind of cron
integration.

On Thursday, December 31, 2015, Pierre Ozoux notifications@github.com
wrote:

Is this "feature request" for past and future, or should we have 2 feature
requests?
(I want to post a bounty on it, and I'd like the 2 features actually)

—
Reply to this email directly or view it on GitHub
#411 (comment).

Ben Werdmuller
http://goog_1933028737
benwerd.com | werd.io

+1 (312) 488-9373

[jgmac1106]

Can this be done in the database now?

[mck182]

Yes, but it's quite tedious from what I remember (done it over a year ago),
I think it involved downloading the json from the database, editing it and
uploading back.

There are actually two dates, you need to change both (or just the one that
determines the sorting, can't remember the details though).

[kylewm]

Yeah agree editing the database directly would be a hassle -- you'd need to edit the timestamp in entities.created as well as the "created" value in the JSON blob in entities.contents, and probably also update the metadata table for queries to work properly.

I backdated a few posts last night with a short php script that I put in the known directory and ran from the command line...

<?php

$_SERVER['SERVER_NAME'] = 'kylewm.com';
$_SERVER['SERVER_PORT'] = 80;
define('KNOWN_UNIT_TEST', true);

require_once __DIR__ . '/vendor/autoload.php';
require_once __DIR__ . '/Idno/start.php';

$site = \Idno\Core\Idno::site();
$user = \Idno\Entities\User::getByHandle('kyle');
$site->session()->logUserOn($user);

$slug_to_date = [
    ['farkling', '2016-01-23T02:13:39.000Z'],
    ['oh-murphy', '2016-01-23T01:24:05.000Z'],
    ['the-craftsman-at-work', '2016-01-24T19:25:51.000Z'],
];

foreach ($slug_to_date as $arr) {
    $entity = \Idno\Common\Entity::getBySlug($arr[0]);
    $entity->created = strtotime($arr[1]);
    $entity->save();
}

$site->session()->logUserOff();

[cleverdevil]

This topic came up today in IRC / Slack, and I do think its something we should roadmap for 1.0. What do you think @mapkyca and @benwerd? I'm happy to take a crack at it with some guidance.

Ideally, I'd like to do this by updating a default template for editing an entity. What would the appropriate template be? I see:

• default/entity/editwrapper
• default/entity/edit/footer
• default/entity/edit/header
• default/entity/edit/spinner

Guidance would be super helpful!

[mapkyca]

So, date editing is actually a fairly involved subject to do correctly, and isn't just a simple matter of changing the create time.

Most entities save methods do listen for the "created" input, but this isn't passed by any of the forms, so at first glance all you'd need to do is make this editable. However, it's not the whole story.

From the data model point of view created != publish, so I actually think we need a third date column on the entities table, and then modify stream functions to only show things with a publish date in the past.

Additionally, there's the issue of how we handle urls if an entity is modified after it has already been published. Do we modify the slug, or do we preserve the old url? The answer to this, I think, is "yes". We create the new url, but implement entity tombstoning to redirect the old url magically (#1742)

So, we need to:

• Modify the data model to add a publish field
• Modify stub creation to key of publish not create
• Figure out a way to future date entity publish hooks (e.g. posse hooks, pubsub, etc), ideally without cron or message queues.
• Hide future dated publish fields from feed search (although this presents the problem of how you'd come back to edit it, meaning maybe we need to implement a more Wordpress style admin/user view, vs blog view)
• Implement tombstoning and redirects

Even without scheduling for future dates, simply editing the past dates actually represents a fair amount to think about.

[cleverdevil]

Definitely more complex than I assumed! Thanks for the rundown. I do think its worth pursuing.

[mapkyca]

I don't disagree

[willowbit]

Just wanted to bring this fairly old issue up. To me Known seems to be nearly feature-complete, but this is essential for anyone (like me) who is trying to migrate from another software.