Zikula Community

• Technobilder
  
  

  • Rank: Registered User
  • Registered: Sep 03, 2007
  • Last visit: May 14, 2010
  • Posts: 48

  Posted: Jan 14, 2009 - 05:24 PM

  With this ticket I notified the core team about 3 month ago that timed news arn't working anymore.
  If you use the news module and set an article to get published at a futere date you will find that it's not there - but sored where it's creatin ID puts it.
  Ticket #302 (closed Bug: not core)
  News Module - Articles are displayed n wrong order when timed
  
  This bug makes the news module unusable for anyone with more than 2 articles per week - as editors need to enter articles now that are published some times later. My website has 80.000 visits per month and I do need a working news module where I can enter articles now to get them published later.
  
  I read the thread for the bug again but I cannot follow the argumentation there.
  Firt the bug was set to major - now it's parked for 1.2.0 - or maybe later someday ... ?
  
  What I don't understand is that this feature worked wit postnuke all the time, so what is that complicated to implement it back now?
  
  News sorted by ID is standard and works.
  News sorted by date/time is too complicated?
  
  Maybe you just go back one step to postnuke, just reinvent the dropped table "autonews" that holds all the articles with a "publish at" date in the future. Then you just need to scan this table - check wether "publish at" is now (then publish) or not now (then do nothing).
  
  For me it looks the easyiest solution is this old fashioned postnuke way - so why play around with ultra modern mySQL5 or Oracle features when it's definitly not necessary?

  • 
  •  
• slam
  
  

  • Rank: Team Member
  • Registered: May 03, 2004
  • Last visit: May 31, 2010
  • Posts: 511

  Posted: Jan 14, 2009 - 06:05 PM

  The News module is not part of Zikula core any more, it is an independent 3rd party project now. Please re-file a bug report at http://code.zikula.org/news - you might even start to volunteer in this project. But keep in mind that the goal is to maintain a simple and easy to handle News module for beginners, not a complex system for bigger sites.
  
  Personally, I have moved over almost all bigger sites with more than one editor to Pagesetter, which provides different dates for created, published and changed together with a flexible workflow for editors.
  
  Greetings,
  Chris
  
  --
  an operating system must operate
  development is life
  my repo

  • 
  •  
• Technobilder
  
  

  • Rank: Registered User
  • Registered: Sep 03, 2007
  • Last visit: May 14, 2010
  • Posts: 48

  Posted: Jan 14, 2009 - 06:52 PM

  As I wrote I opened that ticket already 3 month ago.
  
  Maybe your sites need a Wiki that stores, added, changed, reissued information. But thats no news!
  
  News are entered and published. 99% of all news are published ones and never changed again. So if you are with the 1 percent that needs more - you can use Pagesetter as you like.
  
  As I also want a simple and easy to handle news module - thats what I call simple and easy installation and handling.
  
  Upload news, install in module admin - ready for use.
  
  To use:
  Click on "Enter news"
  - enter headline
  - choose category
  - cut&paste your text
  - click send
  
  Such a simple and easy news module has to be a core module.
  I remember a survey from 2007 asking people which modules they use most and I think news was on top of the list.
  
  
  
  edited by: Technobilder, Jan 15, 2009 - 07:59 AM

  • 
  •  
• Technobilder
  
  

  • Rank: Registered User
  • Registered: Sep 03, 2007
  • Last visit: May 14, 2010
  • Posts: 48

  Posted: Jan 14, 2009 - 07:18 PM

  The main migration bug was to remove the autonews table - that was storing all future articles.
  And reimplementing that table is the easiest way to get this bug solved.
  Same as we all organize our private future tasks by having a "resubmission" basket to look up each day
  
  The simple solution for that bug is:
  1) create a table that stores articles with publishing date in the future, giving them no or temporarily IDs
  1a) Each day scan that table. If the date of an article has been reached: yes=publish with next regular ID, no=next element in table

  • 
  •  
• espaan
  
  

  • Rank: Developer
  • Registered: Aug 23, 2003
  • Last visit: May 31, 2010
  • Posts: 1428

  Posted: Jan 14, 2009 - 08:00 PM

  There are comments already in the ticket that contain the/a solution, but since it is in the process of moving over to a "official" 3rd party module headed by Mateo (and me as sidekick ) the parked tickets should be transfered/copied/whatever to the news project (code.zikula.org/news).
  
  I think a great deal of the webmasters that do use the News module do not use future publication. So they will never have this issue.
  But the removal of autonews and queue tables on upgrade and not merging the articles into the stories table with the correct fields filled in is bad. For upgrades of large sites this should be solved first.
  
  The merging of AddStory, Submit_News and News and the Major cleanup of the code was very successful IMHO. I just browsed through News pn764 code (for http://code.zikula.org/news/ticket/7) and it was awful . Very hard to see what is going on.
  This "bug" is not so straightforward, but I added some comments to the ticket as well.
  
  ValueAddon separation BTW is not there for the Category modules (FAQ, Feeds, News, Pages, Quotes, Reviews) AFAIK until Zikula 1.2 (http://blog.zikula.o…on-finished.26.html).
  
  I must say that the process of parking the Tickets and setting them to closed also at first seemed a bit strange to me, but the tickets are surely not "forgotten".
  
  
  
  edited by: espaan, Jan 15, 2009 - 09:07 AM
  
  --
  campertoday.nl, Module development, Dutch Zikula Community

  • 
  •  
• Landseer
  
  

  • Rank: Team Member
  • Registered: Jan 02, 2003
  • Last visit: Oct 21, 2009
  • Posts: 800

  Posted: Jan 15, 2009 - 02:31 PM

  Quote

  With this ticket I notified the core team about 3 month ago that timed news arn't working anymore.

  
  Sorry if we are not available in hours or minutes after you have opened a ticket to fulfill your personal needs.
  
  

  Quote

  The simple solution for that bug is:
  1) create a table that stores articles with publishing date in the future, giving them no or temporarily IDs
  1a) Each day scan that table. If the date of an article has been reached: yes=publish with next regular ID, no=next element in table

  
  If you think so, then do it.
  
  --
  "He is not dangerous, he just wants to play...."

  • 
  •  
• Technobilder
  
  

  • Rank: Registered User
  • Registered: Sep 03, 2007
  • Last visit: May 14, 2010
  • Posts: 48

  Posted: Jan 15, 2009 - 05:19 PM

  I read the comments but I 'm not sure if I can use a) as a cut&paste fix to my problem.
  I'll try to include this fix when I come home, hope that it will help me until the final solution will arrive.

  • 
  •  
• Technobilder
  
  

  • Rank: Registered User
  • Registered: Sep 03, 2007
  • Last visit: May 14, 2010
  • Posts: 48

  Posted: Jan 15, 2009 - 06:11 PM

  The solution says: [spoiler]There are some solutions:
  1. One solution would be to set the 'from' field to the creation time when the 'nolimit' is set and use the 'from' field in the sorting. Articles with the 'publication from' set to the future will be sorted after articles which have their 'publication from' set to the creation time since the 'nolimit' is set.
  This could be done by changing:
  
  // check the publishing date options
  if ((!isset($args['from']) && !isset($args['to'])) || !empty($args['unlimited'])) {
  $args['from'] = null;
  $args['to'] = null;
  } elseif (isset($args['from']) && !empty($args['tonolimit'])) {
  
  into
  
  // check the publishing date options
  if ((!isset($args['from']) && !isset($args['to'])) || !empty($args['unlimited'])) {
  $args['from'] = DateUtil::getDatetime();
  $args['to'] = null;
  } elseif (isset($args['from']) && !empty($args['tonolimit'])) {
  [/spoiler]
  
  I changed that in pnuserapi.php but the result for the articles is as follows. Still sorting follows the sid instead of the publishing time which if right would give the Articles listed as 1,2,3,4 from bottom up.
  
  Test Artikel 2 (has sid 23)
  Test Artikel 4 (has sid 22)
  Test Artikel 3 (has sid 21)
  Test Artikel 1 (has sid 20)

  • 
  •  
• espaan
  
  

  • Rank: Developer
  • Registered: Aug 23, 2003
  • Last visit: May 31, 2010
  • Posts: 1428

  Posted: Jan 15, 2009 - 06:54 PM

  There was no cut&past solution in the comments BTW. It was merely a summup of things that need to be done, without going into details. I assume you are talking about the comments in the ticket 302 ?
  
  I need to consult with Mateo on how to proceed with this. We need to make sure that the solution is a good one and that no errors are introduced. Maybe I can make a fix that works in the mean time, but I'm not sure if you want that, since the solution later on might change things again (a little bit).
  
  --
  campertoday.nl, Module development, Dutch Zikula Community

  • 
  •  
• Technobilder
  
  

  • Rank: Registered User
  • Registered: Sep 03, 2007
  • Last visit: May 14, 2010
  • Posts: 48

  Posted: Jan 15, 2009 - 07:58 PM

  A fix would be very helpfull - the only way for me to handle 100+ emails with infos a month is to set the publishing date to the future for most of them.
  
  The final solution may change things, I guess thats handable then too

  • 
  •  
•  
•  

Users on-line

• rgasch

This list is based on users active over the last 60 minutes.