Just out of curiosity!


Will XOOPS 2.5.4 RC and XOOPS 2.6.0 Beta release together since both of them are updated frequently in SVN?


Thank you very much for all the efforts of XOOPS developers. XOOPS is a wonderful masterpiece indeed.


Thanks a lot!




Regards,

cadelite

Hi cadelite,

XOOPS 2.5.4 RC should be released within the next couple of days since we are not getting any bug reports. We want to make sure we have a stable 2.5.4.

XOOPS 2.6.0 will be released as alpha and should not be expected before the end of this year. Although we are being very active in 2.6.0, the time seems not to be enough.
I was giving the following task:
- Make XOOPS run in STRICT mode (no notices displayed in debug)
- Make XOOPS handlers extend XoopsPersistableObjectHandler
- Remove php 4 support and deprecated methods.
I had set a timeline of 2 weeks for completing this task, I had already taken 3 weeks and I'm about to enter the 4 week without knowing if my task will be completed within it.

So, when I say end of this year, I may be talking about my task alone


Oh, but it will worth the wait, XOOPS is already faster and consuming less memory. And while we 'wait', there is many work to do at the modules level.

I haven't seen a road map for 2.6 at this point. Is there one somewhere?

Does sound like the work you are doing is very productive and very necessary.

I just hope that the idea of 2.6 is to lay the framework for further advances down the road.

@redheadedrod,

there is no roadmap for features planned yet.
Quote:

First step is to have clean code, one that is more OO (using less/none globals) and that has good phpdocs and inline tags. When I use phpstorm on 2.5.4 is very rare to find a file that is totally green. Many classes are not identified by the editor, return values are incorrect, it is a complete mess. In 2.6.0 I aim to have at least 90% green files (some cannot be achieved because editor cannot parse dynamic file includes). This means that developer will be able to use autocomplete and hover any $variable and see its properties. It also helps on code checking, if you mistype a method, the editor will trow you a yellow line (if the file is green, you cannot miss it!)

Thank you, trabis!

I believe that XOOPS 2.6.0 is worthwhile to wait (especially it marks a brighter era for XOOPS).

Having been using XOOPS for over 3 years, I think XOOPS is very good at building community and commercial websites, except that the size of files included in XOOPS is really too large compared to Drupal and Wordpress. Maybe owing to maintaining the backward compatibility and the obsolete codes included in the old trunks.

I hope the future versions of XOOPS (2.6.0 or later) will use more advanced features of PHP 5.3 or later and, if possible, will add more support for PostgreSQL and MS SQL Server.

Not sure if the recent popular NoSQL databases are suitable for the future XOOPS development but I believe that there will be a chance for XOOPS to be used in one of the most popular social websites in the world. Let's see!

Thank you very much! You XOOPS developers are the most respectable and you worth the praises from us, as XOOPS users. Thank you!! :)



Regards,

cadelite

This definitely sounds like a great move forward. The code as is now can be very difficult to review and learn.

Quote:

Maybe a 200% code refactoring on XOOPS project is a must to the further development of XOOPS.

Drupal lifts the burden of backward compatibility. Every version has great features added and forgets the backward compatibility to the previous versions.

See if XOOPS will follow it. Of course, it may cause many users who are still using XOOPS 2.3 or earlier version, like those in Taiwan and Japan, to make a really hard decision on whether or not upgrading their websites to the latest version of XOOPS.

Well at this time Xoops is in a position that the core has pretty much been neglected for a long time.A couple gifted programmers at different times offered to come up with the next "great thing" and for one reason or another those projects did not end up getting finished. During those times work on X2 stalled and it has not changed much in a few years. The programmers in the past have been very protective of their work and did not want to share their ideas or let outside programmers into the fold. This alienated module programmers who wanted to make xoops better and they went elsewhere. So this leaves us with a lot of modules that are not up to speed with the current version of xoops and few developers to update them.

This does leave us an opportunity though to make some great advances with Xoops and hopefully do so in a manner that bringing the old code up to par will be much easier. Any future changes to the current version path should be made with the intent of heading towards a X3 branch but we are a ways from being ready to start looking there yet. Hopefully the problems of the past will show that we need to get X2 branch up to date and add some much needed features while also working on an X3 branch when that becomes a viable solution.

I think a big thing for xoops will be to make the code as reusable as possible and well documented so that module programmers can step right in and use it as is. I have made some proposals for some things I would like to see happen but I will likely end up doing them on my own to show how good they will work and then hope they get incorporated in a future version.

I do think what trabis is doing now is a very good thing. If I had the experience and knowledge of the core that he does I would be pushing to do exactly what he is doing now.

In the same mindset the only things I would also try to look at while refactoring is making sure the HTML code only uses the main Xoops CSS id's to make it easier to make a theme change the look of everything in the site. And looking at the database structure to make sure that something like ADO could be added to support other databases relatively easily.

Rodney

Oh yea, kind of got off track there.. As far as support for modules and such. I strongly believe that even through branch X3 that we should be allowing the modules to remain compatible. The main reasons why the older modules don't work is they were written for 2.0.x and were not done in a manner that would remain compatible to 2.5+. There are examples of many modules that were designed for 2.0.x and work fine today. However there is also an issue for the modules being written for php4 and pretty much all servers are on some version of php5 now.

I believe that we should be molding the X2 branch in a manner to be able to bring alot of those old modules up to speed by cutting out alot of unneeded code in the old modules and bring them up to php5 specifications. Assuming those old modules can be brought up to date for the current branches. Once that is done it will be easier to carry them into the future versions.

I personally would love to help with alot of the stuff going on but I am too swamped with work and school right now to be of much help. I will work on what I can when I have time until I can bring something public. I am looking forward to my current class on Javascript as it should bring me up to speed on alot of the stuff I want to add to code of my own.

Quote:

I agree here. I've been experimenting with XOOPS since before 2.0 and have yet to gain a meaningful understanding of the structure. Every time I think I get it, it changes...


*edit*
Also just found an odd thing.. trying to log out after my reply doesn't work. The link isn't active.

ArGh!