1 - When there is no center block, the block is shifted right
2 - I do not see this option

I like the look of everything so far but a follow up comment about extensions..

The admin menu's for extensions and modules should be a little more similar than they are. It almost looks like two different people worked on each with little shared input between them. Although most of us experienced people will not find an issue with this, newbies will be more likely to be confused by the different ways they work. Expecting them both to work the exact same way.

Not sure what I mean? Use each menu and you will see what I mean. Each has its good and bad points. Would be nice if we could settle on one style and use it for both. Personally I like the module admin menu better than the extension one.


Since extensions appear to be more or less "super modules" It makes sense how it could make things more difficult to separate them, but in the long run I think it is a very important thing. We should not make it out of Alpha into Beta with the Extensions and Modules residing in the same directory. It can be very confusing to know which is which when you start having a bunch of them.


In the news article it states:
" Some modules in the Admin will also become Extensions (eg. Protector). All these Extensions are runing as modules, but they cannot be renamed, and they will be shown in a separate menu module"

I am curious what it means to not be able to be renamed? Are the extensions hard coded into the core so we can not add additional extensions?

Once I am done with the database stuff and the install script I would be more than willing to look into a solution for this and help if it is still an issue. But if I do it then it will likely be something for 2.6.1 because of my limited time and need to get the other projects completed.

Rodney

If the Extensions/Modules issues I have brought up during this thread still exist by the time I am done with the install script I am willing to look into them further as it falls in line with projects I have mentioned elsewhere.

May also be a good idea to have a similar system for the frameworks that get added to make it easier to recognize when a framework is installed. Although I envision that such a system would be extremely simplified compared to a module. (Would help when tracking versions of Frameworks and module dependencies which as xoops becomes more popular may become an issue.)

In the same realm I would also like to mention the potential use of module libraries a I have mentioned elsewhere. These would be used similar to how .dll files are used with windows. As I get more involved with code building for xoops I will likely press this further and help make it an actuality. I envision the use of Libraries as a very good example of code reuse and in time should help make module building much simpler than we have today.

I notice the "banned" fork is actually adding much of the stuff I have talked about adding to the module install stuff. Things like Dependencies etc.

Again, As I get more involved with Xoops coding and can give more time I will help further these ideas. The only other idea I haven't really touched much for inclusion is an ACL system which I think can be coded into the system in a manner that it won't change how modules see the permissions system. It will just be much more simpler for admins to setup permissions when they have vast groups of members to deal with. I think adding an ACL will go a long ways to making xoops viable in a business environment over any of the current big name CMS's. I don't believe I have heard of any that include something like that.

Big news!
I have some opinions about all the parts of this alpha release but now I should response about the new extensions concept quickly.
actually, they are not extensions at all but as core team stated they are "system extensions" which is very very confusing and make all people wrongly think they are something like joomla extensions and they are different from other modules. But really there is no difference between them and other common xoops modules other than a cosmetic feature that i will explain below.
The core team decided from a long time ago to create new modules based on the current features in system module. the examples are profile and pm.
A more accurate and comprehensive definition for them is: "modules that make old hardcoded features in system module extensible and modular". We are all familiar with them because profile and pm modules are "system extensions" modules for years. there is no difference between these new modules in 2.6 alpha and profile, pm modules.
Turning these features in system module to stand alone modules will free system/core from many unrelated duties and more importantly open the way for module developers to work on them without touching core files.
they have xoops_version.php file and install/uninstall just like other modules. therefore the true location for them is inside modules directory.
The only thing that make everybody think they are different is the different menu in admin (just a different look) which is nothing more than a cosmetic feature.
I mean it just show them in a different menu while there is nothing different in the under layer coding.
and that is because of adding 2 options in xoops_version.php.


by adding those 2 options in any module you can turn it to an extension!
eg: I add to newbb and force it to be as a system extension!!!!!!(very funny)


I was blind because i never imagine that this little feature will bring these kind of misunderstanding in the whole xoops.org forum.
So those 2 options in xoops_version.php is seems very confusing and its little nice looking advantage is not necessary in compare with a lot of confusing that will bring up in 2.6.

Anyway we dont need any extensions like joomla extensions in xoops. one of the xoops few power points over other CMSs is its simplicity. you have core - module - theme and a new comer will work with them just fine. If we add extensions concept it will be more complicated for people especially newcomers.

Also im not the enemy of cosmetic features like that. The admin menu of 2.6 is very nice and will attract new comers but i as a webmaster need an understandable admin more than a nice looking one.
Also 100 features is missing in core and 1000 is missing in modules. whenever we could add those features we can put time and add cosmetic features.

I will talk about other parts of this release today.
just one thing: this 2.6 will move xoops 10 years forward because i can not remember any release with this huge development from 2.0.18 until now.

Edit:
Quote:
confirm.
in this url:
/install/page_configsite.php
same configuration. somebody should investigate this bug.

Quote:
Confirm.

Quote:
An interesting mistake.
The core team forgot to add those 2 options to banners module. so now you have banners module in the module menu while you have other modules in extension menu!!!!

edit2:
Quote:
Core team create these module and decide to make them just a very basic module. you as module developer can create your own modules. eg: red_banners, red_smilies, red_avatars, ...

We dont have any developments in xoops modules in the past 5 years so now IMO by releasing xoops 2.6 we dont have any module for this brand new core.
The below activities are not development:
- make old modules compatible with new core release and php and mysql
- add module admin class to old modules (cosmetic feature)
- create basic modules that have not features of the old modules. xoops dont need any more basic module. we just need full features.

So we need a real development in modules for 2.6.

Irmtfan, first, thanks for testing XOOPS 2.6.0 Alpha, and for providing feedback. We very much appreciate it.

Let me address some of they point you've raised about System Extensions. I am not sure why are you confused here.

a) Joomla is using the term "extension" loosly, defining as their "extensions" pretty much everything: Components, Modules, Plugins, Templates, and Languages.

b) we're defining our "system extensions" more narrowly in the terms of "software extensions" in general computing, similar to how they are defined and understood in Chrome or Firefox, i.e. as add-ons that provide additional functionality to XOOPS Core.

The basic thought behind them is very similar to how they originated in Firefox:
Quote:
As a result, we're removing functionality that was part of XOOPS Core, that might not be required by everybody (like Smilies or Avatar), and making XOOPS Core as "lean and mean" as possible.

While you might see it as nothing more than a "cosmetic change", this is just a first step of separating functionality. In the future, it might evolve into something with a total different architecture, but for now, let do one step at a time

Quote:
The simplicity still remains!

I hope, the above clarifies what we mean. We have:

- modules: client/user oriented applications
- extensions: providing additional functionality to XOOPS Core
- themes: skins for XOOPS

In the future, we'll need to create a clear "plugin architecture" as well, but again defined in terms of general computing, and not in terms of how some other CMS is using the term for themselves

Quote:
Ouch! That hurts! Really? No new modules in the last 5 years? Come on, Irmtfan! You should know better! Just check the past issues of WOX - we list there all new and updated modules.

And I have to disagree with you that "make old modules compatible with new core release and php and mysql" doesn't count as development. There is the old saying: "If ain't broken, don't fix it". If the module has a good set of features and is working as it supposed to, why do you want to abondan it, and create something new? Updating, refactoring to new API, upgrading - it is the right way to do, at least in my opinion. Develop something new if the cost of updating or maintaining is higher than creating something new, otherwise why would I do it?

I don't think that our users would react very positively if we would announce today: "We are stopping all work on updating existing modules to new PHP/MySQL versions or to new XOOPS GUI, as this is not the real development. From now on we'll only develop brand new modules"

Sure, there is more fun doing something new and creative, since maintaining/updating old code is boring and frustrating, but I really think that our users do appreciate us maintaining/updating older modules, and keeping them current.

Soapbox is now working on XOOPS 2.6.0 Alpha 1. I plan to update it to the latest API later on, but as long as it delivers its functionality with no errors, what is wrong with it? Why should I discount it?

Mamba, you misunderstood me.

as i stated in my post turning those system module functions to stand alone modules is a big development.
having a separate extension menu in admin is just a cosmetic feature and you can see everybody here is confused by that.
also they are not like firefox extensions too.
Quote:

they are just like other xoops modules and nothing more. please read codes to see.
this is not a new approach in xoops. previously we separate pm and profile functionalities from system module and now we separate other parts which is really good.

Edit:
it is just playing with names modules, extensions, plugins, addons.
we should not play with names.
please define a "xoops system extension" for me then name it to whatever you want.
my advise is very simple. Just remove those 2 options from the new modules and let all of them listed in the modules menu in admin.

Mamba, also about the module development you misunderstood me.

for me the development is adding new features to old module both by creating new modules or developing existing ones.
And you are right maybe i was so pessimist because at least there was some development in newbb 4.3.

making old module compatible with the new core php and mysql is essential and i never argue that. Mamba you really doing a great work and put your precious time in this part and i never forget it. your works are really appreciated.

You know that i worked on newbb 4.3 but i dont name it developing.
developing is adding new features.
If a module developer want to create a brand new module (eg: forum) with less feature than newbb 4.3 i recommend him to not waste his time.

This is my opinions about developing.

Quote:
At the moment! Let's not hang on today's code. This can change dramatically in XOOPS 2.7.x. Consider this as a first step to separate them logically from modules, which are "end user applications".

I think, it simplifies things: If I am an end user, I don't have to worry about "extensions", which are being dealt by the Webmaster/Admin.

What I agree with others, is that we need to have a separate directory for extensions, because that's what is really creating the confusion. Once this happens, everything should be pretty clear.

Protector is an "extension", it "extends" the system, but it doesn't matter to the "end user".

Banners is a module, which creates new functionality for the "end user". Unless there is an "end user" who wants to use it, "Banners" doesn't matter to the Webmaster or Admin.

Quote:
Maintenance, bug fixing, and updates, are just normal stages of software development. Saying that development is only adding new things is very dangerous, because it my lead to thinking like: "I am a developer, I develop new features, but I don't fix bugs or maintain my modules" which I dont' think is what we want. I think, we want our developers to fix their bugs, and update their modules for new PHP/MySQL versions, and refactor them to take advantage of new API, etc. Of course, they can be helped by marketing people like me , but Maintenance, bug fixing, and updates are still part of development in my mind.

But if you disagree, I accept it, so let's not argue about it anymore - there are more important things that we agree on and where we can contribute together for the benefit of XOOPS

This is the error in step 10 of installation in install/page_configsite.php:


I had to turn the php debug on with the help of phpmyadmins. IMO it would be great if the debug would be on in the installation process and automatically turned off after a successful installtion
I suspect that it is because of our php 5.2

Quote:
I can understand it completely and it is really a good approach in xoops API which i support it.

but core team dont explain other deprecations.
eg: I cannot understand the below deprecations necessity.
xoops_getModuleHandler to $xoops->getModuleHandler

it needs an explanation because some people like Mamba should put their precious time and change all these functions in all xoops modules to make them compatible with the new 2.6 core.
therefore core team should have a very good reason for that.
Also i may disagree with the below deprecations until i can see a good reason from core team.

for example this one:
xoops_load to XoopsLoad::load

and our widely used function:
formatTimestamp to XoopsLocal::formatTimestamp

I know it is quite easy to change the above methods in calling functions to calling Classes::Functions but i want to know what is wrong with a function like formatTimestamp that we have to change millions of them in the whole xoops modules?


Quote:
Soapbox is working fine in 2.6 thank you Mamba.

I may work on newbb 4.3 to make it fully compatible with core 2.6 because IMO it is very good to have an enormous module working with the new core to find more issues in core and help core team to fix them.


Edit:
Mamba now i see a very new definition from you for modules and extensions:
- modules are "end user applications"
- extensions are "Webmaster/Admin applications"

while i cannot see the above definition in the news i think it is unnecessary to have a new concept for admin only modules.
just pay attention that we already have a plenty of modules that just have admin features and nobody have problems with them so with this new definitions we should turn them to extensions.


i dont have time right now. i will write more in the near future.

I find the root of this bug which i think is very important.
to solve this open class/xoopsform/formcontainer.php
change this:

with this:


It seems we just have this bug in php 5.2
Anybody can replicate this bug in other php versions please contribute.
also i sent it to the bug tracker
https://sourceforge.net/tracker/?func=detail&aid=3560263&group_id=41586&atid=430840

and about the system extensions:
Maybe i was too radical and energetic in my previous posts so im sorry if my way of disagreeing was not polite enough, but honestly i just can see more simplicity with only modules in xoops other than having modules and extensions.
please just think about that: These extensions have not any difference with the current familiar modules and even core team stated that.
Quote:

Naming them extensions and having an extension menu in admin (to just a show off) is confusing.
Therefore Im sure moving them to another directory is totally wrong and will mess everything.
I just want to make XOOPS a better CMS.


Edit:
Quote:

I can confirm this bug in banners module.
to solve it open /modules/banners/class/renderbanner.php and around line 100:
replace this:


with this:

bug in sf.net
https://sourceforge.net/tracker/?func=detail&aid=3560274&group_id=41586&atid=430840

Quote:
Yes, as far as i can see this feature is missing and should be added because it is very handy for webmasters like me!


Edit2:
flipse:
Quote:

It said we should make that folder writable.
IMO it would be better to have this directory in uploads folder just like ranks avatars and ...

uploads/maintenance/dump

feature in the tracker:
https://sourceforge.net/tracker/?func=detail&aid=3560290&group_id=41586&atid=430843

Quote:

Hi, there is a bug when I want to put a module on the default home page