OLD To Do List

There are quite a few actions that need to or should be performed asynchronously. These include:

• Sending pings to blog directories
• Double checking referers
• Pruning stats & sessions
• Generating static pages
• Auto updating the antispam blacklist
• Etc...

The plan is to have a table named T_schedule which would store all actions to be performed.

Then there would be a special script like /htsrv/async.php that should be called periodically (either with cron or with a website watchdog service). Typically once every minute.

This script should take an optional password as a parameter to prevent unwanted flooding.

Of course, the script could also be run manually, from a "schedule" tab in the backoffice that would display a neat list of things to come...

The script would look at the next action to do in T_schedule and do the job then report it done.

Typically the fields in the table would be:

• sch_ID UNSIGNED INT AUTO_INCREMENT
• sch_date ENUM(pending,running,finished,failed')
• sch_start_at DATETIME
• sch_repeat_after UNSIGNED INT seconds after which we want to repeat the same task. Once the task is finished/failed, a new one gets scheduled. Note: make sure the new time hasn't already passed!
• sch_action VARCHAR(20) typically 'ping' or 'check-referer' or 'prune-hitlog' etc.
• sch_params I'm not sure about this one, maybe serializing an array() would be the best.
• sch_results Not sure either, but if a ping fails we want the error message, etc... maybe a serialized array() too.

The main issue here are transactions. In an INNO_DB mysql (i-e WITH transactions) you can make sure that you start the next pending task only if it has passed start_at time and it's still 'pending', then put it into 'running' mode before any other instance of async.php tries to execute it).

Without transactions you're kinda screwed! We could workaround this by creating a second table called T_schedule_hanlder with an Primary Key were we would store the ID of the task we plan to execute; if we can insert it without error, then we know we're the first trying to do the task.

With Phoenix we now also have skins in the backoffice, loacted in /admin/skins

Currently these can only be switched through the config files.

The minimum we would need would be a SELECT list on the user profile form were the user could choose his default backoffice skin.

OPTION 1: we could use a SELECT in some corner of the backoffice screens to change the backofficeskin faster. This would be handy 1) for testing, 2) when we happen to log in on a smaller screen than usual or cases like that.

OPTION 2: we could use a checkbox on the profile form saying "use a different b/o skin on each computer". When checked, the SELECT described in OPTION 1 would override the DEFAULT SKIN SELECT from the profile form. This override would be carried out by saving a value for skin #0 in the evostate cookie, see: http://b2evolution.net/dev/todo/2004/04/13/save_skin_for_each_blog

At each request:

1) check if we can get a sess_ID + a sess_key from cookies. These should be matched against the evo_sessions table. If they match, the user is logged in. We can get his ID though sess_user_ID.

Note: sess_key is currently implemented as a poor md5 hash which is flawed. This should be changed to a real random string in the range [A-Za-z0-9]. (We pass the sess_ID along because it speeds up the process; i-e: no need to make sure the sess_key is really unique, nor to index it).

2) if no sess_ID+sess_key is provided, then we need to authenticate through username and password (by the way, no md5 version of the password was ever been meant to be transfered online). If ok, we need to create the session.

OPTIONAL DEV: The session should expire after an admin/user configurable delay if no activity. that means we need to check sess_lastseen on step 1. (some people will want the session to never expire).

OPTIONAL DEV: Checking that the user agent (not in session table yet) or the IP has not changed should also be an admin/user configurable option.

OPTIONAL DEV: for augmented security we could ask for the password again after some time if a critical operation is requested. This needs a lot of work and testing though since you don't want to lose data when a user clicks on "POST" after one hour of editing and gets asked for the password again.

Because this SEO troll is slowy boring me, I'm going to check it out right now:

• link 1
• link 2

Stay tuned for results once the googlebot has cropped these...

Make it so that people have to update there blacklist before they can report new spammers.
For the ones keeping the blacklist up to date (like me) it's a tough job to deprecate all those spammers (because 1 good spam-word was choosen to avoid 200 other adressen).

Here's how I think this should be implemented:

Right now we only have an EDITOR role who can create anything, edit anything and delete anything.

The extra granularity we need is this:
- being able to only create/edit one's own stuff without being able to touch what belongs to others.
- being able to only edit stuff that belongs to someone with a user LEVEL lower than yours.
- being able to only edit stuff that belongs to someone with the same user LEVEL as yours.
(I am talking abou the user LEVELs you see on the user list screen. Those are basically useless currently and waiting for the above implementation.).

(For the sake of simplicity I am deliberately leaving out the "delete" problem. Let's talk about it later, once the "edit" problem is clear :)

The 2 additional LEVEL based cases allow for collaborative editing having a hierarchy of competence.

Furthermore on the lower levels, you might want to allow people to only post drafts and then have someone with a higher level validate those drafts.

In the User Interface, this would translate to the following:
We keep the same "wide" checkbox table we already have, but we replace the 5 checkboxes in the columns for Published, Protected, Private, Draft & Deprecated.

We replace those checkboxes with select lists. In a full implementation those select lists would have all of the following choices:
- No
- Own
- < Own Level
- ≤ Own Level
- All

Of course the current implementation is equivalent to only having the following choices:
- No
- All (except for PRIVATE, see below)

NOTE: for the PRIVATE status, even in the full implemtation, we would only have:
- No
- Own
Because only yourself can see the private posts, so there it doesn't make sense to have editing rights on stuff you can't even see. (We might actually want to allow some super admin to see other people's private stuff but that's different from what we have now and would probably bug quite a few users. "If you don't want people to post private stuff on your blog don't allow them from the beginning").

In the Simple display UI, this would add the following new radio options:
o Not Member
o Member
o NEW: Writer (can post own stuff)
o NEW: Editor (can edit < own level)
o RENAMED: Moderator (can edit anything; this is the existing "editor" level)
o Admin
o Custom

It doesn't hurt if all new scenarios resolve into "custom" in the beginning, however we should try not to break the Javascript when adding selects.

check/uncheck all won't make sense any longer and can probably be removed, since you can select the admin radio in the "Debug" mode. Maybe we should make the debug mode a feature and call it "combined" or sth like that.

I think this can all be implemented very incrementally, one step at a time, without breaking anything, except maybe for the 'magic' javascript. Halton if you can't get the script to work, just let us know and Daniel or myself will look into it.

Okay this is a bit long but nothing too weird I think. Does it make sense?

-François.

PS: I've said it before, but someone should remove the 'non members' part from those screens and replace it with a text entry named "add member:"

A critical security issue has been discovered in the XML-RPC for PHP that most applications use, including b2evolution.

It is highly recommended you fix you installation by downloading this patch file and unzipping it into you /blogs/b2evocore/ folder. This should overwrite the two following files:

• _functions_xmlrpc.php
• _functions_xmlrpcs.php

UPDATE: The authors of the XML-RPC library have released a new version. The previous one may not be sufficiently secure. Thus there is a new patch file available for b2evolution. It must be installed in the exact same manner.

This patch has been tested on the latest 0.9.0.12 "Amsterdam" release but is believed to work on all 0.9.0.x versions.

The patch will be included in future releases.

A moderately critical security advisory has been posted here: http://secunia.com/advisories/13718/

Methods to fix this issue are described here: http://forums.b2evolution.net/viewtopic.php?t=2695

We are encouraging all b2evo users to update their installation.

see http://forums.b2evolution.net/viewtopic.php?t=2732

Interesting suggestions here: http://forums.b2evolution.net/viewtopic.php?p=9176

First, b2e Calendar has both month and years switch, this is great.
the trouble is that the switching links are not next to month and year text, they are gone in a footer.

What would be cool and ergonomic friendlier is on a first line, the links to previous and next month and in-between, the month.
Same for the year on a second line.

example :

< July >
<< 2004 >>
Mon Tue Wed Thu Fri Sat Sun