Jump to content
formmailer

Release: SchedulePages

Recommended Posts

Hi Jasper, I was ready today to trying the new version.

After installing, when going to edit the module's prefs, I get a blank page and this:

Error: Using $this when not in object context (line 202 of /.../site/modules/SchedulePages/SchedulePages.module) 

Share this post


Link to post
Share on other sites

Hi!

I made a mistake when making the module translatable. Sorry about that.

I just pushed a new version to Github that should work.

/Jasper

  • Like 1

Share this post


Link to post
Share on other sites
Hi, this could be another error with translations (seen in github code):

 ( $this->_("Your....

If I understand that correctly from reading the api manual, in modules the writing is differently  ( __("Your....

but I am not a modules programmer myself, so I can't tell for sure.

By the way: I had another mass-unsubscription today. Unfortunately I forgot to activate the module's new log-feature and have no details for you. Next time you get more info from me)

EDIT:

Funny that pages got unpublished that had no content in any of the 2 schedule fields.

There might be something with the searches;

$unpublished = wire("pages")->find("status=unpublished"); 

Does this actually find anything, if the user isn't superuser? Or is ";include:all" needed here?

$published = wire("pages")->find("status<" . Page::statusUnpublished . ", publish_until>0");

Why isn't the opposite of above code is used (status!=unpublished) but this fancy :: double colon scope operator instead (and what works better)?

Does this reliably exclude pages that have no content in the scheduled-fields? (In my case, pages with publish_until=0 were unpublished.)

Does it play a role that "setOutputFormatting(false)" is executed in the script and might influence time calculations somehow?

EDIT2:

I am on module 1.1.1 and PW dev.

Share this post


Link to post
Share on other sites

Hi!

You are right about the translation errors, I thought I got all of them now, but might have missed one. :(

The reason why I used <" . Page::statusUnpublished is because the status can be something else as well. This includes:

Page::statusOn (1)

Page::statusLocked (4)

Page::statusSystemID (8)

Page::statusSystem (16)

Page::statusHidden (1024)

But not

Page::statusUnpublished (2048)

Page::statusTrash (8192)

In my test setup all the searches seems to work fine.

SetOutputFormatting(false) is needed to get the date in unix timestamp format, so it can be easily compared with the other values.

It would be interesting what the logs say if it happens again.

//Jasper

Share this post


Link to post
Share on other sites

OK I could catch a log now. Fortunately I had deactivated save() this time. so no damage happened.

Example:

2013-08-23 00:06:28    guest    http://www.mydomain.com/en/contact/contact-in/    Unpublished /en/help/ with publish_from value of 1970-01-01 01:00:00 and publish_until value of 1970-01-01 01:00:00. Current timestamp is 2013-08-23 00:06:27.

I can email you personally the full log with the correct links that I did not want to expose here.

Interesting is that the first url is always the same and that specific page one hold the "clock" script that is still under my suspicion to be the conflicting script.

So, renaming that one variable did not help.

I can give you full access to everything you need to investigate, but not over this forum. I write you a PM.

EDIT:

1970-01-01 01:00:00  is a value that is stored in the database for the "empty" publish_until field (instead of 0 or NULL).

So the problem might be a time string conversion problem. - I use a non-default setup of the publish_until time field:

{"dateOutputFormat":"Y-m-d H:i:s","dateInputFormat":"l, j F Y","datepicker":1,"_dateOutputFormat":"Y-m-d","_timeOutputFormat":"H:i:s","size":25,"description":"At this date this page will go offline.","tags":"all-Page-Controls","columnWidth":50,"_dateInputFormat":"l, j F Y","dateOutputFormat1231":"Y-m-d H:i:s","dateOutputFormat1234":"Y-m-d H:i:s","collapsed":2}

Share this post


Link to post
Share on other sites

I also recognized that daytime fields in pw once set and saved then cleaned again it saves the field with the 1970 date. This is like 0 timestamp. It is ok when using in api but when directly queried from db you get the date so you have to take care of those. This is clearly a pitfall and should be fixed. I think I even reported this long time ago on github but not sure anymore.

Share this post


Link to post
Share on other sites

Just a quick note:

I still believe that the offending part that causes all this might be the usage of date_default_timezone_set in PHP at another script somewhere else which seems to have unintended side effects on the module's script. That would explain why the script is only hurting me and almost no one else. (I de-activated that other script and will do some more logging now.)

Share this post


Link to post
Share on other sites

Hi, 

Since the previous logs showed that the unpublished pages have a publish_until date set to 1970-01-01 01:00:00 which actually is a Unix timestamp 0.

Could you please try something for me?

Please change line 180 from:

 if($p->publish_until <= $currenttime) {
 

into

if($p->publish_until <= $currenttime AND $p->publish_until > 1) {
 

This would prevent the module from unpublishing pages with the 0 (1970-01-01 01:00:00) value set in the publish until field and should resolve the issue (although it isn't a pretty solution. :) )

Let me know if it works. If it does, I'll push a new version to Github.

/Jasper 

  • Like 2

Share this post


Link to post
Share on other sites

Hi, this looks like a clever idea. It's pretty enough ;-)

I put this online and continue with loggings. 

Share this post


Link to post
Share on other sites

Any news if the issue is solved with this?

Share this post


Link to post
Share on other sites

I installed this modules as I have a need to a scheduler, thanks for all the work put into it.

I have a problem that the scheduler doesn't run then visitors visit the site. It only runs when I am logged in. This doesn't make a lot of sense, and I'm suprised that nobody run into this? Any ideas?

Also it would be nice when installing if it would check if fields already exists and only try to create them if not present. I already had them created beforehand with the same names (lucky) without knowing I would install this module. 

Also when deinstalling the module I'm not sure It should try to remove the fields at all ,even if the fields are not used on any template anymore. Maybe the dev wants to keep them.

Thanks

  • Like 1

Share this post


Link to post
Share on other sites

RE: Ahhh, I think I found what the problem is. It's that I have template cache enabled for most pages. Any ideas how to make it work with cache enabled? If that makes sense at all :)

Edit: Need to analyse this a litte if this is a problem at all. If at least some pages are not cached, or cache gets newly created for any of the pages, it should trigger tha lazy cron. So I can see this is not as much if a problem as I first thought.

Share this post


Link to post
Share on other sites

Any news if the issue is solved with this?

Hi, I had the logging ON (debugging mode ON) and the actual actions OFF (commented those lines out) so I could monitor for 2 months how the module behaves.

I checked the log in messages.txt on both the staging and the live server and found no mass-unpublishing any more.

Looks like the issue I had was solved indeed (I am using the dev version of PW, and PHP 5.3).

  • Like 1

Share this post


Link to post
Share on other sites

@Soma, I believe that you are right about the lazycron and cache. But if this is an issue (eg. with a very long cache time and (nearly) all pages cached, it should be quite easy to edit the module so that it can run using a regular cron job on your server.

@Ceberlin That's good to hear. :D

//Jasper

Share this post


Link to post
Share on other sites

I've testing the scheduler and I had this morning a strange behavior for a page I was testing yesterday where only the publish from is filled with a datetime past the current time. The scheduler is set to 2min. I had the page unpublished and tried to see it would get published and this was what I got in the log for this page:

It was getting published and then unpublished at the same time... 

2013-12-04 10:30:27    guest    http://removed/    Published /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 10:30:27. (SchedulePages)
2013-12-04 10:30:27    guest    http://removed/    Unpublished /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 10:30:27. (SchedulePages)
 
2013-12-04 11:01:58    guest    http://removed/    Published /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 11:01:58. (SchedulePages)
2013-12-04 11:01:58    guest    http://removed/    Unpublished /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 11:01:58. (SchedulePages)
 
Really strange. And I was trying to find out but couldn't. I set the published_until and tested again but seems like it is gone away. I blanked the publish_until again and still couldn't get the behavior as before.
 
I tested with other pages but no luck. 
 
BTW I added before all testing, the suggested text fix you mentioned some posts earlier
 
#180 if($p->publish_until <= $currenttime AND $p->publish_until > 1)
 
I'm not sure what was causing it, and hope it's not something that will give surprises later :)
  • Like 1

Share this post


Link to post
Share on other sites

@Soma: I had planned to debug this a bit further before posting, but since you've already mentioned it: I've been seeing this same issue for couple of days now. Log entries are very similar to yours.

So far I'm guessing that this is somehow related to ProcessWire issue #284, which has since been fixed. At least in my case, where pages just got suddenly unpublished and I'm running dev version just before this fix, this seems to be the culprit.

Taking a look at field_publish_until for one particular page for which it should be empty, it looks like this:

+----------+---------------------+
| pages_id | data                |
+----------+---------------------+
|     9224 | 1970-01-01 02:00:00 |
+----------+---------------------+

Since SchedulePages first finds pages where publish_until>0 and then checks if publish_from <= current time, this particular page getting unpublished sounds logical :)

This might only be applicable to dev branch, but I haven't tested this a site running older release yet. Soma, what version of PW are you running? If you're using dev, could you update it and see if the issue persists?

Edit: Soma, I just realized that you mentioned the issue suddenly going away. Any chance that this was because you updated your PW at some point, applying aforementioned fix? :)

Edited by teppo
  • Like 1

Share this post


Link to post
Share on other sites

I have very latest dev from yesterday which fixes cache delete problem. But the problem was today, BUT there was something happening on date field after updating PW on first load... could be that this page I tested still got an issue with it. As since changing values it doesn't happen anymore.

Share this post


Link to post
Share on other sites

BTW I thought I openend an issue with date fields but maybe haven't. But surely mentioned it in some threads that the date fields get saved with a 1970 timestamp 0 which I ran into when checking dates and empty dates. Hopefully it is now fixed.

Share this post


Link to post
Share on other sites

What I have since the update to latest dev is this on the very bottom of the admin "pages tree" screen...  as mentioned before I thought it was only once but suddenly appeared again:

Warning: date() expects parameter 2 to be long, string given in /home/.../wire/modules/Fieldtype/FieldtypeDatetime.module on line 370

Which appears random it seems and I can't reproduce why, but wasn't there before the update.

Share this post


Link to post
Share on other sites

I think both of these issues are fixed on dev, but please let me know if you are still experiencing either. 

Share this post


Link to post
Share on other sites

Just thought I'd add some more info to this that might be relevant.

I'm currently working on a site that is a work in progress (using the PW dev branch), and I would encounter an initial page load time that was unnecessarily long (I would get a "max execution time exceeded" message) every now and then. To cut a long story short, it was the SchedulePages LazyCron issue concerning the date field having the '1970' value in the DB.

The site in question currently has over 10,000 (imported) news posts that can potentially use SchedulePages. The line below seemed to be returning all of these pages, causing some internal PW page-related functions to time out due to the volume of pages involved.

$published = wire("pages")->find("status<" . Page::statusUnpublished . ", publish_until>0");

My solution was just to run this query to remove the existing rows, so those pages with the incorrect values would not be picked up by the "publish_until>0" selector used in the SchedulePages module.

DELETE FROM field_publish_until WHERE data = '1970-01-01 01:00:00';

After that, using the bleeding-edge dev branch of PW, I tested the publish from/until fields on some posts and the DB rows get added and deleted as they should do.

  • Like 1

Share this post


Link to post
Share on other sites

Since PW Version 2.4 i cant use this module anymore. I think its not really compatible. Every minute, all my pages are automatically unpublished. Unfortunately I have no time to search for the problem. Disable the module helps for now.

Share this post


Link to post
Share on other sites

I've been using this module with 2.4 for couple of sites without issues.

David, your problem sounds a lot like issues reported earlier, i.e. "empty" date fields containing 1970's timestamp. I'd suggest trying what Craig explained above:

DELETE FROM field_publish_until WHERE data = '1970-01-01 01:00:00';

Share this post


Link to post
Share on other sites

If I delete those empty fields (which I successfully did and had no incidents after that)... is it guaranteed that they do not come back?

I want to double check: does PW 2.4 now delete those fields if not used, so that error has gone forever? I think so...

Just for my curiosity: Would it help if the module ignore  pages from unpublishing which are older than, say, 1975 (very old but younger than the infamous 1970)?

Share this post


Link to post
Share on other sites

Hi formmailer, others,

I got the following error: "Error: Undefined class constant 'logOnly' (line 168 of /xxxxxxxxxxxx/site/modules/SchedulePages/SchedulePages.module) 

" in PW 2.3, with debugging turned on.

Thanks in advanced

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Macrura
      PrevNextTabs Module
      Github: https://github.com/outflux3/PrevNextTabs
      Processwire helper modules for adding page navigation within the editor.
      Overview
      This is a very simple module that adds Previous and Next links inline with the tabs on the page editor. Hovering over the tab shows the title of the previous or next page (using the admin's built in jqueryUI tooltips.)
      Usage
      This module is typically used during development where you or your editors need to traverse through pages for the purpose of proofing, flagging and/or commenting. Rather than returning to the page tree or lister, they can navigate with these links.
      Warnings
      If you are using PW version 2.6.1 or later, the system will prevent you from leaving the page if you have unsaved edits.
      For earlier versions, to avoid accidentally losing changes made to a page that might occur if a user accidentally clicks on one of these, make sure to have the Form Save Reminder module installed.
      http://modules.processwire.com/modules/prev-next-tabs/
    • By Gadgetto
      SnipWire - Snipcart integration for ProcessWire
      Snipcart is a powerful 3rd party, developer-first HTML/JavaScript shopping cart platform. SnipWire is the missing link between Snipcart and the content management framework ProcessWire.
      With SnipWire, you can quickly turn any ProcessWire site into a Snipcart online shop. The SnipWire plugin helps you to get your store up and running in no time. Detailed knowledge of the Snipcart system is not required.
      SnipWire is free and open source licensed under Mozilla Public License 2.0! A lot of work and effort has gone into development. It would be nice if you could donate an amount to support further development:

      Status update links (inside this thread) for SnipWire development
      2020-03-21 -- SnipWire 0.8.5 (beta) released! Improves SnipWires webhooks interface and provides some other fixes and additions 2020-03-03 -- SnipWire 0.8.4 (beta) released! Improves compatibility for Windows based Systems. 2020-03-01 -- SnipWire 0.8.3 (beta) released! The installation and uninstallation process has been heavily revised. 2020-02-08 -- SnipWire 0.8.2 (beta) released! Added a feature to change the cart and catalogue currency by GET, POST or SESSION param 2020-02-03 -- SnipWire 0.8.1 (beta) released! All custom classes moved into their own namespaces. 2020-02-01 -- SnipWire is now available via ProcessWire's module directory! 2020-01-30 -- SnipWire 0.8.0 (beta) first public release! (module just submitted to the PW modules directory) 2020-01-28 -- added Custom Order Fields feature (first SnipWire release version is near!) 2020-01-21 -- Snipcart v3 - when will the new cart system be implemented? 2020-01-19 -- integrated taxes provider finished (+ very flexible shipping taxes handling) 2020-01-14 -- new date range picker, discount editor, order notifiactions, order statuses, and more ... 2019-11-15 -- orders filter, order details, download + resend invoices, refunds 2019-10-18 -- list filters, REST API improvements, new docs platform, and more ... 2019-08-08 -- dashboard interface, currency selector, managing Orders, Customers and Products, Added a WireTabs, refinded caching behavior 2019-06-15 -- taxes provider, shop templates update, multiCURL implementation, and more ... 2019-06-02 -- FieldtypeSnipWireTaxSelector 2019-05-25 -- SnipWire will be free and open source Plugin Key Features
      Fast and simple store setup Full integration of the Snipcart dashboard into the ProcessWire backend (no need to leave the ProcessWire admin area) Browse and manage orders, customers, discounts, abandoned carts, and more Multi currency support Custom order and cart fields Process refunds and send customer notifications from within the ProcessWire backend Process Abandoned Carts + sending messages to customers from within the ProcessWire backend Complete Snipcart webhooks integration (all events are hookable via ProcessWire hooks) Integrated taxes provider (which is more flexible then Snipcart own provider) Useful Links
      SnipWire in PW modules directory SnipWire Docs (please note that the documentation is a work in progress) SnipWire @GitHub (feature requests and suggestions for improvement are welcome - I also accept pull requests) Snipcart Website  
      ---- INITIAL POST FROM 2019-05-25 ----
       
    • By horst
      Croppable Image 3
      for PW 3.0.20+
      Module Version 1.2.0
      Sponsored by http://dreikon.de/, many thanks Timo & Niko!
      You can get it in the modules directory!
      Please refer to the readme on github for instructions.
       
      - + - + - + - + - + - + - + - + - + - NEWS - 2020/03/19 - + - + - + - + - + - + - + - + - + - 
      There is a new Version in the pipe, that supports WebP too: 
       
      - + - + - + - + - + - + - + - + - + - NEWS - 2020/03/19 - + - + - + - + - + - + - + - + - + - 
       
       
      -------------------------------------------------------------------------
       
      Updating from prior versions:
       
      Updating from Croppable Image 3 with versions prior to 1.1.7, please do this as a one time step:
      In the PW Admin, go to side -> modules -> new, use "install via ClassName" and use CroppableImage3 for the Module Class Name. This will update your existing CroppableImage3 module sub directory, even if it is called a new install. After that, the module will be recogniced by the PW updater module, what makes it a lot easier on further updates.
      -------------------------------------------------------------------------
       
      For updating from the legacy Thumbnail / CropImage to CroppableImage3 read on here.
       
      -------------------------------------------------------------------------
       
    • By Robin S
      Inspired by a recent question.
      Image Crop Ratios
      Allows preset aspect ratios to be defined per image field for the ProcessWire image crop tool.
      The module adds a select dropdown to the crop tool. Choose an aspect ratio and the crop area will be fixed to that ratio.
      Screencast

      Installation
      Install the Image Crop Ratios module.
      Configuration
      Default aspect ratios for all image fields can be defined in the module config. Aspect ratios for specific image fields can be defined on the Input tab of the field settings. You can override the ratio settings in template context if needed. Insert a hyphen as the first item in the ratio settings unless you want to force a ratio to be applied to the crop tool. The hyphen represents a blank option that allows a free crop area to be drawn. Usage
      Click the "Crop" link on the details view of an image thumbnail. Click the "Crop" icon at the top of the editor window. Choose an option from the "Ratio" select dropdown.  
      https://github.com/Toutouwai/ImageCropRatios
      https://modules.processwire.com/modules/image-crop-ratios/
×
×
  • Create New...