I did the second way long time ago, but I think, it was simpler:

a) Import from smartcontent to publisher
b) uninstall smartcontent module, and delete the folder
c) create a clone of publisher called smartcontent
d) uninstall "publisher" and delete the folder

Of course, make a backup of "smartcontent" just in case something goes wrong.

Mamba, I don't think so - clone uses different tables, than publisher - check sql files in both of them (prefixes for tables in files).

It means, publisher is fully clonable.

But that's the point: Publisher clones the tables and files and creates a "new" clone, that is its own entity, i.e. it can coexist with the original publisher.

This way I can have:

Publisher
Clone1
Clone2

and all of them can be on the same XOOPS installation, and are independent from each other.

Unless I misunderstood you....

Correct - that's right.

In a short time I'm going to create two copies of publisher (publisher and "new publisher" in my website wodniacy.eu - the first one just is installed and now we try to create a content (it's some kind of almanach/vademecum for leaders of seascouts), the second one it will be vademecum for sailors, about sailing. Two different modules with the same functionallity.

I suppese, your method of importing datas was possible in fmcontent, because version 1.5 and 1.1 was based on one pocked of tables both for oryginal and clones.

the fmContent module was different, because it kept all the "cloned" modules' data in the same table.

So you had the original "fmContent" module, and then you've created:
fmContentClone1
fmContentClone2

but all of them were sharing the same tables, i.e. you couldn't easily move fmContentClone2 to another XOOPS installation.

The Publisher's way is better, in my view, because it creates "independent" clones that are easily transferable to other XOOPS installations.

Quote:
yes, i imported the old smartfactory successfully. this procedure works.


Quote:
This procedure is wrong because in the "c" step the cloned module is not installed yet!
when you clone publisher you just have another fresh module without any tables in the database. then after installation it create tables and it is a fresh module.

I still think the GIjo way of cloning modules is better (maybe the best way). In the cube they called it "Duplicatable V3 (D3)"
He is a very professional coder and IMO he knows everything better than all of us. I mean he can choose the way that trabis use in publisher because I think the trabis way is rather much easier for developers while Gijo way is hard for them.
in the contrary, for the end user Gijo modules are so much easier for install/upgrade/clone/uninstall

please read the below as some advantages of Gijo cloning way:
1- You have one big base module and many small childs (clones). These childs have a few files and you can copy/paste them very easy.
2- You can create a new clone as simple as renaming a directory.
3- You can upgrade your cloned module very easy just copy the new release base module and you will not touch the clone at all. ( while i dont know in the publisher how we can upgrade a clone easily? the name is different. tables are different and ...)

Im not a developer and the above opinions are just based on my experiences. Maybe there are more advantages of Gijo modules that i can not mentioned. a developer can see the codes and explain better.

I still think xoops should have a procedure for cloning. some standards would be great. then all module developers should clone based on that. something like Mage done for Admin GUI.

for example the current issue that Mamba raised from Voltan's fmcontent. the clones dont have separate tables which i think is not good at all.
maybe a standard for tables in database is necessary as below:
- (XOOPS_PREFIX)_(DEVELOPER_UNIQUE_PREFIX)_(CLONE_PREFIX)_(TABLES)
eg: xoops255_voltannews_mycontent_stories
xoops255_voltannews_mycontent_topics
.............

Quote:
I think so too.
It seems to me that this is a good time for Trabis and Voltan cooperation. Why?

1. Both modules are designed to the same: they are an advanced information management system, both static and dynamic.
2. a) FMContent, that's much more than a module for static content.
b) It has quite good, working util for articles sort order management, well-resolved image display. But cloning method and SEO are "under constraction" (from the other side, SEO is designed holistically).
3. Publisher is totally clonnable. It's still RC (I suppose, the signature of Trabis is to have all modules still "under construction" ), but it works and has some interesting solutions (author's mask, etc.). But there are no good tools for sorting the items, partially SEO and a lot of errors (image management, sth in some blocks, complicated configuration).

If Voltan and Trabis began to collaborate, XOOPS quickly should have a great and flexible module for content management, both static and dynamic. After adding the import tool from Smartsections, niusów, MastopPublish and Content it would be great.

Quote:
A part of module functions can be placed in XOOPS_LIB - it can be common for all instances/clones.

I still beleve, it will be possible for me to test last RC version of very good "content module" before my summer trip on the sea. It will start about 9th of June - next time I should have a time to test anythig after 25 of July.