Displaying list of scheduled nodes (contrib)

Whats wrong with the views module? All the sites I maintain have a page and a block with scheduled nodes.

OK. Since it is a tab in the node admin section and the code is really straitforward...

The patch looks good. But could you enlighten me on this part:

  // Default ordering
  if (!isset($_GET['order']) && !isset($_GET['sort'])) {
    $_GET['order'] = t('Post');
    $_GET['sort'] = 'desc';
  }

Is this using documented behaviour or is it a hack? Sure looks like a hack. (No offense, I am just getting nervous when I encounter $_GET in contributed modules).

Scott? Any progress?

Just wanted to see if the Drupal 6 port, mentioned in the original post, was ever created!?

I had also written this functionality before I saw this post. It uses views (as Eric preferred) but no admin work in views is required as the module provides the view. The results are shown in two tabs, 'Scheduled for publishing' and 'Scheduled for unpublishing'. The column titles are sortable and edit & delete links are provided. I also wrote an addition to the 'time ago' format which will now display time periods to the future as well as the past.

Attached is a screen grab. If anyone is interested I can create a patch file. (although I did the work in a separate scheduler_mods module just for my own use, so it is not in a state to be rolled just yet).

Jonathan

I don't even know what the current status of this is. Scott?

If it wouldn't be too much trouble to provide the patch, I would imagine others could benefit. I would think Scott and Eric might like to see different ways of attacking it.

I would commit Scotts patch if I knew if the $_GET[]s are OK.

In the meantime, would someone be willing to use the export option, to export the view they use? It might be easy enough to provide this in a contrib folder of the tarball.

@Superdave913 #12 #14
I could attach here the three files of my scheduler_mods module in their entirety. One of them is an export of the two views I created.

But what would be even better is instead of being a separate module (which I did for very quick development, just experimenting) is if they could be put into a subfolder of /scheduler/ as you suggest, and this could be enabled by an admin checkbox, with default setting = whether views module is installed.

I don't think I want to make the current files public because it is not correct to create a whole new module, and if users get this it could just create more bug issues for us all to deal with. But I will attempt to integrate it into a subfolder of /scheduler/ and then show you what it looks like.

@eric #13
I do not want to conflict with this work. I agree with syscrusher that it could be good to have code in this module which give the functionality without relying on views being installed. I think there should be a good solution which caters for both.

Jonathan

OK, attached are three files for a sub-module of scheduler, which I have called scheduled_content. The three files need to be placed in a new folder within modules/scheduler/. The new folder can be called anything, but I called it scheduled_content just to be consistent. This will create a new module which is dependent on views, so it cannot be used if views is not installed.

When enabled, it creates a new link in the navigation menu under admin->content management called 'scheduled content'. If necessary this link can be moved or copied using the admin menu UI to a higher position in the menu tree where it can bee seen by users who have been granted scheduler permission but who don't have full admin rights.

I am sure there are many things required to improved this code, but at least here is a starter, as requested by syscrusher and superdave913. I have checked it with coder module for drupal coding standards. I am on D6, so you may need to alter quite a bit to test with D5 (sorry).

One thing which does definitely need looking at is that it uses a new time format that I added to my views module code, which is like 'time ago' but displays the time period forward to a datetime in the future. See my screengrab in #10 above. I think this should be implemented within views properly, but until that happens we might need a work-around.

Anyway, please let me know if anyone has any success in installing and using this, or report any errors and bugs.

Jonathan

I merged syscrushers patch manually into the current 5.x cvs version and rerolled a patch (attached).
If someone reviews/tests this ok I will commit it and create a new release.

But we still need a version for 6.x. Lets see, the evening is still young...

Eric,
I have already merged in syscrushers patch into my D6 site and it works fine. To save you the trouble, I will make a patch right now and post it here.
Jonathan

Here is the D6 patch. I rolled it against 6.x-1.3 but I think it should apply reasonably cleanly to the 27th Jan dev version, but I have not checked this.

Hope it helps. Sorry for the delay - due to having to work out how to check two access parameters.

Jonathan

I made it a Tab (MENU_LOCAL_TASK) and commited it.

D6: http://drupal.org/cvs?commit=198724
D5: http://drupal.org/cvs?commit=198726

Thanks a lot!

Nice idea to have it as a tab - much better than a sub-menu link.

I guess you were happy with your concern in #13 about the $_GET ?

May I suggest that the table column titles are changed to 'Publish on' and 'Unpublish on' to match the words used elsewhere in the module and edit form, instead of using 'Post' and 'Hide'.

Jonathan

About the $_GET: The content of is not really used there. The values are set with default values in case they do not exist.

Ofcourse you are right about the column headers. I will change that.

Thanks again,
Eric

D5: http://drupal.org/cvs?commit=199032
D6: http://drupal.org/cvs?commit=199036

Eric,
When you changed the title headers you missed the next bit of code, where 'Post' should be changed to 'Publish on'. Also in my opinion, it is better to have the default sort order Ascending not Descending, so that the next item to be published appears first in the table not last. That seems logical to me, I think, as you are more likely to read the list downwards and assume time flows downwards. The code to change is:

  // Default ordering
  if (!isset($_GET['order']) && !isset($_GET['sort'])) {
    $_GET['order'] = t('Post');
    $_GET['sort'] = 'desc';
  }

which becomes

  // Default ordering
  if (!isset($_GET['order']) && !isset($_GET['sort'])) {
    $_GET['order'] = t('Publish on');
    $_GET['sort'] = 'ASC';
  }

Jonathan

Thanks. You are right.

D6: http://drupal.org/cvs?commit=199750
D5: http://drupal.org/cvs?commit=199752

I've downloaded and tested the D6 version, all correct. Viewed the D5 changes via cvs and looks identical.
Excellent work, thanks.

When I have better integrated and enhanced my views-based version (see #16) I will start a new post to discuss it, so I am happy for this issue to be set back to fixed. I am not sure of the etiquette of me changing the status to fixed, seeing as you have done the commits, so I have left it for you.

Jonathan

The usual workflow would be setting it to "reviewed & tested by the community". I will keep it in this state for a couple of days before setting it to fixed.

Thanks,
Eric

Will this be sparking an official update version release?

@superdave913: There will be a new official release in a couple of days for both 5.x and 6.x.

For some reason the official release isn't appearing on the project page.

Well, "couple of days" is a flexible term...

I was just surprised the ticket was closed before it was uploaded to the project page.

Release 6.x-1.4: http://drupal.org/node/516514

Awesome! Much appreciated!