1
Mamba
Roadmap 2.6.0 Discussion
  • 2012/7/10 6:24

  • Mamba

  • Moderator

  • Posts: 11366

  • Since: 2004/4/23


Recently the Core Team has published the Roadmap for XOOPS 2.6.0

Please discuss any issues related to this Roadmap here.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

2
redheadedrod
Re: Roadmap 2.6.0 Discussion

Mamba:
Is there a tracking system that shows who is working on what and what items are planned to be included? I know such systems exist because we used one in one of my programming classes. They also track where the person is on the "tasks". (Haven't started yet, % done on coding, level of code status (alpha, beta etc))

Wishcraft:
In reference to the Database stuff. No one "gave" me any sort of task. After the short debate over the ADODB - PDO debate nothing else seemed to be done. The way it seemed to me was that the database stuff was put on hold. I asked here and in the core mail lists if there was a need for someone to work on PDO stuff and didn't get any responses. I got no responses to related threads I posted as well. With the Database Optimization Challenge that was posted I thought it would be a good project to work on especially since the current MySQL PHP extension has been depreciated and will be likely removed from a future version of PHP which would cripple Xoops. I posted a converted class based on a Procedural version of the newer MySQLi extension which was created with a script after which I edited to make sure it still reflected what it should. This runs fine on my home system.

If you in fact have written a PDO class then I really don't need to waste time working on one. However after looking through your ADODB class stuff I have to wonder if you do a PDO class set if it is going to be as complex as what is in the SVN. Your ADODB design is complex and hard to trace which is bad for core code if it is to be included. As to performance numbers etc, really these are just database connection classes and should show no difference in performance and just be a difference in implementation and possibly code quality. The difference in performance will come when the core is refactored to take into account the improved security and performance gains available from the new features.

With relation to PDO I came across 2 things...

1. PDO makes use of interrupts for error trapping and these should be used any time you use a PDO function. If you fail to do so then the default error display will display the error connection including all of the connect string which includes the database name, user, and password information. It is important to make sure you have the interrupt error trapping turned on and always use try..catch blocks around ANY PDO related accesses.

2. PDO is an abstract class and as such has a code base that if you limit yourself to the most commonly supported features then the core and any modules written with it properly will work with any of the databases PDO supports. It does however also have support to allow different databases to make use of their strengths by having additional parameters and such that can be called. So different databases can have some specialized items that can be utilized. Since those specialized items however are limited to specific databases I don't believe they should be used (at least not in the core). We should try to generalize the code as much as we can to make it compatible across the board. And in relation to what the core has available now this should not be a big issue at this step. The main idea here is that the PDO extension was created with the intention of allowing any database to be used without having to make major changes to the code. In essence you should ONLY need to change the connect string to change databases and everything else should just work.

This does bring about an interesting concept as well. I discussed this briefly with Mamba when I visited him but I think we need to modify the whole Database class structure. This class was originally designed approximately 10 years ago before things like PDO or ADODB existed and the idea was to some day support multiple databases. Assuming PDO becomes the defacto standard extension the database class structure should be modified to streamline the use of this extension and thus allow the core programmers to make use of the new features it brings.

The most simple change would be to convert it to one class file. This is assuming the only change we need to make is mainly to the connect string. By using a switch statement for the database connect string we don't need the extra files under the current system. The rest of the class could then be simple PDO based code and not need additional files.

if however we need to support different code beyond just the connect string for different databases then we could keep the same structure but modify the database.php file to include all of the base PDO code. Then we just use small database specialized files that only includes the code that is different from the base code thus simplifying the supporting files.

3
DCrussader
Re: Roadmap 2.6.0 Discussion

Quote:

Is there a tracking system that shows who is working on what and what items are planned to be included? I know such systems exist because we used one in one of my programming classes. They also track where the person is on the "tasks". (Haven't started yet, % done on coding, level of code status (alpha, beta etc))


I got simple code for that but someone have to port it to XOOPS, it's bellow 5k.

4
redheadedrod
Re: Roadmap 2.6.0 Discussion

Quote:

DCrussader wrote:
Quote:

Is there a tracking system that shows who is working on what and what items are planned to be included? I know such systems exist because we used one in one of my programming classes. They also track where the person is on the "tasks". (Haven't started yet, % done on coding, level of code status (alpha, beta etc))


I got simple code for that but someone have to port it to XOOPS, it's bellow 5k.


I will PM you my email address... If this is simple I may try to port this over. Would like to at least take a look at it.

5
timgno
Re: Roadmap 2.6.0 Discussion
  • 2012/7/11 19:20

  • timgno

  • Module Developer

  • Posts: 1504

  • Since: 2007/6/21


My modest support is available here

6
irmtfan
Re: Roadmap 2.6.0 Discussion
  • 2012/7/12 6:00

  • irmtfan

  • Module Developer

  • Posts: 3419

  • Since: 2003/12/7


timgno:
could you please continue developing your "JQuery UI datepicker" to support localization?
please continue here:
https://xoops.org/modules/newbb/viewtopic.php?post_id=347721

7
DCrussader
Re: Roadmap 2.6.0 Discussion

Link sent on PM

8
timgno
Re: Roadmap 2.6.0 Discussion
  • 2012/7/15 16:40

  • timgno

  • Module Developer

  • Posts: 1504

  • Since: 2007/6/21


Quote:

DCrussader wrote:
Link sent on PM


which link?

9
DCrussader
Re: Roadmap 2.6.0 Discussion


10
zyspec
Re: Roadmap 2.6.0 Discussion
  • 2012/7/16 18:28

  • zyspec

  • Module Developer

  • Posts: 1095

  • Since: 2004/9/21


I'd like to see some of the following considered in addition to the things listed in the news article.

CSS

  • CSS - Rework templates to CSS2.1

  • CSS::CSS3 (depending on official CSS3 status)

  • CSS::CSS3 - use @media-type attribute to set css based on screen resolution

  • CSS::CSS3 - provide standardized methods to autodetect mobile devices and a simple template/theme 'switcher'

  • CSS::CSS3::Mobile - eval using WURFL

  • CSS::CSS3::Mobile - eval using PHPSniff -https://sourceforge.net/projects/phpsniff/

  • evaluate using CSSTidy for CSS optimization


Smarty

  • Update Smarty to 3.x

  • Smarty::3.x - enable {php} but put in deprecation notice ($smarty->allow_php_tag=true;)

  • Smarty::3.x - disable whitespace parsing ($smarty->auto_literal = false;)

  • Smarty::3.x - search and remove trigger_error() references

  • Smarty - evaluate using foreachq and includeq in 'core' Smarty templates to improve performance

  • Smarty - change 'multiple Smarty assigns to single 'array' assigns. It's faster since $xoopsTpl->assign only get's called once.
    (userinfo.php would benefit from this).


HTML
====

  • HTML - add capability of adding 'extra' attributes to the <body> tag for page loads.

  • HTML::BODY - add things like 'id=myindex' would allow setting CSS based on page/module

  • HTML::BODY - allow creation of<body onload...>


JQuery - update core to use jquery methods
======

  • calendar

  • validation

  • color-picker


Misc
====

  • Investigate updating CakePHP cache engine

  • evaluate creation of XoopsCacheWin (similar to XoopsCacheApc) for Windows installations

  • replace backend.php with something similar tohttps://xoops.org/modules/news/article.php?storyid=6080

  • remove hidden errors '@' usage.&nbsp; This masks various problems and '@' is 'expensive' execution time (roughly 1.5X-2X slower)

  • ability for admin to easily upload and overload admin logo and favicon

  • change xoTheme to load javascript afte<body> to improve progressive display

  • evaluate using SplObjectStorage instead of using arrays for object storage

  • evaluate a variant of Catzwolf redirect for users (https://xoops.org/modules/newbb/viewtopic.php?topic_id=71863&forum=74&post_id=341059#forumpost341059")

  • /class/xoopskernel.php gzip Compression routine takes away server ability to determine best compression
    (zlib.output_compression_level') < 0) instead of when it's disabled zlib.output_compression_level') == 0)?

  • /class/xoopskernel.php path() should validate that the path actually exists (call to pathExists())

  • improve Xoops ErrorHandler (./class/module.errorhandler.php)

  • ./include/common.php attempts to load xoops_loadlanguage('pagetype')- which doesn't exist, why?

  • extend CAPTCHA class to provide question/answer (math, colors, shapes, etc)

  • create a 'banned' group by default. Provide method in user management to move users to the banned group (just like the
    'delete' functionality)

  • 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

  • ability to use email addr to sign in instead of uname

  • utilize bugtracker API in admin interface (requires switch from current bug tracker to one that has an API) to easily upload bug
    reports


MyTextSanitizer

  • Allow overload of an extension if in Frameworks

  • Provide config 'switch' method by adding a /Frameworks/textsanitizer/config, not by 'hacking' core
    /class/textsanitizer/config.php (config.custom.php)


XoopsErrorHandler

  • Translatable messages

  • add SetErrorMsg method (allows setting, or overriding, messages)


Frameworks

  • provide architecture and web integration for plugin
    architecture (can download plugins from xoops.org from Admin panel)

  • evaluate usage of .phar files for distribution

  • QR code generator class (is part of tcpdf, just needs to
    be made ‘visible’)

  • location lookup class (IPDB, etc)

  • pdf generator class

  • Graphing class - include Image Rezising methods

  • Ratings class (w/ plugin architecture for text, jquery star, etc)

  • Social Network Icons class

  • Create a XoopsTags module (derivative of Tags module?) to manage tags to provide site wide tag support, allows for both structured and unstructured (freeform) tags. Structured tags only allow modules/users to enter predefined Tags set by admin

  • [ul]
  • evaluate using wishcraft X-Payment classes for 'optional' payment gateway

  • update and re-release XoopsGeshi class (still instantiated by the the textsanitizer syntaxhighlight extension)

  • /art/object.php & /art/functions.php both assume a MySQL database, should be rewritten to use db class to abstract call

  • module.textsanitizer.php textfilter is looking for XoopsPurifier in /Frameworks, what happened to it? Why isn't it available in Frameworks anymore? Should at least be avail. as a separate download somewhere official


Authentication extensibility, use a interface class to define XoopsAuth

  • create OpenID provider

  • Janrain Engage integration

  • oAuth integration between trusted Xoops sites (client, server, resource owner)


PHP 5.x

  • use PHP interface classes to define extensible core functions (XoopsCacheEngine, etc)

  • investigate use of PHP5 spl_autoload_register (cannot use __autoload for Smarty compat)

  • investigate use of PHP5 __destruct for garbage cleanup (e.g. online/offline)

  • utilize PHP5 exception handler (try/catch) in core

  • remove usage of functions being deprecated in PHP 5.4
    (break/continue $n)

  • evaluate using PHP namespace for module cloning (requires
    PHP >= 5.3)

  • change actual constants (class constants) to const
    declares instead of using defines, a little faster, a little more secure
    since constants can't be redeclared, and most importantly&nbsp; it makes
    the code easier to read because things like if( 1 == $mycond) isn't as
    clear as&nbsp; if( MYCLASS::ADMIN == $mycond)

  • consider using (int) instead of intval where appropriate, it's faster

  • check camel case for all functions/calls.&nbsp; Currently PHP does not check function case but this may change in future releases
    as it did for class names in PHP5. For example there are multiple places where 'xoops_getmodulehandler' is called by core as
    'xoops_getModuleHandler'&nbsp; (see ./modules/system/admin.php as an example.

  • eval using php_strip_whitespace on files before putting them into the cache to speed load/display, reduce file sizes on disk


Document and extend xoopsPreload

  • tutorials (adding new preloads, using existing preloads for garbage collection, etc)

  • evaluate method used by ICMS &/or Xoops Cube to see if it's applicable


Eval onokazu's suggestions in SVN tracker (Feature Requests)

  • https://sourceforge.net/tracker/?func=detail&aid=3018305&group_id=41586&atid=430843

  • https://sourceforge.net/tracker/?func=detail&aid=3011395&group_id=41586&atid=430843

  • https://sourceforge.net/tracker/?func=detail&aid=3011394&group_id=41586&atid=430843


Login

Who's Online

181 user(s) are online (56 user(s) are browsing Support Forums)


Members: 0


Guests: 181


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Mar 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits