Hello Edwin,

>>> Would you please send me in attachment of an email the K2 package that you are using to let me try reproducing it.

The package of K2 is not different because I have downloaded it from the web install tab in Joomla.

>>> Concerning all the specific requirements, I think understand partially what you would like but this require a specific development that I don't want to include in JMS due to all the side effects and potential increase of support that this will probably leads.

JMS is a tool for clients having multiple domains for 1) “cloning““ and 2) “sharing“.
Both these functions are fundamental to concept of multisite and, thus, are fundamental needs of your clients.

JMS has become a little toy to clone a specific set of configuration of an extension. It has failed to develop in the area of sharing in the last ten years, at least after I purchased it, and to demonstrate intelligent technique of “sharing“.

In the area of “sharing“, JMS has remained dumb and primitive.

What it does, I can do it all manually without JMS. While doing so, I can develop templates for creating a new. JMS is merely a management tool to grab parameters of external Joomla installation and manage configuration of the external slave databases from the main code base.

From day one, the demand by all clients was there, for “cloning““ and “sharing“. From day one, you have not developed sharing technology in JMS the way how a mature product should have achieved in ten years.

You have developed php codes to clone from a master database on per component basis. This is necessary and helpful for newbies and experts. In the last ten years, you have developed cloning technology much more and left sharing technology too restrictive. The conceptual focus should have focused on sharing technology and “thereafter“ cloning. What you have not developed is a generic sharing function to convert parts of a component into VIEWS and to have certain tables shared.

A wrong belief is to have inconsistency of a slave database by views. The fact of using VIEWS already means that database tables are absent in a slave. But that's a choice an admin makes.

>>> As I already said that allow creating views without any control is dangerous in terms of consistency.

Well, “ dangerous in terms of consistency“ for whom? Are you talking about foolish or newbie clients, who do not know what they are doing, or talking about experts like me? People like me do not need any babysitting on what could be consistent and what not.

You do not want to develop sharing function in parts of a component. You give reason that there could be foolish clients, who may result in some inconsistency upon using sharing functions. Thats the reason why experts like me cannot avail these functions.

I have the capacity and competence to program shell scripts *.sh to clone a Joomla installation and create links to directories, then ones I want for slave domains. In fact, I have developed such cloning shell scripts for Bonfire on CodeIgnitor that works like charm. Likewise, I could also develop - without problems and too much work - shell scripts to create sharing MySQL tables of same code base for slave sites. JMS is in my list only for comfort and ease.

When I want to have a set of tables shared, and not full component, then I have technical reasons. The same apply to others. If a client - as a user of JMS - is a fool or a newbie, and does not know what should be done with it and what not, then it is not necessary to think that “he should not be, or cannot be allowed to be, foolish!“.

You are trying to be extra careful, of course in the interest of your clients. But then, you are imposing restrictive approach on functionality of JMS and, consequently, are not developing coding logic on certain fundamental features of JMS. They are missing today.

For example: If I have DJ-Classifieds or EasyBlog extension, I may want to have the same category or geo IDs in different slave databases. If I have twenty subdomains that focuses on twenty categories, then I may want to have a central table in master DB for categories for DJ-Classifieds or EasyBlog and showing these table on categories in all these slave databases. This allows to have the same IDs and have different data specific to that slave domains.

Sharing such common tables also means reduction of space. The geo database from a website (GeoNames?) requires 35 MB for one language. They offer 8 - 10 such databases for free. Two languages would costs 70 MB in one database. Why should one have 20 slaves x 70 MB cloned?

Every seperate database table will have to be indexed and their handles to be generated for queries. This requires sever resources.

On the contrary to your declaration, there is a “consistency of data“ amongst master and slave and “not inconsistency“ of data“!

The stupidity of Lead developers of Joomla has lead to embedded stupidity in Joomla's core. Every developer of component wants to have their own category IDs and own geo IDs. There is no consistency. It is not wrong to offer Joomla users to have a consistent ID system of categories and location IDs. Had that been there, one could use it in Registration process optionally asking a new user from which country he is based in. As this is missing, every developer of component or plug-in wants to demonstrate his expertise and make new IDs.

Sharing such tables based on categories or geographic locations within a component in master database is a fundamental need of every client. Because this function is not in JMS, no one has asked about it. If I am the first one, then it does not mean that this is a specific need of mine. This is nothing specific to myself.

What JMS should do is to let admins specify a component and then capture dynamically all tables related to it. One could also generate a drop-down tables to be selected for sharing, just the way how vData component in Joomla does. Having chosen the component or tables, one could then dynamically generate codes for sharing and convert them into VIEWS. Here, one could also have the data imported into master, if the table structure is the same or drop it.

Because the sharing technology has remained under developed in the last ten years, while it is scalable, I am really sorry to say that JMS today is too restrictive in terms of its usability.

Concerning K2, I have downloaded the version 2.8.0 and installed on the master with success and it is correctly defined in JMS as I have been able to select this extension in JMS Template and be able to create slave site that share its content.
I also been able to use the JMS Tools and add K2 as shared extension into an existing slave site.
Therefore, I don't find any issue concerning the K2 sharing.
If you want that we connect on your environment for a deeper diagnosis, this is still possible with our billable support that you can order at
www.jms2win.com/index.php?option=com_vir...orderby=product_name

Concerning the VIEWs, more than 90% of our customers must be considered as novice and does not have any experience in the sharing and in consistency.
Perhaps that you are an expert and know how to ensure the consistency of the data. This is great and therefore as you said, you are able to create the views manually.

As I told you, we are able to create specific plugin to let you add in XML specific rules. We do that with 1 hour of support to create such specific plugin.

Concerning your example of partial category sharing in DJ-Claissified and EasyBlog, this can not be done in JMS without modificiation of those extensions to add a field in their tables.
Concerning EasyBlog, I think that you can ask to the author of EasyBlog to add such functionality. When they did that for EasySocial, we suggested that also do it for EasyBlog but they didn't implemented it because they didn't saw the interest for their customers, like for EasySocial. So perhaps that you can submit them the request to add the PHP Code in their extension to filter on the JMS Site ID in the categories.
For the moment, EasyBlog is only defined for a whole sharing of their table and not partial content.

The same for any extensions for which you would like to have a partial sharing. Request that to the author of those extensions because the modification in their code must be maintained in the time.

Concerning DJ-Classified, we never received any request to share their content.
Again, send us the extension in the attachment of an email and specify for which version of joomla you would like the review for the sharing.

Concerning the consistency of the data, you are wrong.
For example, you can not have inside an extension a reference to an "Article ID" to provide a specific text if this article is not also shared between site. (ie. to make reference to general condition, specific description, ...)
When you have such kind of things, this mean that you also have to share all the article and all the categories and all the users and all the tags, and finally almost all everything. In this case, this is no more a sharing but you have to use the same DB with same prefix between the websites. This is our "Share all site".
Perhaps that you know what you are doing but the majority does not know that and does not take care about the data. Once they are facing to the problem, in general this is too late and it is very difficult to fix the data in the DB once plenty of records and reference are created by live users.

Perhaps that you consider that JMS is too restrictive but as I already mentioned, we can develop a specific plugin to let you add specific rule in XML files.
As you mentioned that you have the skills, this is probably the solution to your needs to declare any rules under your own responsibility.

Hello Edwin,

I give up as any discussions with you cannot help in substance. Even in our telephonic conversation before nine years, I had the same feeling. In the above post, I tried to explain any misunderstanding, if there was one. It was not that...

Where the the hell did I talk about sharing "Article ID"? You are making a joke by talking about "Article ID" sharing, when I am talking about "Category ID" sharing.

Your answers are thoughtless and pointless. I discussed about something generic and you begin to talk on something extension specific. As one could see, both of us have no common point to talk about, if you answer something else that what I am trying to address.

Regardless of this, I want to honestly thank you for your take time to answer my request. I will assure you that I will not do so in the future, in placing questions of this kind. This was my terrible mistake that has wasted my time and have eaten your time as well

This is now my last post.

Sorry to see that you didn't understand the example with the article sharing that illustrate the fact that we can NOT share any tables without knowing deeply all the relationship and why we don't want to provide such generic sharing that would leads to inconsistencies. This is the inconsistencies that force us to forbid to allow sharing whatever, as most people does not take care of the consistencies.

I told you that a specific plugin where you will setup XML file can do that but this is a specific thing that we create from time to time for specific needs like the one that you have described.

To all other users, who may be watching or following this postings:

Following SQL query will create sharing of categories of articles from the Joomla default component:



Just substitute respective details, like master_tableprefix, etc. This SQL query will drop the table categories from default installation in slave database and after that create a VIEW from the master database table of categories.

With this, all categories from the master database will appear in the slave database.

Consequently, all the category IDs in master and slave databases will remain the same.

You could create new categories anywhere, from slave or master. Then the new categories will be saved in master database as all other slaves have a direct access through VIEWS.

Exactly this is also done with the User tables. They are one one ones in master, which any slave uses.

The above concept does no different than that.

With this method, every user could create VIEWS of a specific table in master database and have that shown in a slave database. This might be interesting and important, if one wants to have the same details from a table made available anywhere in any slave.

The advantage of this system is that one has the same categories from the master but will have different data of articles in the Joomla content component.

To have a merge of all slave articles, one could easily configure the auto-increment of an article in the table_content to have for slaveOne.com starting from 100000 and slaveTwo.com starting from 200000 and so one.

Thus, later, one could even import all articles into one website if one wants. Although if one does not, there is no harm.

To do such a replication of a master table, you simply create a new VIEW of that table in master. Then export that view, change necessary details like above example, and run that SQL code in a slave.

That table_category will be shared.

Likewiese, if one has masterprefix_countries, masterprefix_states and masterprefix_cities, then one could create VIEWS of those master tables and display them into all slaves. Thus, all the Geo-IDs of countries, states and cities will be the same in all slave databases.

Thats it.

And this tiny little thing Edwin did not understand. Thats a pity...

If you do such kind of sharing, be careful that you also need to share the user that is made in reference.
You also need to share the Assets table that are used to determine the ACL that are given to the categories.
As well as all the relationship and the category "options" and permissions must also be shared.
The additional "params" may also have content that is local to a website. (ie. the image path).
So you have to ensure that you also have the same "media options" and that you share the same image path on all the sites.

By your post, you clearly show that you didn't took in account the consistency and create inconsistencies when all the relationship are not also shared.

Perhaps that in your specific case, you also have shared all that and that it works fine for you but this explain why we refuse to generalize such kind of sharing without any control.

Thank you for this illustration that shows what CAN NOT be done without any control and why in such specific case we propose to develop a specific plugin to declare the specific sharing.