zyspec: That is a pretty good list of items that need to be updated.
I know some of the items you mentioned are already done in the 2.6 base. I had been told in the past that Smarty 3.x would require major reworking of templates and the work required to accomplish this in relations to what is gained was not worth the effort at this time.
If you read the roadmap, Alpha 3 is slated to have a different Database base which will likely be a PDO extension since the currently used MySQL extension is due to be removed soon. (Heard rumor that it was depreciated in 5.4 and due to be removed in 5.5) Any core or module code that are accessing MySQL directly instead of using the Database classes will not work at all when that happens. Hopefully since the plan is to move to another extension with 2.6 this will not be a big issue. Any module using the Xoops API to access the database should work fine in relation to the databases. The new Database extension whichever one is used will support many new features which should help with database access performance as well.
I am assuming by this list of items that you are a programmer... I know the core group could use more programmers that can provide stable working code...
For development modules some tools needed. at this moment we don't have any good tools for module and I have to write all needed codes in module class, I hope module class added in core and some needed functions add to this class.
Can you be more specific? Could you provide some examples of code that you had to write?
Is TDMCreate something that could help? Or XMF from Trabis?
There more detailed requests we have, supported by examples, the easier will be for the Core Team to understand what is needed.
Thank you zyspec. There are some ideas that will be useful for coders/designers which i as a end user cannot understand some of them. I just should inform you as far as i know some of your ideas is already requested. like: JQuery UI calendar or email login. look here: xoops feature tracker in sourceforge
Audit trail (ability to see who/when major changes were made - installed module, changed, theme, etc). Put data into an MySQL ARCHIVE table it doesn't allow deletes - so is more secure/accurate
Yes, something similar to this although instead of having to place this code manually throughout all core files, modules, etc. it would be better to either use a core function that modules could just call each time a change is made. It makes it easier to implement and more uniform in execution. The real difference is to also put the log into a database ARCHIVE table instead of storing it in a file. This makes the log more secure for 3rd party audits, not just by the administrator. There are sites where the log must be accurate and not easily modified by anyone, including the administrator.
I had been told in the past that Smarty 3.x would require major reworking of templates and the work required to accomplish this in relations to what is gained was not worth the effort at this time.
I guess that's a matter of opinion. Smarty 2 development stopped a couple of years ago - the last release was June 2009. By the time XOOPS 2.6 is released (mid next year) they may not even be providing updates anymore. Smarty 3 will require some template updating but the improvements in code quality, speed of execution, additional features seem to me to be 'worth it'. You can see some of the benefits here. Most modules will require some tweaking anyway (due to PDO changes) so the additional 'burden' of tweaking the templates isn't that significant.
it would be better to either use a core function that modules could just call each time a change is made. It makes it easier to implement and more uniform in execution.
If you read the last sentence in that tracker you can find I meant even more than a core function. IMO we need a new module or at least a new plugin in system module for doing that. It should be totally functional. Quote:
The real difference is to also put the log into a database ARCHIVE table instead of storing it in a file.
IMO there should be an option in the preferences that webmaster can choose the place logs stored: File/Database(recommended)
The location of that file should be optional too: outside root(recommended)/ inside root Also logs can be store with secure hash algorithms like SHA-256 and SHA-512.
In one sentence I repeat: That log/history module should be totally functional.
1- boredcamp 2- list item ( news , file , image , ...) : some functions for make list pages in user and admin side is good 3- item page ( story page , file page , image page ) some functions in this class needed
if you check some of xoops modules ( tdmdownload , extgallery , article , news and ... ) you can see same methodes and options in all modules , this needed codes must add in core class