planning:3.50

Nucleus 3.50 Feature Planning

Here’s proposed features parking lot for next NucleusCMS release.

Tentative release date: Aug, 2009

Proposed Features (carry-over from v3.4x)

OpenID

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

NP_PoorManCron

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.

Ajax framework

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.

Build-in Multiple Categories

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.

Build-in pagination for every type of page (index, item, search ...)

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

Seperator for plugin options

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...??

More consistent naming convention

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).

Web standards

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...

Upgrade password, ticket from MD5 to SHA1

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....

mysql_* API warning

  • 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. Note, a side effect is all plugins adapting to this API might break backward compatibility to pre-v3.50 (In reality, getMinNucleusVersion() will returns 350). IMHO, it’s justify because now we can do things on the DB layer (i.e. add memcache support, new DB engine, PDO) and upper layer will not be impacted.
  • Also, the core should convert to use sql_* API.
  • Use PDO where/if make sense
  • There are still lots of plugins out there using the mysql_* API. We should add warnings (print to action log as debug) to ask user to report to plugin writer to change to sql_* API.
  • We can also extend it to support other SQL back-end like SQLite, Drizzle, memcached

Developer: ftruscot

Status: extended sql_* api will be in 3.50. Available and used by core as of build 1370. Need to complete the full support of mysql_* api to include those functions not used by the core. In reality, only the mysql/mysqli backends can be supported in 3.50 because there needs to be a time for plugins to convert over to the sql_* api. 3.50 will ship with a pdo/mysql handler for anyone who wants to test using pdo (for plugin development, etc...). Also, need to decide if better to have plugins that support sql_* api use the getMinNucleusVersion method or the supportsFeature method to declare their support.

Other Features Proposed in the Past

  • ATOM 1.0 skin
  • caching system
    • get NP_Cache/CacheLite works properly
    • add a triggering mechanism to allow plugin to mark cache as dirty, hence flush the cache and re-generate contents on next access
    • add a plugin mechanism to allow other plugin to register and mark it’s skinvar as static or dynamic, hence portion of a page will be regenerated on next page access.
  • skinable admin area
    • de-couple ADMIN class with all other classes, so a new admin panel can be a drop-in. A quick grep found these instance of ADMIN class references:
globalfunctions.php:	include_once($DIR_LIBS . 'ADMIN.php');
globalfunctions.php:	global $REMOTE_ADDR, $REMOTE_PORT, $SCRIPT_FILENAME, $SERVER_ADMIN;
globalfunctions.php:			include($DIR_LIBS . 'PLUGINADMIN.php');
globalfunctions.php:// START: functions from the end of file ADMIN.php
globalfunctions.php:// END: functions from the end of file ADMIN.php
MEMBER.php:		$query = 'INSERT INTO '.sql_table('member')." (MNAME,MREALNAME,MPASSWORD,MEMAIL,MURL, MADMIN, MCANLOGIN, MNOTES) "
MEMBER.php:					include_once($DIR_LIBS . 'ADMIN.php');
MEMBER.php:					ADMIN::deleteOneMember(intval($o->vmember));
PAGEFACTORY.php:			ADMIN::selectBlogCategory('catid',$catid,$startidx,1,$this->blog->getID());
PAGEFACTORY.php:		ADMIN::_insertPluginOptions('item', $itemid);
PLUGINADMIN.php: * @version $Id: PLUGINADMIN.php 1279 2008-10-23 08:18:26Z shizuki $
PLUGINADMIN.php:include($DIR_LIBS . 'ADMIN.php');
PLUGINADMIN.php:		$this->admin = new ADMIN();
PLUGINADMIN.php:    document.write('<?php echo _PLUGINADMIN_TICKETS_JAVASCRIPT ?>');
showlist.php:			echo '<th>' . _LIST_MEMBER_NAME . '</th><th>' . _LIST_MEMBER_RNAME . '</th><th>' . _LIST_MEMBER_URL . '</th><th>' . _LIST_MEMBER_ADMIN;
showlist.php:			echo "<th>"._LIST_MEMBER_NAME."</th><th>"._LIST_MEMBER_RNAME."</th><th>"._LIST_TEAM_ADMIN;
showlist.php:			echo "<td><a href='",htmlspecialchars($url),"' tabindex='".$template['tabindex']."'>"._LIST_TEAM_CHADMIN."</a></td>";
showlist.php:					echo "<br /><a href='".htmlspecialchars($plug->getAdminURL())."'  tabindex='".$template['tabindex']."'>",_LIST_PLUGS_ADMIN,"</a>";
showlist.php:				ADMIN::input_yesno($varname, $current['value'], 0, 'yes', 'no');
  • Create a new admin panel using a MVC framework i.e. Symfony, Zend, CakePHP (other suggestions?) Note, we might need to ensure this framework is lightweight to prevent creating a blob.
    • It accesses existing database schema
    • It provides all existing workflow actions (add/mod/del post, etc.)
    • implements a pluggable GUI that allow plugin to add/mod/del component fro the admin menu i.e. A Tagging or multi-category plugin can hide/replace the build-in category functions from add/mod post and other category management functions
    • implements all existing events
  • karma vote out of core into plugin
  • full UTF-8 support
  • GetText support

Background reading/Parking lots

 
planning/3.50.txt · Last modified: 2009/06/23 17:28 by ftruscot