JkPublishPages - Module to publish/unpublish, trash/delete or move a page depending on dates and times

[snck]

Great news! ?You could even attach a hook on page save that triggers a warning if a published page is unpublished manually, but will be published by the module again in the future (could work analog for an unpublished page that is published manually, but will be unpublished because of a "publish_until" date in the future).

[snck]

And I just had another idea ?: Pages that will be changed by the module in the future could also be marked in the page tree, e.g. prefixed with a "clock" icon.

[Juergen]

Great idea! I will try to publish the new version as soon as possible, but I cannot say when it will be happen.

[snck]

@Juergen No worries! I am looking forward to it and happy to test, when it's ready. ?

[Juergen]

Hello Flo,

I have pushed the module version now to 1.3.6. This version does not auto populate the fields. I have removed all the Hooks which are responsible for auto population. So this is the one, which fits your requirements and you can use it until the other additions have been implemented.

Best regards

[Juergen]

Hello Flo,

5 hours ago, snck said:

And I just had another idea ?: Pages that will be changed by the module in the future could also be marked in the page tree, e.g. prefixed with a "clock" icon.

should it look like this:

At the moment the icon will be displayed if a start and/or an end time has been set, but id does not take care if a change will happen in the future (publishing or unpublishing of the page)

[snck]

5 hours ago, Juergen said:

I have pushed the module version now to 1.3.6. This version does not auto populate the fields. I have removed all the Hooks which are responsible for auto population. So this is the one, which fits your requirements and you can use it until the other additions have been implemented.

Hey @Juergen, thank you! That was so quick that I am not sure whether I can test and implement it before you release the next version. ?

43 minutes ago, Juergen said:

should it look like this:

At the moment the icon will be displayed if a start and/or an end time has been set, but id does not take care if a change will happen in the future (publishing or unpublishing of the page)

Visually it looks great to me! ?

But I think, the method should be "smart" and also check whether the module has "fired" yet or if it will in the future (which should not be to hard as it is just a date comparison). I think the big value in highlighting pages in the page tree is in reminding the user that there WILL be a change to this page. The user should not be bothered by pages that already have been (un)published by the module and there could be a lot of those.

You could even include a tooltip that gives detailed information on the (un)publication of the page if the user hovers over the clock icon like "Will be (un)published on XX.XX.XXXX – XX:XX:XX".

I really love how quick you implement feedback. Thank you again! ? 

[Juergen]

Version 1.3.7 is out

This version comes up with some new additions as discussed in this forum in the last time.

To check out what is new, please read the changelog.md

As always, please keep in mind, that this is a new version with a lot of changes. I have tested almost all scenarious, but there could always be an unwanted behaviour. So keep an eye, that everthing works as expected. Otherwise please write an issue report (here or directly on GitHub).

Have a nice week!

[snck]

@Juergen Thank you! ? We are still testing it, but it's looking good! A massive improvement over the previous versions. ?

[snck]

@Juergen After testing with a colleague we found some points that could probably be addressed:

• Translations: German translation shows "VERöFFENTLICHT" (instead of "VERÖFFENTLICHT"). Maybe it could just be "veröffentlicht" (no CAPS, but bold)?
• If you have set a publish date (in the past) and save a page as unpublished, you get a warning, that the page will be published on the next run of the cronjob (same for unpublish date...), which is fine. We were asking ourselves, whether the method that is triggered by the cronjob should also run on page save (for pages that have values in the module's fields). This way the warning could be changed to something like "you have set a publishing date in the past, the page can only be unpublished, if you clear the field...". We think that (although the message that is shown is clear about the effects) it is not the best possible experience that a change has an effect, but only for a short time and changes back automatically after that. Warnings might not be read everytime.
• Page tree: If a page is published (because of a publish date in the past) and gets unpublished directly in the page tree, the warning mentioned above is not shown (because it is an ajax request) and the user will not notice, that the page will be published again soon (only if he reloads the page tree manually). I do not know, what the most elegant solution is, but I think, hooking $pages->[un]publishReady() and "stopping" the (un)publish action if it is against the settings in the module fields (and outputting a warning that explains the reasons) would be a solution that also solves the problem mentioned above.

As I said, the improvements are huge already. These are no necessary changes, but suggestions on how the module could become even better. ?

[Juergen]

Hello @snck

First of all, thanks for your feedback!!

The first point is something that could be changed easily and I will correct this as soon as possible.

According the other 2 points, I have to check this out, if it could be changed easily and the work is it worth to spend the time ?

2 hours ago, snck said:

These are no necessary changes, but suggestions on how the module could become even better.

I am always happy, if people post some interesting additions and improvements!!!

Greeting Jürgen

[Juergen]

Version 1.3.8 is out and contains improvements and addons according to the discussion in the forum before

You will find all relevant information inside the changelog.md.

Happy testing Jürgen

 

[Stefanowitsch]

Hi @Juergen!

I just installed the current Version of the module on a website. I am using this module in an older version somewhere else and it works fine there.

With the current version however I get an error message when selecting a publish date in the jk_publish_from field:

 

The date that I've chosen is tomorrow. So this date is definitely in the "future". Why keep I getting this error message?

My field settings are as follows:

[Juergen]

Hello @Stefanowitsch

I see that there is a problem with the HTML5 input and with the separate selects input. I am only using the Jquery UI Picker and therefore I have only tested it with this input and I have not recognized that the others does not work properly.

For the moment, you need to switch from HTML5 to Jquery UI Picker and everything works as expected. I will check this out in the next time.

Thanks for reporting this issue!!

[Juergen]

It is a parsing problem of the date

[Stefanowitsch]

@Juergen okay thanks! By using the Jquery UI Picker it works.

[Juergen]

Hello @Stefanowitsch

I have updated the module and it should work now as expected. I have not the time to test all possible scenarios now, but I could not discover any problems on my local setup.

For more information about the problem read the changelog.md.

Please test it, if it works for you now.

Best regards Jürgen

[Stefanowitsch]

I can confirm that it is working now as expected when using the native datepicker. 

[Cybermano]

Hi Juergen,

thanks for your hard work: it sounds awesome and I will try it asap.

As I understood, this module can operate on the single page when almost one date fields is setted. Right?

Did you considered to perform a batch execution (always based on -a date and time) for all children of a page? Maybe based only to their template?

Let’s imagine this scenario:

A parent page (the main container) having lots of children (more than 1k created by formbuilder with a specific template) and some sub container (backup folders with another template, eg “backup”, so we can have subpages as “backup 2024”, “backup 2025” and so on).

On your experience, do you think it could be possible to move the yearly formbuilder children into the relative backup (even setted by hand into module each year, not necessary programmatically) in one shot? Could be  possible to have any execution time issue?

[Juergen]

Hi @Cybermano

18 hours ago, Cybermano said:

As I understood, this module can operate on the single page when almost one date fields is setted. Right?

Yes, you are right.

I have discovered some problems by using the module on a multilanguage site, so I have decided to unpublish the module now in the module directory, because I have not the time at the moment to make it more stable and to work properly.

Maybe someday I will publish it again, but for now I cannot recommend you to use this module.

Best regards Jürgen

 

[Juergen]

Hello @Cybermano

I have published it again, with a fix for multilanguage sites, but it will take some time until the module will appear in the module directory again. In the meantime you can download it directly from GitHub.

As fas as I know, an action on a parent page will have an effect on all childpages. Fe if the parent page will be unpublished, all child pages will be unpublished too.

For example moving pages to another place. If you move the parent page to directory A, then all child pages will be also moved to directory A.

But it is not possible to select between different templates of childpages. You cannot move child pages with template 1 to directory A and leave child pages with template 2 untouched. Sorry!

It is also not possible to leave the parent page as it is and only move/trash/unpublish,.. child pages.

[Cybermano]

Hi @Juergen

Thanks for your answers.

I will try your module and if possible ask if I can fork it.

In my free time, I will try to add features according to my needs and if everything goes well, I will share my code with you.

Thanks again.

[Cybermano]

Please, note that in the last linked repository your "jk_publish_until" field still has a "none" output format (instead of a [d-m-Y]), that causes a parsing date issue. 

Furthermore I found a little misunderstanding the unpublish description in scheduled plan if the page will be moved in new parent: this page will be remain unpubilshed? It seems no: the page will be unpublished from it's first parent, but it will remain published in the new one. So the page will not be unpublished at all. Or am I wrong?

 

Edited September 30 by Cybermano
Fixed some typos

[Juergen]

Hello @Cybermano

8 hours ago, Cybermano said:

Please, note that in the last linked repository your "jk_publish_until" field still has a "none" output format (instead of a [d-m-Y]), that causes a parsing date issue.

Thanks for the hint. I have fixed this. There was a writing mistake of the dateformat (d-m-Y instead of d-M-Y). If you have the module installed, you need to change it manually at the configuration of the "jk_publish_until" inputfield - if you install the module once more, it will be correctly set during the creation of the field (recommended).

8 hours ago, Cybermano said:

Furthermore I found a little misunderstanding the unpublish description in scheduled plan if the page will be moved in new parent: this page will be remain unpubilshed? It seems no: the page will be unpublished from it's first parent, but it will remain published in the new one. So the page will not be unpublished at all. Or am I wrong?

No, you are not wrong. The page will be moved to a new position and the new status is published (not unpublished). This is a little bit confusing I know, but I guess it would not make sense if you move the page to a new position and leave it unpublished. You can think of moving a page at a certain date to the archive - it would not make sense, if the page is in the archive, but not published. That is the idea behind it.

I am not really happy at the moment with the module, because some code is too complex and probably needs a workover. Anyway, you can fork it and maybe you can add new features or simplify the code.

Best regards

 

[Cybermano]

Hi. Thanks for the clarifications, now I understand the basic idea better.

As I said, I would fork your module to work on it in my free time: I can't assure you of short times, or the completion of my ideas, but I will definitely let you know if there will be any developments.

Best regards.