Форумы / Cotonti / Core Labs / small request for functions.php

have a minumum year in parameters

ez
#1 29.07.2011 19:25

function sed_selectbox_date($utime, $mode, $ext='', $max_year = 2030, $min_year=1902)
 

1902 for min year is a long time ago.... maybe add a parameter to this function

and maybe set it to 1930 or something by default... it saves some entries (28).
If used on pages you could use like 1980 as minimum, and for age in profile 1902 is ok :) (nice old user)

==- I say: Keep it EZ -==
Trustmaster
#2 29.07.2011 20:23

Well, the parameter is already there ($min_year). We just need to set it to a better value for pages (and maybe some other places too?)

May the Source be with you!
ez
#3 30.07.2011 07:07

Hi Trustmaster,

Thnx for answering.

In my version the parameter is not there yet... 0.615 (maybe upgrading to 0.617 will do that).
I can imagine some configuration settings for this in pages. It really has no use to show 1902 as a startdate for pages unless you are are making a history website or something. (For userprofiles that should start like 1930 or so)

It will save some microseconds from loading time :) in pages for sure...

This is such a small thing... i know..

greets,

ez

==- I say: Keep it EZ -==
Trustmaster
#4 30.07.2011 08:02

Sorry, my bad. That parameter already existed in Siena only. I have added it to Genoa too, see this commit.

May the Source be with you!
Kingsley
#5 30.07.2011 12:25

If you are fixing the times on pages.. maybe a longer period tht one year for pages? or set it so that an admin can choose a default length for article lifetime

 

just my 2 cents..

ez
#6 31.07.2011 09:17

good one, i always wanted to have that :)

==- I say: Keep it EZ -==
GHengeveld
#7 31.07.2011 10:04

I think the selectbox thing should be made more user friendly with client-side scripting (javascript). There's plenty of scripts available that make date/time selection a lot easier. Cotonti can't really do much to make the process easier.

The expire time is an interesting one. De default value of one year makes no sense, it can potentially be anything. A configurable default lifetime would indeed be a good addition (possibly even configurable for each category). Another thing I want to see added is a checkbox 'Never expire' that disables or hides the expire time selection boxes if checked. Of course this is a client-side feature as well.

There's more to this topic by the way. For example the page_date shouldn't be editable (it's the initial post date). The page_begin should be used as publication date and page_end should be considered 'never expire' if it's equal or less than page_begin. And of course pages should actually expire after page_expire (instead of just remain available).

pieter
#8 31.07.2011 12:58

"page_date shouldn't be editable"

I do not agree. Sometimes you want to switch 2 items in news. Even if there is one older than the other.
This can be done with changing the date.

... can we help you ...
ez
#9 01.08.2011 06:59

@Koradhil
Yes there are plenty of datepicker scripts out there. But the current one is fairly simple and is pretty good (everyone gets this).
Just like i said make the list somewhat shorter, 1902 is a bit overdone, so some flexibility in start and endate would be very very welcome.
I made that little corehack for startdate, because i wanted to use the datepicker in a plugin... but i did not wanted 1902 :) i wanted something like -5 yrs to +10 yrs

The expire time..... Yes, the flexible setup for the default expire time (1 month, 2month, 1 yr, 2 yr... never expire) per pagecat is a real nice addition

About the page_date.. i have to agree with pieter... leave that in please...  Sometimes this comes in real handy :)
 

==- I say: Keep it EZ -==
GHengeveld
#10 01.08.2011 09:52
You dont understand, page_date is what page_begin should be. Articles should be ordered by page_begin instead of page_date and page_date should only be used as a reference for knowing when the first version of the page was added. Actually there should also be a page_updated that indicates when the page was last modified. This is common REST behavior.