Forgot to mention...

php version 5.2.3

mysql version 5.0.45

Ok I am able to go through the install with all "green" checks up to the point I enter the data base user and password...

I put the right name and password and host in but it goes right back to the same screen with the default values and no error... If I change any of the values it tells me there is an error and forces me to reenter them but has the values I entered.

I am assuming it is an easy fix but I can't see what is wrong...

I WAS running 2.0.17 prior to this... I deleted the directory other then the cgi-bin folder and starting fresh... Dropped all the tables but kept the same user and name etc...

I could probably restore the old site and try the upgrade but I would rather start fresh on this site...

Thanks for any help you can give.

Rodney

I am still getting up to speed here so I guess I should be considered a newbie.

I am about 2 and 1/2 books from feeling real comfortable about how this stuff all works but guess maybe I am jumping the gun a little bit.

Learning the ins and out of OOP with PHP now then off to frameworks, patterns etc last to be followed up by security before I start diving into more specific XOOPS stuff. Guess maybe I should sit back and watch more before I "jump" right in.

My intention with this was to show how you could have 3 different modules have their own versions of a similar "hook" incorporated into one hook. That hook could then be called by the system when needed as triggered by one of the three modules or by something else altogether unrelated and the methods defined in each module would each be run by being included in the main hook. Was assuming some things based on what I have learned so far and guessing on the things I have yet to learn based on what I have seen so far. Hoping that someone more experienced would see the logic and have the details worked out by the time I am up to speed and not only writing my own modules but helping convert some of the old modules.

May have been an expert in making computers talk to laboratory equipment in line based Basic and C but this PHP stuff is a lot more complicated and a lot more facets to it then I originally realized. Thank god for Amazon and $5 used books... ;)


Rodney

Another power of registering the hooks is that you can cascade them if you keep track of the one that is supposed to be run.

As an example...
Module A B and C all have user Delete hooks..

You want all 3 to run when a delete user is done..

They are installed in order.. A, B then C...

When A is installed the original hook is installed, When B is installed it includes the class from A and adds to it to perform its duties, And then finally C is installed and includes the class from B which already includes the class from A. This new class is the one that gets used to delete users...

The added bonus here is when we run the new Delete user function from The class C hook, it automatically deletes the users from A and B since they are included...

I am brewing up a concept to make this work but I am sure you get the gist of the power this allows.

Rodney

Here are some thoughts....

To minimize collision of simular "hooks" I think we also need a way to register the hooks as well as verify they are there.

The problem I see with how we are discussing things now is that you could still have a number of simular functions in place. Unless a module knows another module of set version is installed the module can't assume there is the necissary hook for it..

We should shoot to only do this at module install/upgrade/remove stage which should not impact actual rendering of the site to the users.

We should also have a way for modules to know when there is another module depending on it being there so you know if you should delete it or not...

I would think the purpose of having hooks should be to reduce the amount of code we have in place as well as make it easier to produce new modules.

I believe we should head towards a goal to produce a method of registering these hooks. We establish a supported list of hooks and definitions of what the intended definition of them is. Then it is up to the developers to write hooks compatible with this standard definition thus allowing other modules to know if they use this hook they know what to expect.

With little known or non standard hooks the hooks should be documented so that others can use them.

To support future versions of XOOPS and the needs of those I think we need a way to register the hook versions as well. With any additions to the hook listed in the "version".

So lets say we have a class definition that is made to add a new user to the system.. We have version 1.0 which is compatible with 2.3.3 of xoops. All we need to do is provide the user name, password and email address and it does the rest..


Normally we might use the Profile module to do this... Well we have a new module we want to use instead... It is also compatible with "newuser 1.0" but has additional functionality. We might even now have a "new user 2.0" if there is enough call for it.

So now we have another module that requires "new user 1.0"... It can use either the "profile" module or this second module and know it will have a compatible "new user" add.. The version 2.0 would have to maintain downward compatibility with version 1.0 so other modules requiring 1.0 would know that they would still work no matter if we had version 2.0 or 3.0... But if you installed newer modules that needed the 2.0 they would need the newer module... To promote universal hooks these hooks should only have the defined items included inside it.

The intention here is then we have a simular system to the system API but can be changed on the fly as necissary. You should still be able to have custom hooks as well but as we develop much used hooks we should define them and perhaps get to having a library of hooks that are seperate from the modules that are loaded as needed. Make sense?

Rodney

As I read more about PHP and security and such it makes me wonder why it wasn't written to be put in a "trusted directory" in the first place.

Was it figured out that this format was the best format to be most compatible with everyone out there? I am assuming some setups don't allow for a directory/folder not in htdocs directory.

Guessing at this point it would be a big project to get it to work in such a format.

Seems to me that the potential of having access to the source code (Even if you have just the SQL structures and DB access stuff in a protecte directory) is a bad idea because if a hacker can figure out what modules and versions you are using and such they should be able to look through them for security issues that can be used. I also do realize that in some cases it takes a lax in security settings to actually read any of the .php files but still, if ALL of the source is in the "trusted directory" it seems like it would better secure alot of things... Might mean a change to the way things are handled in XOOPS but isn't the security risk of having the source code available an issue?

Just trying to learn the thinking of how this all works..

Rodney

I am still playing catchup right now since I have been pretty much out of programming for ten year but I am wondering if I am missing something here.

Is there a reason why we can't build XOOPS to be able to reside on a "trusted directory" for all the sourcecode?

So the main directory would only contain the index.php file which would really only contain a simple include to access all the source otherwise?

Would believe it would be more secure and help prevent attacks since there would be no direct access to the source code.

Rodney

Along with the incorporation of module hooks I have been dreaming up a new way of doing the modules as well. The image I have is of a new module that takes into account versions of the modules, xoops, as well as dependencies. The intention is you will have an admin module that can keep track of the dependencies and latest versions.

Eventually would evolve into the sort of functionality that you see with Ubuntu's combo of dpkg and apt-get packages.

Is there something already in the works like this? With the module hook system in discussion we really need a module or system like this to tie it all together and will help XOOPS work well for everyone.

Rodney

I notice there is nothing written on programming for Permissions in the developer wiki for making modules. The documentation I will likely be looking to write will end up being mostly for developing modules and such for now as I get to know them. And how do we go about doing so? Do we write a draft and someone looks it over for accuracy and we go from there?

Rodney

After further thought on this, I do agree that with the current system individual developers can do something like this and you end up with module systems like the "smart" ones or other ones like the "altsys" stuff. However...

I believe if you standardize a way to do this it makes things easier for everyone because I know as a developer I don't want to remake every wheel or copy someone elses code when I do something with a module. Or depend on someone having a particular module installed to make mine work. But if I can allow a module I make work better by using other modules and do so easily then I think it is a good thing. There is no reason this couldn't work much like how the Language system works for translation.

You could definitely use a hash table to list the available routines to use. If defined flexible enough this could be used also to provide for unique options with the modules as well. One such item could be the simple add/remove users item as listed above. The profile module could look for other modules that have a "delete user" or "add user" function that need to be run along with the one from the profile module and yet do so in a way that doesn't require hacking of the original profile module. But I envision still a system that would be used during the install/upgrade/uninstall cycle and not during normal use to prevent a performance hit.

Perhaps a table for interconnected functions such as the one listed here and another for the module "offerings" and dependencies.

I STRONGLY believe after much thought that this is something that should be dealt with when modules are installed/upgraded or uninstalled. I would have to believe if it is done at that time any performance hits should be negated since when you get done installing the module the modules installed should operate no differently then normal modules do now. All of the work is done by the admin and only the end result is seen by the users.

The xoops_version file could have a "dependency" field added and go from there. You could support having different combinations of dependencies by having each line list all the dependencies for that module. (Ie if you could use 1 module or a combo of two modules then you would have the first line list the single module and the second line have the other two modules listed. Thus you can satisfy the dependency with either line being satisfied)

A new Module could be developed to handle the dependencies etc. I envision a module that would work much like the dpkg utility under Ubuntu to handle this stuff. Where you use the utility to install the modules, check for dependencies and activate or deactivate modules as necessary based on dependencies.

My intent with this project overall is that as I get up to speed with PHP and how XOOPS is put together I will help out with trying to improve the flexibility and scalability of this system. In doing so I learn the ins and outs of how the system works and can help build a better system for my own stuff as well. I am outlining a unique dating/social site at this point and no one is doing anything close to what I am doing. Flexible, fast software is needed to run what I want to do and by helping develop XOOPS into a better system MY site will be that much better then anything currently available. I only mention this so you understand my motivation.


Anyhow enough grandstanding for one day, I hope this is something useful and I am off to go play with source code and start figuring out some things.

Rodney