this my minor issue and not so minor issue.

I got for example x site with the smartsection module installed, preferences have been configured for the module, categories and articles written..

now if I want to migrate just the smartsection data from "x" site to "y" site... I back up all the tables called xxx_smartection_something ...import them to the new site ...and yes apparently all the content and categories are there.

BUT then looking in more I realize all the preference options, permissions for articles...etc have been saved in the xoops_config table..... data I can not import to "y" site because it would import lots of unused information.

So this means it is very hard to migrate succesfully all the data generated from one module from one site to another, because some part of the data always goes into the XOOPS core tables. I really think all module generated data should be kept to it's own tables.

I just wonder if module developers could have in mind Keeping core database data separate from the module database data?

...am not sure if this a module developing or XOOPS core issue, or both

You mean - instead of adding configuration of the module with 4-5 lines in xoops_version.php, you want each module developer to implement his or her own preferences, group permissions etc. in the module?

Seems like an awful waste of efforts.

no, not for each module developer to create his own group permissions and preferences, this is one of XOOPS strongest and most important caracteristic to let go of it like that.

...but that somehow the module data should be easily extracted from the database ...so when doing a migration of not the full site but just a module and it's content could be easier

...maybe a tool that can make a full backup of the module including it's preferences which are hidden among hundreds of rows in the xoops_config table

Hey Snow,

Unfortunately, this is not really possible for the module dev's if they adhere to using all of the available XOOPS functions.

EG: All of the 'Preferences', 'Comments', 'Notifications', and Module / Block permissions are tied to functions (and tables) from the core.

Sure it takes some time to reset the options, etc... But what I think we need to push more for is for Module Devs to use the tools that GIGOE has put together for D2 & D3 (Duplicatible) Modules. All the sudden it only takes a couple of minutes to reset the permissions when everything you need to set is available from within the module admin section (Group & Block Permissions & positioning, Prefs, etc).

Unfortunately, there is still a real lack of clarity and standards for Module Development, made worse by the current Repository problems and lack of PHP5 support in legacy modules (which can usually be fixed in a matter of minutes if you know how) etc...

While it would be nice to have all of the data related to a module within the module tables, that would essentially require a much stricter (Development) standards set, would break most, if not all current modules, if introduced into the core, and would alleviate the benifits of having core functions for developers to 'Hook' into.

So while I understand the issue you raise, I think the resolution lies in providing all of the modules Options to be accessible from within the module as opposed to trying to move the Core data/functions into Module tables.

Thoughts?

thanks for the answers. I know it's a rather complicated / tricky situation. Just was wondering if that could spark up some new more advanced programming ideas with the connection between modules and core.

you've got a good point in considering having the options accessible from within the module, that would facilitate things a whole lot more.

and well if this opens up a dialog or the minds among module developers, it will be pleasing to see things keep evolutioning and new thoughts coming along.

you could use an sql query to search for all rows WHERE conf_modid = x

where x = the module id..

i know that's not the point of your post, but a nice tip for anyway ;)

That is a great a tip, thanks

Now I know it's not that impossible. I guess nothing is impossible when knowing which tools to use and how to use them.