How to change the published date in the page dialog?

[RuiVP]

I'm trying to migrate a Drupal site to PW, using the export/import csv strategy. Not an easy task at all, considering I'm a total ignorant about php and PW.
Lots of problems, as expected. Here's one I can't figure out how to solve.

I can give up with a few things present in the Drupal site (namely the forum), but for historical reasons it is very important to keep the date published for each page, the author and the visits count.
So, first problem: how to change the publishing date when editing a page? I can't find an item for that in the page editor. Is it there and I simply missed it?

Thanks in advance for any clue.

[dragan]

Hi @bilioso and welcome to the PW forum.

You can edit the publish date programmatically or via module.

Given your situation, it would be far more efficient to do it via the PW API.

If you've imported your Drupal pages to PW already, I hope you also defined and populated a relational ID that relates from PW to the old Drupal site.

If you did that, it's just a couple of lines to update the publish date with the PW API in one go. Let us know if you need instructions (but I guess the first link I posted should give you enough clues)

Disclaimer: I haven't used the module I linked. Although compatibility with PW v. 3.x is not claimed, chances are it will still be working fine with the latest PW version. If not, maybe all that's needed is to add PW namespace in the very 1st line of the module.

[RuiVP]

Thanks @dragan

Sorry for asking in the first place. I realize now that there is already a lot of talking about the subject. The fact that my English is very limited doesn't help on using the right words in searches...

The programmatic solution looks frightening to me, for the moment. I'll try the module solution; or, to avoid future problems with outdated modules, I'll create a date field in the PW template, since it is easy to export a date field from Drupal via csv.

I can't see what means

6 hours ago, dragan said:

a relational ID that relates from PW to the old Drupal site

but I guess I'll get there as I put my hands at work.

[dragan]

8 hours ago, bilioso said:

15 hours ago, dragan said:

a relational ID that relates from PW to the old Drupal site

 

The concept is actually quite simple: A PW field (integer), which you create and use in all templates that you need for the Drupal import. That field can just as well be hidden in the PW admin.

In your export CSV you have to make sure that the unique node ID is present, and then you can match those two fields.

If you don't export/import the published date in your initial migration step already, you can just as well update it later:

$drupalNodes = array(1 => 1601804655, 2 => 1601804674, 5 => 1601804676);
foreach($drupalNodes as $k=>$v) {
    $p = $pages->findOne("drupal_id=$k");
    $p->of(false);
    $p->setAndSave('published', $v);
}

 

[RuiVP]

Thanks for your fast answer, @dragan

This may be a bad decision (newbie's fate), but after having a look at the links you gave and taking good note of @ryan's comments on date creation/etc, I think I will go for the direct manipulation of the database. My reasons are:
1. In several aspects I want the new site to be an straightforward mirror of the old site (dates, visits, urls, etc.).
2. Creating new fields for dates goes against my opinion on what machines should be and should do. Meaning, if the final user is forced to do the machine's work and to understand the machine's entrails in order to use it, having to put there every single detail the machine should be aware of right from the beginning, we'd be better off. The user should be able to focus in only one thing: conceiving and organizing contents. For my experience, if I complicate the editing page with a plethora of fields, the users will run away and in the end I will find myself forced to edit for them, in order to keep the site growing.

Now, let me take a deep breath and get the courage to make some silly questions about the proceeding:

I suppose I need to put the sql query somewhere, to run once, but... Where? Is it in the template.php? Should I write a codePiece.php and put an include_once call in the template.php? (and than get rid of it). And if so, does the codePiece.php need some kind of flag or does php take good care of running only once? Please be indulgent, it is the first time I'm dealing with php, and some parts of the php manual are good for those already with some enlightenment, not for total newbies.

Anyway, I'll have to find the (long) time to experiment with all this, it won't be for today. As soon as I can do it, I'll tell you about the results.

Thanks again for your patience and goodwill.

[kongondo]

@bilioso,

Welcome to the forums and to ProcessWire.

Before you start, please backup everything, especially the databases. 

Secondly, do the import on test site first, whether a local or remote site, but don't try this on the live/production site. Once you've tested things went OK, you can do the import on the live server. For backups, in ProcessWire, there are several options. The simplest I think is this module by Ryan. https://modules.processwire.com/modules/process-database-backups/. You can use it to make backups at different points in your tests. Use that to make a backup of the ProcessWire site before you changed the dates. This will allow you to always be able to go back to that point whenever you need.

1 hour ago, bilioso said:

I suppose I need to put the sql query somewhere, to run once, but... Where?

I am assuming this is SQL executed via ProcessWire? Template file could work. You would add the code to a template file and visit a page that uses that the template that template file belongs to. You would do that once then remove the code. However, a better approach is to use TracyDebugger's code console. You can then run the code there and comment it out or delete it once done. TracyDebugger is really useful to developers. You can get it here: https://modules.processwire.com/modules/tracy-debugger/

Let us know how it goes :-).

Edited October 4, 2020 by kongondo

[kongondo]

7 minutes ago, HarrisReid said:

Try to find the answer in the article about Drupal migration

moderator note

Nice try, but no. The article is about migrating from D8 to D9. I have removed your (advertising) link.

[RuiVP]

I'm still working on migrating my site from Drupal to PW. It will take very long, because I have to do it in my spare time, which has been none lately.

My experiments on this subject are not interesting, compared to some other threads on the same subject in this forum and I would not be offended if the moderators opt for deleting this thread, namely to avoid confusing more other newbies. Nevertheless, I will add now some thoughts about my ingoing migration process:

1. You were right about the importance of making a mirroring field for the Drupal pages id. In fact, I restarted all the migration process from scratch, creating in the PW templates lots of fields to accommodate every kind of value existing in Drupal pages. It turned out to be very useful and I can delete them on PW any time, once the migration process is completed and tested.

2. Migrating multivalued fields is not as straightforward as I would like... It requires some programmatic solution I don't have the skills to implement. Fortunately my site has only a few hundreds of pages and I'm willing to do some kinds of adjustments manually (or, in this particular issue... to give a try with Tracy debugger, via "exploding" an exported line of text from Drupal, containing several values comma separated, and injecting each of them into the corresponding field_pages in PW).

3. My advise to other people facing the same kind of migration: study in-depth the CSS rules in the old site (in my case very flourished and with lots of variants inside the articles) and than try to rethink the CSS rules in the new site using the same naming, otherwise you will end up with a big mess, most of the articles visually destroyed and a lot of work to do by hand. Unfortunately, I didn't do it... On top of that, be prepared to see some CSS formatting (classes and so) magically disappear during the import.csv process (sanitized?).

4. An unexpected problem arose from the combination of stats and pages in different languages. Apparently, Drupal and PW approach the languages issue in different incompatible ways. As far as I understand, Drupal creates different pages (different id) for each language version; PW creates a single page (single id) for any number of language versions on the same page.
This results in a major problem, because I'm required to show in the final rendered page the total amount of visits for each page, since its creation.
Certainly there would be a smart automated solution for this, but once again it is out of my reach.
Plus, I found only 2 modules for counting visits: ProcessPageViewStat and PageHitCounter (simpler and easer to manipulate). But... they are not prepared to deal with languages! And I'm not prepared to transform them into language-aware modules, so this is a problem with no solution at sight.

5. Finally, I gave up manipulating the native "published" field in PW. It is a too messy operation. I opted for creating a new published-date-field - editable by hand, but self-filled with "today date" by default.