I know a lot of mod devs are writing these functions themselves and it makes sense to consolidate them so that the code is common. I'm sure there are a bunch of other functions we all use. I'm happy to give code for some of these and you could leave the moved ones in place for a version so that there is time for folks to update their code (and the core).
Having them all in one place helps to make new dev's know about and use them which mean quicker and more standardised development as well.
send_pm() would be extremely useful, I've been asked for that before and have yet to make my own, but like BC says, most of the rest we mod devs make for ourselves anyway, I certainly have all the ones BC suggests except send_pm() and get_rank() and re-use them in all my modules. That means duplicated code for anyone who uses more than one custom module (which I suspect is a lot of people).
edit: My comment class was made to suit my own purpose, I just gave it away for the hell of it. It doesn't have DF's moderation options or word censorship, or allow users to choose nested or flat views etc., so it's not as sophisticated as DF's, however it is a plug-in which can be used for any module.
the get_rank($rank, $posts) and get_avatar ($user_id). Those results can be achieved using the getusrdata function available in the cms.ini file
Actually no, these will both return the full path and name of the image in question. Many of the functions listed might be suitable for this new class though.
I know that Kendle made something for comments and that could be the basis of the core comment functions.
The general idea is to get a core class for common functions. Once it's in place then they can be added to or modified to suit. But they must be supported and in the core to be of any overall value because only that way will they become the standard and stop the inclusion of hefty function.php files in each module.
Its our intention to provide a core only package. No modules, just core.
At install, or at any time, the user can install any module or add-on they want.
For example Private Messages will be an add-on for Your Account, Forums or other modules.
Every module will have its own classes and related functions if Forums "require" to send private messages then when installing Forums will check, and if missing, install Private Messages as well. Off course it will require an user confirmation and if the user will answer no, then Forums will not be installed because of the missing required dependencies.
Again if Forums made Private Messages an optional "add-on" will still warn and ask for user confirmation but this time it will proceed the install auto-configurating it self for the missing dependencies.
Not everything will be part of the core, we do have good ideas but everything will come slowly slowly, so all modules will have the possibility to adapt them self the new DragonflyCMS versions whit out big rewrites.
.:: I met php the 03 December 2003 :: Unforgettable day! ::.
Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS