Note: 3.32 is released to address a XSS problem found, so the next feature relase is 3.33

Note: 3.33 is also released to fixes a recently discovered security issue.

Suggestion: Maybe we can use the version number 3.40 instead of 3.34 for the next release. (kg)

Here’s trying to capture all proposed features for the next release. Once we collect enough information, we can decided what features to take on and who will work on it. 8)

Tentative release date: May, 2008 (it will be later )

It’s going to happen sooner or later. PHP announced to stop support @ Aug 2008. see here. So we should start moving into PHP5.

The good news is latest Nucleus code already running under PHP5 (test on v5.1.6). It’s mainly an announcement to user community that NucleusCMS will dropped PHP4 support and no guarantee it will continue to function in PHP4 environment.

kg proposed to stay w/ PHP4 until PHP5 is widely adapt, meanwhile NucleusCMS continues to re-factor toward OO.

admun: I guess I am cool with kg’s plan. I think support for PHP5 and stopped of PHP4 support can proceed in parallel. In 3.33, we will announced intension to stop PHP4 support in near future. Make sense?

⇒ Version 3.5 will only support PHP 5 (kg)

I think it is good to make clear that PHP 5 in plugins is not a problem with all versions of Nucleus CMS. The only thing to do is to give the users a hint like “requires PHP 5”. If some plugins use the new features of PHP 5 it would encourage users to see the advantages of accounts with PHP 5.

It seems slowly gaining traction, and many heavy weights are on the wagon. There are 2 area of support we are aiming to provide:

• using Nucleus blog as OpenID server to authenticate blog member by external website
• authenticate commenter w/ OpenID (so only OpenID user or member can make comment)

There are a few openID plugins for wp already, we can use as reference: OpenID Provider for WordPress MU, Simple OpenID plugin, WP-OpenID

Maybe we can integrate with phpMyID

Developer: admun

⇒ A new event makes it possible for plugins to implement a OpenID solution: Revision 1294

Many plugins required cron to function, but often many users do not have access to it.

This plugin will: * provide interface for plugin to schedule task * utilize method similar to NP_Ping w/ JustPost event and back-end script, tasks will be executed in the background.

Developer: kg

⇒ No changes of the core necessary: can be realised with the PostSkinParse event.

Bundled Javascript based Ajax library like jQuery (other suggestions??) to provide action/event that plugins/skin/admin area to use.

Application:

• Admin menu to show action response like WP and many Ajax based webapp already do.
• Change plugin order interactively.

⇒ Not decided. But currently it is possible to embed a javascript with extrahead.

Currently, we are using NP_MultipleCategories to achieve multiple categories, but I think it will be much better for this plugin to be integrated with Nucleus core.

Currently, we are using NP_ShowBlog and other plugins to achieve that. A build-in pagination has been a often asked function.

kg:
Advantages of a inbuild solution:

• all pages can be paginated, also archive and search pages
• with skinvars (like <%previouspage%>, <%nextpage%> ...) every use can decide if he want to use the inbuild solution

Implementation questions:

• the basic implementation is easy (if have done tried it on my local computer)
• the testing needs time, because there are several cases which must be considered

admun: can it be used by plugin in menu? There are many plugins I wrote have to add pagination i.e. NP_NotifyMe and others

Currently, there are NP_TechnoratiTags (now a general tagging plugins, but lack of excellence integration w/ Admin menu), NP_ExTags, and NP_Tags families (which is hard to install).

Maybe the core to introduce a new skintype itemlist for a result list and a function readItemList which can read a list of items, eg. array(3,11,17,29) where the numbers are the item ids

admun: IMHO, NP_TechnoratiTags already provide good tagging support. 8)

⇒ New function makes it possible to show ItemList: Revision 1295

Since I program plugins I had the wish to have some headlines between the options to give them a more logical order

admun: More info...??

There are still some text string in the code that should move to the language files.

Examples:

• Installer
• first posting pp

admun: further, maybe we can move to Gettext library?

Developer: admun Status: Coding completed

Nucleus should have consistent naming throughout, in particularly regarding variable / array names when they deal with database fields.

For example, it works fine, but it’s a bit un-intuitive that comments now have “cmail” and “cemail” fields, and then they’re referred to differently in arrays as (if I recall correctly) $comment[’userid’] and $comment[’email’]. Whatever happens, it should be consistent. In this instance, it’s because the separate email field is rather new and cmail used to contain either a URI or email address, but now it is only for URI. (On a related note, we should probably make the upgrade script parse through the existing comment rows and separate email addresses out of cmail and put them into the cemail field).

abolish the use of tables in the admin area for layout. We’re XHTML compliant, but still using tables for layout? C’mon. :)

admun: Maybe we need to re-factor the admin menu for that. some idea come to mind: OO, Ajaxize, w/ XHTML 1.0 compliant.... looks like a big piece of work...

It’s the time to say thanks and good-bye to MD5. Currently Nucleus stored password in database as a MD5 hash.

By using SONY Play Station 3, over 1.4 billion MD5 calculations a second is possible (http://www.pcworld.com/article/id,140037/article.html ), meaning that any password with 8 alphabets/numbers can be hacked in 2 days. So, using MD5 hash is now almost the same as using plain text! In the near future, MD5 may be completely hacked and password may be calculated in a second.

PHP5 (>=5.1.2) supports SHA512 as hash engine. I suggest using this method to store the password in database. PHP4 does not support SHA512 but does SHA1 (>= 4.3.0). I guess, we need to use SHA1 instead of MD5, if SHA512 is not available.

I also suggest to use “salt” for the hash (http://www.developerfusion.co.uk/show/4679/3/ ), because the password cracking is also possible for SHA1/SHA512 when the leak of hashed value occurred by SQL injection etc.

admun: agreed, I think md5 is proved to be weak these days. However, since we might not be moving into PHP5 yet (only announcing soon PHP4 support end of life, see above), we need a plan B for this. It’s reported that PHP4 supports SHA1 too....

• Currently, mysql.php in the core mapped mysql_* w/ mysqli_* so Nucleus works on PHP5.1
• A subset of sql_* (sql_connect(), sql_table(), sql_disconnect(), sql_query()) is defined in globalfunctions.php to provide a basic DB layer to all Nucleus functions.
• We can expand sql_* API to map the rest of mysql_* API
• Also, the core should convert to use sql_* API.
• This create a base DAL for future.

There has been some problems with $CONF[’Self’], IndexURL that causing Item URL creation incorrectly. It’d be nice to simplify the base URL infrastructure.

Developer: admun Status: code submitted

• ATOM 1.0 skin
• caching system
  • a plugin infrastructure to allow plugin to register and mark it’s skinvar as cachaible or not. It should also allow plugin to mark contents as “dirty”, hence the page will be regenerated on next page access.
• skinable admin area
• karma vote out of core into plugin
  • see here -Armon
• full UTF-8 support
• GetText support
• Data Abstraction Layer (maybe switch to PDO???), SQLlite support

• Nucleus_CoreDev_340_and_beyond
• General "sketch" analysis of NucleusCMS: a deep analysis about Nucleus internals (still a draft). Worth reading.
• http://wakka.xiffy.nl/project:roadmap
• http://dev.nucleuscms.org/tracker/
• A feedback from end-user

Changes in Nucleus 3.40