The following
Feature list contains those features, I plan to implement into the later versions of my
Advanced Link Expirator (ALE) plugin.
"Thinking about this plugin on a funny way, we can say, the ALE (an English beer type) is expiring away from your mind, until tomorrow" . Paul in England may like this joke
Summary of Requested & Planned features of the Advanced Link Expirator (ALE) plugin: 1) Expiration types:
. . .
a. Number of days (expire after X days)
. . . . . . I) expiration start date (Exp_date_start) field is filled (when to start expiration)
. . . . . . II) expiration days (Exp_days) field is filled (after X days to expire)
. . .
b. Expire by Date (expire on date 2002.03.30)
. . . . . . I) expiration start date (Exp_date_start) field is left blank
. . . . . . II) expiration end date (Exp_date_end) field is filled (when to expire the link)
. . .
c. Valid within date interval, then expire (2002.02.01-2002.03.01):
. . . . . . I) expiration start date (Exp_date_start) field is filled (when to start expiration)
. . . . . . II) expiration end date (Exp_date_end) field is filled (when to expire the link)
. . .
d. After displaying X times
. . . . . . I) expiration after X display times (Exp_disp_num) field is filled
. . .
e. After having X hits (clicks) on link with jump.cgi
. . . . . . I) expiration after X hits (Exp_hit_num) field is filled
2) Expiration checking could be activated several ways (advantages are +, disadvantages are -):
. . .
a) Form submit event based expiration checking
. . . . . . + works for Dynamic & Static mode
. . . . . . + faster page display, especially in Static mode (only by comparing to option b.)
. . . . . . + does not take much server resources in full Dynamic mode, when adding, modifying, deleting links
. . . . . . - used form submit events: link Add, Modify, Delete
. . . . . . - may be very slow link adding, modifying, deleting
. . . . . . - takes very much server resources in full Static mode, when adding, modifying, deleting links (for many minutes, depending on rebuild time of changed pages)
. . . . . . - may be very inaccurate for sites with low traffic, because there will be many lately expired links
. . .
b) Page display event based expiration checking
. . . . . . + accurate link expiration
. . . . . . - works only in Dynamic mode
. . . . . . - page display is slower (comparing to the case, when no expiration is done)
. . . . . . - takes a bit more server resources, when displaying a page
. . .
c) Crontab based expiration checking
. . . . . . + very scalable solution
. . . . . . + works for Dynamic & Static mode
. . . . . . + is as much accurate as often the expiration checking is often done (the more often is more accurate)
. . . . . . + expiration checking interval could be set by the user
. . . . . . + does not take much server resources in full Dynamic mode
. . . . . . - takes much server resources in full Static mode, for each check (each check can even last for minutes, depending on last rebuild time of changed pages, and on amount of pages to rebuild)
. . . . . . - each expiration checking process should have enough time to finish page rebuild job. If 2 expiration checking process job overlaps themself the server may become unstable
3) feature to select categories, where to expire links
4) feature to set some links to "never expire" (if no expiration start date and no expiration end date is set for the link, then it will not expire)
5) e-mail notification X days before the link will be expired (might be improved later to be a periodic Reminder feature)
6) e-mail notification when the link expired
7) On link expiration:
. . .
a) delete the link
. . .
b) just put "on Hold", and do not display it. The link can be Re-activated by the user anytime.
. . .
c) move to Expired DB table and delete from there after X days (look at 8.a point). The link can be Re-activated by the user within this second expire time.
8) Re-activate option: the user can be Re-activate those links, which was inactivated in 7.b or 7.c.
. . .
a) keep for X days (in other words, Re-activation is possible within X days)
Please note:
- it is very likely, that the first v1.0 version will contain only a few features of those listed above
- the remaining features will be implemented in later versions.
- altought I got the suggested features into the list, it does not mean, that the feature can be developed into the plugin. All these development problems will appear only when I start the real development.
- the development was just started, the release date is unknown at this time, and it is not scheduled (while I'm developing the LSQL plugins in my free time, I have to do my studies...).
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...