Can we have the option "Know the country of connected users" as discussed in the thread?

Deepak

Wordpress, Drupal, there are plugins for jQuery to insert such a Player, as an explanation in the comments are also created under the copyright of the files, it would be nice, some plugins xoops have it but not very practical, others are not , and for a beginner programmer in php, it is not easy. I wish that plugins are created and then loaded as desired by the administration.

I have had this document kicking around for awhile I planned a direction for core changes this includes fixing the security issue with the sessions being ridable from a proxied connection.

Download: XOOPS 2.6 Planning & Direction.pdf (fixed)

One thing that is ready is the 3rd Party addition of ADODb, I have written a wrapper for with a MySQL Pivot PDO in 3rd party on the SVN for Database support other than MySQL, it is in the 3rd party section of the ADODB 0.23 - SVN.

This from my bench test improves XOOPS Database handling and fixes the bottleneck in the existing database classes which are from 1996, it needs to be fitted there is some issue at the moment with the session handler class with it installed, so someone that understand the session should include it and fix the GC Session Handler. There is no call or use of Sessions in ADODB that what I found funny about this bug, but the ADODB Patch is finished over 4 months ago.

To Give you and idea it means xoops will run on the following database platforms: (code)

• access
• ado5
• ado_access
• ado_mssql
• borland ibase
• csv
• db2
• db2oci
• fbsql
• firebird
• ibase
• informix72
• informix
• ldap
• mssql
• mssql n
• mssql native
• mssql po
• mysql
• mysqli
• mysql po
• mysqlt
• netezza
• oci 8.05
• oci 8
• oci 8 po
• odbc
• odbc db2
• odbc mssql
• odbc oracle
• odbtp
• odbtp unicode
• oracle
• pdo
• pdo mssql
• pdo mysql
• pdo oci
• pdo postgress
• pdo sqllite
• postgres 7
• postgres 8
• postgres
• proxy
• sapdb
• sqlanywhere
• sqlite
• sqlite po
• sybase
• sybase ase
• vfp

It also means there will be possible to use Store Proceedures with XOOPS as well as a long query cache for those long queries that happen on large database, which means another cache the better performance there is.

Check it out.

I would like a few more preloader parts, we have one at the end of footer but I also want it at the end of loading a cache before hitting exit, for ultimate quiet background crons.

I also think my multisite 1.40 principle should be adapted to the system so there is full domain bootstrappable principle of multisite.

I'll weigh in on this topic eventually.
I think it's a bit premature, but eventually a needed discussion.

Focus should be fixed on the problems we have at the present time, so as not to get ahead of ourselves as the x3 project ended up.

Honestly I'd rather see 100% of the effort expended on bringing modules out of beta/rc/etc.

I'll get back with you on this Rod.

The 2.5 branch should hopefully be made bug free soon. This thread was originated so we could throw out ideas what we think will be important to a 2.6 branch.

I am not an official Xoops anything at this point other than just a user. I wanted to start a thread on this stuff to get us thinking towards a 2.6 Branch. This thread was made before the full blow up about XE happened.

I think that the 2.6 Branch should include some major upgrades that we have been needing to make xoops work more efficiently and to work towards a much nicer environment. Alot of technology has been upgraded even since the 2.4 branch. The 2.5 branch was more of a backend improvement.

Personally I believe that while keeping with the 2.X branch of Xoops we should determine the important aspects of 2.X to keep intact and upgrade the rest that we can.

We should not touch support for modules.. Any modules made to work for the 2.0 serious should work throughout the series once updated for depreciated functions etc and brought up to PHP5 code.

First Priority, as has already been said, make 2.5 stable and bug free.

After that is done we need to decide what to include in the 2.6 branch.

This is more of a brainstorming thing hoping that the core developers see this and the council decides to add some of this stuff.

Continuing the 2.x branch should be something that doesn't require a total recoding of xoops at this point. Maybe refactoring old code to bring it up to current standards where applicable but I think for a major rewrite you really need to look towards a 3.0 branch.

Quote:
Yes, this will be one of the focus areas for us after XOOPS 2.5.2 is released.

The work already started with the Basic Module Pack, with all modules using consistent GUI via ModuleClasses and all being tested on XOOPS 2.5.x.

The goal is to get the main, most popular modules updated for 2.5.x, provide documentation for all of them, and put them in Module Packs, so a new user can have the best experience with them, without the frustration of searching for modules, looking desperately for documentation, and once installed, finding bugs or realizing that the module doesn't work on 2.5.x.

What we need to do is to make the experience for first-time XOOPS user as pleasant as possible.

I think, we are getting closer to finalizing the Basic Module Pack, but we still need documentation on several of the modules, so your help would be very much appreciated.

This: "What we need to do is to make the experience for first-time XOOPS user as pleasant as possible."
Is a good thing..

I'm not really sure how big a help I could be, but as stated in other sub-forums here, I'm pretty much all in on XOOPS for the time being, so I'm willing to help as much as I can..

My coding skills are pretty out dated, and I basically cobble (read cut n paste) most of my stuff, but I'll look into the dox requirements and see if there's anything I can help with.

*edit*
Of the listed modules needing docs, I only use 2 of them (TDMDownloads & Newbb).

The trouble is that there are distinctly different versions of both of those modules in use at present.

I'll give this a bit more thought...

Ok, to partly answer Rod, 1 thing I'd like to see in any future version is a built in Multi-Lingual ability.

It isn't just needed, it should be a requirement for any CMS.

I also hinted at linking certain forum topics/categories between websites (in another sub-forum here), and as it will most likely take some provisioning at a core level, that would be a suggestion I would make for future consideration.
(It's obviously module specific for the most part of course, but the core should allow for the content sharing aspect of the idea to be usable by any forum module)