39 replies to this topic

[MarionRaven]

hello everybody,
I realized that this nice module can even be used with repeater to schedule not a whole page but just an element on a page since by means of repeater this element really is a page anyway.
but there is a hindrance to this idea. it's works nicely if I run the function RunSchedulePages by "Include & Bootstrap".
but it does not succeed if the function gets called by LazyCron. I guess the reason is, that "find" yields no hits, cause it is an admin page. If I am right, this may be a concern in other cases too.
So I ask you experts for help.

[formmailer]

I haven't had time to test with repeatable elements yet, so I am not sure how this works. Maybe someone else has a suggestion and if a change to the module is required, I'll be more than happy to update the module.

/Jasper

[ryan]

MarionRaven I think you are right about the reason why it's not working, because of the find(). Though not positive why it would work in the include & bootstrap context you mentioned. But I think it may be as simple as updating the two find() calls in RunSchedulePages() to have an "include=all" added to their selectors, i.e.

$unpublished = wire("pages")->find("status=unpublished, publish_from<$time, include=all");
$published = wire("pages")->find("status=published, publish_until>0, include=all");

If you test it out, let us know. My only concern would be that "include=all" may override the "status=", but hopefully not. If it does, try instead to add "check_access=0" rather than the "include=all".

[MarionRaven]

formmailer, yes I got it to work.
ryan, I already found a hint from apeisa in another threat concerning include=all.
I ended up with

$published = wire("pages")->find("include=all, status=published");
foreach($published as $p) {
The conditions regarding publish_from and publish_until are not part of the find. They are handled in the foreach loop.
That solved my issue.

Thanks both of you.

[formmailer]

Glad you solved it!

/Jasper

[yellowled]

I just installed this locally to evaluate it. The datepicker only offers the option to set a date, but if I set the date, the datepicker input field is set to "08.08.2012 hh24:08:ss" … and I have a feeling this is not intended behaviour?

[formmailer]

Hi!

I haven't seen this behaviour before. I just tested it and could not reproduce it.
For me the dates shows like on the attached screenshot.

Are you using WAMP/XAMPP locally or are you running a local linux server?

/Jasper

Attached Thumbnails

• 

[yellowled]

Are you using WAMP/XAMPP locally or are you running a local linux server?

Local LAMP. Ubuntu 12.04, Apache 2.2.22, PHP 5.3.10, MySQL 5.5.24.

[Sevarf2]

After install i got this notice

Notice:Undefined index: cronInterval in/home/public_html/site/modules/SchedulePages.module on line188

[Ralf]

I just installed this locally to evaluate it. The datepicker only offers the option to set a date, but if I set the date, the datepicker input field is set to "08.08.2012 hh24:08:ss" … and I have a feeling this is not intended behaviour?

Hi!

I haven't seen this behaviour before. I just tested it and could not reproduce it.
For me the dates shows like on the attached screenshot.

Are you using WAMP/XAMPP locally or are you running a local linux server?

/Jasper

@ Jasper

i didn´t think that this is a local problem from the LAMP because I can reproduce the problem from yellowled on a server at a ISP.

I thought that the Problem that yellowled and I have is that we CHANGE under SETUP -> fields -> publish_from -> Details -- the "Time Output Format" from 14:20:30 to 14:20 !!

and so i get the SAME Error as yellowled have with the output "15.08.2012 hh24:08:ss"

I change the Time Output Format back to 14:20:30 an ALL works like a charme

Did you have any solution for this??

[apeisa]

There is a bug (probably mine ) in current code.

From line 157: https://github.com/f...ges.module#L157

// Publish pages with a publish_until date > current date
if($p->publish_until > $time) {
  $p->removeStatus(Page::statusUnpublished);
  $p->save();
}

If you have unpublished page where you have set publish_from field, but left publish_until empty, then it won't get published. I think this is the most common scenario, so strange that this hasn't popped earlier. Easy fix though:

// Publish pages with a publish_until date > current date (and publish_until is set)
if ($p->publish_until > 0 && $p->publish_until <= $time) {
  // We keep it unpublished, since publish until is set and valid
} else {
  $p->removeStatus(Page::statusUnpublished);
  $p->save();
}

I know that could be achieved with simple if instead of if else, but I think the logic is simpler to understand that way.

[formmailer]

Thanks, apeisa. I just pushed the bugfix to Github.

@yellowled and Ralf: I'll take a closer look att the datefield issue soon.

/Jasper

[apeisa]

Datefield bug might be unrelated to this module. Pw improved datefields recently and some fields need re saving.

[formmailer]

Datefield bug might be unrelated to this module. Pw improved datefields recently and some fields need re saving.

I know, I am going to test with the latest PW version and see how that's working.

[renobird]

Hi Jasper,

Just installed this module (running 2.2.9) and I get this warning:

Warning: preg_match() [function.preg-match]: Compilation failed: unrecognized character after (?< at offset 6 in /x/xxxx/xxxx/xxxxx/wire/modules/Fieldtype/FieldtypeDatetime.module on line 175

Does this hook into the FieldtypeDatetime.module somehow?

I'm not sure what was going on there. I uninstalled/reinstalled both modules and the warning is gone.

[formmailer]

Renobird,
I don't know what happened either, but yes, this module relies on the DatetimeFieldtype.

/Jasper

[renobird]

Thanks Jasper,

Gremlins I guess. All seems well now.

[apeisa]

I found one bug with this module. I have set the cron to run every minute. I had only one page where I have managed publish settings. Then I started to see this error message on any admin page every now and them (I would assume that it would occur once a minute):

Page saved, but not published. Change publish until setting if you want to publish this now.

I'm not sure, but shouldn't this problem go away if we could restrict afterSave() method to run only when saving page through admin?

[teppo]

@formmailer: it's a bit late to say this, but thanks for making this module -- it has been very useful!

 

Also wanted to mention that we've been running this in current dev branch (future 2.3) on couple of sites for quite a while now without any problems, so I'm pretty confident you could already add 2.3 to "compatibility" field at modules page.

[formmailer]

Hi Teppo!

It's great to hear that this module is useful.

I haven't had time to develop new sites or  projects during the past few months, so I haven't been able to test the module in the development branch myself.
I am happy that it works there as well. Thank you for letting me know.

And thanks for the suggestion you submitted via Github, it has been merged now.

/Jasper