Daigoro:

Wow, very impressive... looks like you have worked out most of the details!

I was just wondering about a couple of little things:

1) 'constant' would only be needed to retrieve the value of a constant (e.g. constant($varPrefix . '_GREETING')), but won't by needed for the line:

$modversion['dirname'] = constant($pathparts[1]);

2) $ModuleUrlPath, $ModuleRootPath... do you define these inside all function(s) which need these? I don't think you would be able to use globals for these, unfortunately.

3) For $xoopsModule->getVar('dirname'), do you the global value $xoopsModule? I'll need to look through the XOOPS core again, but I wonder if this might fail for modules included as blocks (for example a 'recent links' block when viewing a forum page; in this case $xoopsModule would refer to 'newbb' so it might not give the correct prefix when loading the language files for 'mylinks'.) Not sure, I'll comment again about this once I know more.

4) Is there some way to use $varPrefix for generating function and class names too? This seems like the only obstacle to making a module which is trivially clonable. It looks like maybe 'create_function' would be useful:http://www.php.net/manual/en/function.create-function.php. It might be a little tricky to give the functions meaningful names (though one of the user-contributed-notes on the php.net site looks helpful), and also might be tricky to actually call the functions. There must be a better way. I'm not sure at the moment how to create classes with 'dynamic' names.


Anyway, let me just say again, very impressive - thanks for posting this!

Best regards,
Mike

Quote:
This should work, but you have to define _MI_PJREVIEWS_NAME *before* you reach this statement.

Note, you *can* have constants with the same name in different files. BUT if both files are loaded then you get the conflict. The trouble is XOOPS core loads several files from each module to e.g. display the menu block, or if you have blocks from several modules on the same page. This can lead to conflicts. So even if you are visiting somesite.com/xoops/modules/news/index.php which is loading modules/news/language/english/main.php; if you show the 'recent news' block from the 'news2' clone, then it is loading automatically modules/news2/language/english/main.php. So if you duplicate the constants you are likely to get errors. Try it.

In answer to your second question use $module->getVar('name'), as the functions like 'name()' are deprecated.

Quote:
The problem is the language constant will have to be different for the module and its clone. Thus you'd have to replace the language constant everywhere in the cloned module. e.g. _MI_NEWS_DIRNAME => _MI_NEWS2_DIRNAME. So I don't think it solves the problem . You'll have to use something which is dynamically updated, like $module->get('dirname'). There is a small performance penalty (only a function call because the module info is cached internally), and if you are careful about *when* you retrieve the info in your code you can minimize the overhead. Good luck!

Quote:
This is something that PHP does... we really have no choice in the matter. That is why we have all the naming rules for functions, class, language constants etc... it is so that when we process blocks etc from several modules, that we don't get collisions when we include their classes and functions.

Quote:
include_once might work, depending on how the module is implemented. If your cloned module shares the *same* files then this would be good enough (i.e. 'news2' actually includes files from the 'news1' directory). If they have the same files, but each has their OWN copy of the same files, then this won't help because PHP considers them as distinct files.

However, most of this is irrelevant because most people write their functions with hard-coded dirname-dependent things. For example a function 'news_get_all_articles' might contain something like: $sql = "SELECT * from xoops_news_articles", etc... In the cloned module we need xoops_news2_articles, so basically we need a *copy* of the function but we'd have to name it 'news2_get_all_articles' so both functions can be used together. Basically this requires everything to be duplicated, but with change of 'news' to 'news2' everywhere.

The alternative is to write modules such that the database table 'xoops_news_articles' is not hard-coded, but somehow looked up every time it is needed. Then two modules could share one copy of the code and still function independently. This would be very tricky, and XOOPS may not support enough core functionality to do this.

I'm not sure my suggestions of 'function_defined' are all that useful, but here's a little info. This is a built-in PHP feature:



Sorry for the confusing post... hopefully it helps a bit . If you have any questions about it, let me know...

Quote:
Good point. However, modules are treated independently by Xoops, and if both modules are loaded (e.g. a block from each clone, or a menu item from each clone), then there are going to be clashes. (All functions and classes are defined in a global scope. If a file is included containing functions or classes which are already defined, then errors will result.)

In the cloned module, you'd probably have to make manual modifications to just include the code from the *other* module so files don't get included twice. (Or you could use 'if function_defined', 'if class_exists' to conditionally load files.) Not impossible, but also not as simple as just installing two copies of the module with different dirname.

I think this is a very good division of the issues.

On the clonability side, I think most modules will have problems unless written *very* carefully. Ideally, you should just be able to change 'dirname' in xoops_version.php and have yourself a new copy. This would require the mod-writer to use the 'dirname' variable for ALL references to stuff in the module:

- database tables must be constructed from xoops_prefix + dirname + tablename
- any files/paths mentioned the dirname must be constructed from the dirname variable
- any URLs containg the dirname must be constructed from the dirname variable
- all constants (including language constants) must be constructed from e.g. _MI_ + dirname variable + language key
- others?

If these steps are not taken, there will be conflicts with two instances of the module running.


On the presentation side, I agree that yes you can have a lot of mileage with a given module just by changing some language strings (and perhaps templates).

Quote:
Many links scripts and links modules for other CMS have facilities for checking links, so I would be surprised if this was not eventually added in XOOPS mylinks. Probably it would be worthwhile to post a feature request at dev.xoops.org

You could perhaps make the name "Reviews" a module config option, but it would be difficult to incorporate into all your strings.

Would the following accomplish what you want? i.e. just require a change in one place?

define("_MI_PJREVIEWS_NAME","Reviews");

define("_MI_B_LATEST", "Latest " . _MI_PJREVIEWS_NAME);
define("_MI_B_SUBMIT", "Waiting " . _MI_B_SUBMIT);

Note also that for naming your language constants, it would be better to use _MI_PJREVIEWS_B_LATEST and _MI_PJREVIEWS_B_SUBMIT instead of _MI_B_LATEST and _MI_B_SUBMIT.

Quote:
I think we've already discussed this in a couple of other threads . Auto-login FUNDAMENTALLY (not just with Xoops) carries some security risk. For example if someone else uses your computer and you forget to log out, then they will have your privileges on an XOOPS site. Another risk is that cookies can be "stolen" via e.g. javascript techniques (if any modules or blocks with XSS vulnerabilities are installed), and the 'thief' can then log on as the person from which the cookie is stolen. Generally, it is advised NOT to select "remember me" if you are an administrator/moderator/privileged user.

The "remember me" feature is INHERENTLY risky. As a webmaster, you weigh the risks:
- how likely is your site to be victim of attack?
- how sensitive is your data?
- how valuable is your data to you? Do you make regular backups?
- can your admins be trusted to NOT use auto-login?
- how important is it to your users to support this feature?
- many many sites offer this feature without incident
- etc.

I'm not currently active in development at the moment.

I think there are some interesting ideas there, but I don't fully agree that they all should be part of the 'core' content structure for all users. Also, some distinction needs to be drawn between what is a 'field' in the content table (id, title, etc...), and what is outside the table (e.g. max content length). I have been thinking about similar ideas myself for quite a while...

You do realize, I hope, that it would be a HUGE job to convert XOOPS to such a scheme. It would require not only core changes, but changes to EVERY module to be consistent with this approach. Perhaps the conversion can take place incrementally... For example, a first step could be to add common fields (with consistent names) to each of the content tables and them some central mechanism would know where to look for the info. (Each module or item type could have a flag indicating if it is 'compliant' with this schema.) This would pave the way for the full-blown scheme, and provide an easy way to write upgrade scripts etc... But again, *if* this ever happens, it is a *long* way off. (Maybe the other more active devs can give some insight into the long term plans, if any, in this direction?)

If you are looking for a unified solution *now*, I would suggest you have a look at the features of Drupal (php), eZ Publish (php), Plone (zope/python), etc which all follow an approach similar to what you have described.