Nucleus Feature Spec/List for Future Release
Here's a list of features being discussed in the forum for the next release, with URL/description/spec. This is intended for developer discussion in next IRC session (in 2 weeks?) and for tracking purposes.
-
Advanced user rights
- A permission based user rights system instead of role based user rights (normal user, blog team member, blog admin, super admin) currently.
- When upgrading, all users should get assigned a set of permissions that corresponds with their current rights.
- Extensible system. It should be easy to add new permissions without altering database table structure or code.
- maybe add a per member based read permission (aka private post that only show to current user/group).
- An easy interface to check if a user has a certain permission (e.g. hasPermission(edit item))
- also see here for details
Atom API
- This Atom API support should go in the core, sort of like the xmlrpc directory, we'll now have an atom directory.
- The Atom API spec must be closely followed. If it says MUST, it means MUST. The implementation must not fail any conformance test in an Atom API Test Suite (does such a suite exist?).
- Implementor should be familiar with how HTTP requests work (methods, response codes).
- see here and here, spec is here
GetText language files support
- Currently, the language files use a series of constants. This has several drawbacks: partial language files are not possible, memory usage (all constants defined on each request), code is difficult to read (code contains the name of the constant, not the actual text)
-It would be nice to use the gettext functions. Gettext language files are in binary format, and only the strings that are really used are requested. In the sourcecode, text will appear as gettext('english string'). When a gettext translation is missing, the english text will be used.
- Preferably someone who has experience with gettext
- A robust system which also works on PHP installations that do not have the gettext extension (might need to research how other projects tackle the problem)
- Conversion tool to convert current language files into gettext binaries
- Automatic expansion of language file constants in current source code.
- see here and here
More blog convert tools
Move karma votes/IP ban as plugin
- The Karma Votes functionality was originally implemented to mimic the same feature as in GreyMatter. The functionality is little used, and could be implemented perfectly as a Nucleus plugin. To de-bloat the Nucleus core a little bit, this should be turned into a plugin.
- IP banning was introduced as a feature long ago. I don't believe it is really effective, since IP addresses of visitors are rarely static. Also, this could be done as a plugin. Again, a possibility to de-bloat the Nucleus core.
- Upgrade tool should install these plugins automatically and import the existing data from the database.
Plugin API improvement
- Someone should be in charge of discovering new places where hooks could be useful.
Plugin upgrade mechanism
- Currently, users often need to uninstall and re-install a plugin to upgrade. It would be nice to automate this (in the expense on more work by the plugin writer) with a update plugin button on the admin menu, which detect a new plugin version in the plugin directory.
- The nucleus_plugin might have to track version in the table now.
- both upgrade and downgrade need to be considered
- see details here
Auto plugin update
- A wacky idea from admun..... which provide a centralize plugin update mechaniam like yum/apt for Linux.
- This allow users to search and install a plugin from the admin menu directly, which download a list of available plugins from the centralize repository and allow user to install/upgrade from the web. This eliminate the need for official plugin pack.
- This mechanism will need a plugin signing mechanism to ensure the integrity of a plugin from trojan and alike.
- see here
Plugin dependancy check
- Currently, there are plugins depends on other plugin to function. There are cases that users missed the dependancy and failed very badly.
- Lists of know dependancy: NP_MostViewed->NP_Views, NP_PageLinkList->NP_BlogWithOffset, NP_RSSItem->NP_TrackBack, and many future one.
- This mechanism allow plugin writer to detect the error on install time and prevent further failure.
- The code is already done by admun, see here
getminPhpVersion()
- There are cases that some Nucleus setup is on PHP 4.1, but a plugin only works with 4.3 and up.
- This mechanism allow a check druing install to ensure a functioning environment for a plugin.
- see here
TypeKey/SharedID
- We need plugins that allow commentors to comment using an ID they have on those services. One could then allow e.g. only comments made by registered users or TypeKey users. This can be very helpful in times where comment spam is rising. Currently Nucleus blogs are relatively safe, but that will change.
- see here and here
captchs icon anti-spamming
- aka icon with word to challenge commenter to read and enter the passphase.
- This can be done as a plugin, using PrepareCommentForEdit, PreAddComment??
help file improvement (hcgtv??)
- help.html is getting rather big and thus takes quite a while to load sometimes.
- It would be nice if we could have a help.php file instead, together with an XML file containing all pages. help.php?page=key would then just return the requested page.
blog time zone selection
- Currently, a blog has a server time offset setting to allow timezone adjustment. It is complicated to calculate the time offset between the server and the blog.
- It might be better to provide a blog timezone setting instead, which admin can set the blog to a particular timezone.
Member posting control with admin approval
- A plugin similar to CommentControl, which save a post by user as draft, then admin can approve it later.
Subcategories and Multi-blog posts
- It looks like subcategories can be implemented as a plugin to group categories into group and under a main category using a table like nucleus_plug_subcat. (performance issue??)
- A admin menu is need to maintain the group of categories
- For multi-blog post, core change seem needed to assign a post to more than one blog.
NP_EditControl (karma)
List-of-Things (TeRanEX??)
- also see here
itemOption, skinOption and templateOption
- see here and here
WYSIWYG CSS editor
- Tinkering default.css is always a very complicated work for newbie and pro alike.
- It might be good if we can add a WYSIWYG CSS editor so user with little CSS understanding can make changs to there skin.
Comment system improvement
- some idea suggested by radek, worth think about, might piggy-tail the work with advanced users right work listed above.
Comment Previewing
- NP_CommentPreview requires core changes, which IMHO not the best approach.
- Maybe we can use a commentlet, which is like a bookmarklet which has a commenter info tab, edit tab, preview tab, and submit button.
- This will replace the comment form on each item with a "Write new comment" link.
User comment viewing enhancement
- Ideally, all comments on one screen for a particular blog. The same security applies, you should only be allowed to view comments for a blog which you are team member and only comments from posts that you have written.
Merging similar plugins
- suggested by hcgtv
- comment enhancement (more details need)
easy skinning
- Many users have problems applying skins, need to address why.
- There is a lack of skins overall, need more default skins based on grey. (aka sexier skins)
- Easy way of saving off your skin and call it something else, like I'd like to do an NUDN skin but the skinbackup.xml says Grey. I could go into my favorite editor and do a search/replace but I'm looking at users saving off their skins for sharing like I do at NUDN.
- I'd like to see the skins above the feeds in the admin screen. Very confusing to new users, what main index to change, etc.
built-in caching
- The disadvantge of radek's plugin is users have to do a lot of work to get static/dynamic plugin to work together.
- Why not build this function into the core, which provide a plugin a way to register whether it's output should be cache?
- ie, provides a allowCaching() in PLUGIN.php, which defualt to no. Then a plugin writer can override it if the contain is indeed static.
- This function can be control from the global setting (on/off)
Frankenstein (HTTP/external auth patch+plugin) and here
More external auth method/integration with ie phpbb, invision, vbulletin
- see here
post sorts by different category: reverse order (old to new), by author
Comments
kevin whited wrote:
06/07/04 23:30:30
Trent Adams wrote:
I would like to see the use of captchas images like Expression Engine uses in comments to further prevent the use of comment spam. Having to write in a 'random' word before commenting is a good idea. Check an example out at http://music.trentadams.com...
06/08/04 01:21:26
Admun wrote:
kevin, good idea, I'm thinking of this too.... a different approach: commentlet, which adapt from bookmarklet.
Personally, I agreed it sucks that commentpreview (and many of radek's plugins) need core changes... just wrong approach, IMHO. 
will added idea in the item.
06/08/04 09:34:53
Admun wrote:
trent, good idea...... let's see if we can do it as a plugin??
06/08/04 09:52:07
karma wrote:
I wrote some info on the itemOptions/skinOptions (18/19) proposal on http://forum.nucleuscms.org...
06/08/04 13:54:05
Admun wrote:
karma, thanks for the details. I've updated the list
06/08/04 14:03:11
hcgtv wrote:
Maybe you should move the feature list into the more section. You could also use the same concept in the other posts. That way at a glance we can see all your posted items without one post being the dominate one.
This list is looking good.
06/08/04 14:05:08
Admun wrote:
hcgtv, good idea.... just not a extended person myself... well maybe I should used autoextended. hahaha
06/08/04 14:11:58
Add Comments
This item is closed, it's not possible to add new comments to it or to vote on it
Core needs a comment preview system.
XE has it, but Radek's "fix" requires hacking of core code. Core ought to have it in next version. Long overdue.