We bought jsm2win almost year ago and unfortunately can not implement because most of the portal operations is based on jreviews structure

I contacted Alejandro from reviewsforjoomla.com and he is open to provide support and hopefully both developers will support each other for benefit of their clients


Please kindly visit

www.reviewsforjoomla.com/forum/index.php?topic=12770.0



We are not able to look into this for now. We have so many other feature requests and major tasks like J1.6 compatibility that something like this falls at the bottom of the priority list. The fact that JReviews is encoded doesn't have anything to do with this. If I remember correctly I provided them with a license to look into this and tried to assist.

If you can get someone to help you and they need for some reason access to an encoded file, then I am able to help. That shouldn't prevent anyone from making the modifications they need and I am all for that.


Please kindly consider looking at it. Many clients will be happy.

The problem is that they have to change their license management and I had replied to that several time. They want to for using a specific "security" code for each website that does not allow to share the user between the website.

As long as JReview require to have specific global configuration "secret" code when website are share, as long it is not possible to have specific configuration because they are using this secret code to manage their files.

there is answer from Alejandro


JReviews uses the standard and readily available Joomla configuration "secret" var in order to construct the filenames for the configuration cache and other cache files to make them unique. You can either (1) ensure that each site has a different secret word. It comes from Joomla configuration.php. Or (2) Change the code that fetches the secret word from the configuration file so that instead it uses the domain:

/components/com_s2framework/s2framework/libs/cms_compat/joomla15.php

Code:

function getConfig($var, $default = null)
{
# Will need to add a conversion table for configuration variable names once they start differing between CMSs
$cmsConfig = RegisterClass::getInstance('JConfig');

if(isset($cmsConfig->{$var})){
return $cmsConfig->{$var};
} else {
return $default;
}
}


Change it so that if the $var is "secret" it returns something else like a hash based on domain name, install path or any other way that works with jsm2win.

The problem is that the "secret" value can NOT be different for each slave site and that can have othe side effect than the problem with the reading of the config file.
We are not able to review the code of JReview and therefore, we let JReview implement the stuff to be compatible with JMS Multisites.

Alejandro's Answer

I hope finally you will find workable solution for the sake of your clients


That doesn't mean I am going to give out the whole code, i need to understand what exactly is getting in the way of them not being able to evaluate something. We already went through this once and it didn't work. I am not sure we are going to have any better luck this time. My focus is JReviews, not multi sites.

JReview has to ensure that if the "secret" code is identical to all the website that don't have any confict.

Concerning the configuration, if they want to continue writing the confg in file on the disk they could compute the files name differently when JMS Multisitesi is present.

Here it is a sample code that could get inspired.

To read the config, If multisites ID is defined, this mean this is a slave site.
If the configuration file exists with a suffix of the site ID then use it.
Otherwise, use the default "master" one.


if ( defined( 'MULTISITES_ID')
&& file_exists( dirname(__FILE__) .DS. 'configuration.' .MULTISITES_ID. '.php')) {
require_once( dirname(__FILE__) .DS. 'configuration.' .MULTISITES_ID. '.php');
} else .....


For the writing, this is the same process.
Write the MULTISITES_ID suffix when it is defined.
Otherwise, use the normal name.