I would like to give my two cents with PDO adaptation.

Does someone have a look on xpdo library ?
I used this to adapt an old framework with PDO or PDOlike (compatibiliy for php < 5.2) and this simple library give me the right answer.

The proposal is undeniable and positive for xoops, but I would add that in addition to thinking about the functionality of the core, there are other elements to be reckoned with for the future of the xoops 2.6

We are moving towards a target moving so even if we use bootstrap, don't forget that we can exploit all the resources including JQuery Mobile.

Also suggest adding in addition to the extensions folder, including a folder applications for mobile sites.

PDO 4 You is the one I will be looking through but I am certainly open to others. I am not a core programmer but trying to help out. PDO 4 You incorporates a few ways of doing things that make good sense compared to the bare routines supported by PDO but like I said, I can look at different ones to see which makes more sense.

Rodney

@Trabis:
I can see you add the search module. while changing a hardcoded file to a module is good and a moving forward (with the possibility for module developer to add plugins) the main issue still need to be addressed by core team.

XoopsCore use the module search function in XOOPS 2.5.5 and now the module search plugin in XOOPS 2.6.0 so why not redirect to the module itself when the user click on "Show all results" link if MODULE/search.php file does exist?

see this request:
http://sourceforge.net/p/xoops/feature-requests/404/

also this post for detail:
https://xoops.org/modules/newbb/viewtopic.php?post_id=349697#forumpost349697

@Irmtfan

Hi, I will go through feature requests at a latter stage.
I've also finished the notifications module and I am about to commit the comments module.

Please be patient
I know it is a simples fix, perhaps you or other dev could commit it? Would be nice to have more hands on the core.

@Trabis:
I know you already done great job.
reviewing features related to your current modules prior to commit them will help you to find other ideas and implement them in the first step. otherwise you should back and change codes and you will waste some time.

Quote:

I didnt commit to the official branch because IMO it is an anarchy to let everybody commit codes.(then why we have feature request section )
In this specific request, I didnt know whether you and other core team are agreed with redirecting to the module itself or not.

Ideas are far more important than codes and those ideas should be discussed before implementing as codes in the core.
I was really glad to see your proposal open to everybody. IMO all developers should discussed their ideas before writing codes.

I cannot find any special request in sf.net for notifications and comment module so IMO your modules will satisfy all people.

Quote:
IMHO I think we should have a core SVN and an "everybody else" svn.
No one other than core developers should be able to commit code to the core SVN. By letting module developers have write access to the full SVN I think it is dangerous.

Any additions to core should be submitted to the developers for review and let the core developers add it to assure quality control is assured and controlled by the core developers.

Quote:
While it is important to discuss ideas the code will never get established if we keep adding new things to it or changing things around. At the Alpha stage we want to make sure the current items work as intended and go from there. IMHO we are trying out some new things and they need to be tweaked a little bit before they are ready for "the wild" which is why it is still alpha and not beta. Some of the more minor issues should be discussed later or added to the "feature requests" for consideration.

A word about extensions:

Playing around with the 10954 release of 2.6 I can see better how we need to do some basic restructuring.

The modules work well as are and should remain as they are.

We should have plugin support for the control panel. These would be anything that can be added to the control panel to help the admin. These would be things that don't normally have a user side to them although modules or the user side may take advantage of them. There would be no difference in the control panel between these and what are listed as "system tools" and they should be included with the system tools.
This would likely include the currently listed "extensions":
avatars
logger
mail users
maintenance
menus
user ranks
smilies
xcaptcha
xlanguage

We would then also have the "extensions" and these would be something that extends the core in some way. These would be added functionality to the system that some modules may depend on and they likely have a user side and not much use to only the admin. They may or may not have an admin side. The current "extensions" that would be good examples of this would be:
comments
pdf
qrcode

We can look at some current modules that should be included in this as well.
Protector - Admin Plugin
PM - Extension (Needs to be rewritten to fit in here. Should be a generic mail hub.)
Profile - Admin Plugin (Needs to be rewritten to fit in here. Maybe separated into a user maintenance admin plug in and a profile module that ONLY handles profiles without the authorization system.)

There are many other modules out there that could be redone and added as admin plug ins or extensions.

So as a summary IMHO we should have a plugin system for the admin menu. These should reside in their own location. The user experience should be the same as if they were included in the core. They would be in the System Tools menu.

We should have modules. These should be as they are now with maybe some minor tweaking. If they don't have an admin menu they should not be listed but otherwise they should be on the control panel board. (Not currently there in 2.6?)

Extensions are like super modules so they should be in their own location both on the drive and on the control panel. If they don't have an admin menu they should not be on the control panel menu.

Of course any modules or extensions without admin menus should still be in the "Installation" menu.

Quote:
Yes Xoops development should move on. I just think alpha versions are for major ideas/changes and beta versions are for minor changes. So discussing is good to let everybody knows where we are going.


I have another important suggestion too.
please add a designer to core team. His/Her main duty would be modifying/changing icons, images, ... and more importantly revamping current table templates to div templates and change colors, use jQuery methods,...
Now i can see a main developer like trabis have to change even some icons.
Also some people questioned foreground and background colors.

I think tatane is the right person if he have time for it.

Quote:

I can certainly agree with this..

We should have someone that is good in html/css design go through the code and help with the designing of templates and such.