I don't get this one.

I started with a clean installation of Joomla 1.5.14

To proceed, I need to remove the installation folder.

Personally, i don't do that by default, so I do rename
the folder installation to .installation (dot-installation)

(maybe this is a tip to improve JMS)

Anyway, let's call this the master site.

So i proceed with installation of the com component.

This succeeds, so I register my component. Good so far.

So before I start to create slave sites, I suppose I need to patch the master site.

Looking at that section, I do see, it needs patching of the installation folder.

Ok, I do rename the '.installation' back to 'installation'.

But now, well, I can't proceed because, i can't access the adminisration section
anymore, because the installation folder is in place.

So how do You proceed ?

Rename the "installation" directory is perfectly correct and this is also the procedure that we are using and that you can find in our tutorial video
www.jms2win.com/tutorial#jms12x-2

JMS does not redistribute Joomla itself and therefore does not change the way that joomla perform its own installation that require to remove (or rename) the "installation" directory.

YES you have to patch the master as this is explained in the tutorial video 3 that show how to install JMS.
www.jms2win.com/tutorial#jms12x-3

YES JMS need to restore the installation direcrtory.
If you want to re-use your installation directory, this must be do in 2 steps because without the JMS patches, joomla can not run with the "installation" directory present.
So you have to install the JMS patches.
After, JMS will have restored an "installation" directory coming from joomla 1.5.14.
If you want to re-used yours, you can rename the restore installation directory into (ie installation.jms) and after rename your dot.installation into installation

The result will be that you will use your own installation directory.
JMS will ask you again to perform some additional patches to just fix few files.
As the directory "installation" is present, only those files will be patched.

Well, I did read the PDF manual, and the steps are not so well explained.
I will look closer to the video tut.

But I wonder, why don't You use a dot-installation folder by default ?
Or such as .jms.installation

Why the hassle to use the installation' folder, which makes things definetly
more complicated.

I have tried to propose rename the directory in the interface but that seems too complex for the users.
So I have prefered to restore automatically an installation directory to have a unique method.

If a webmaster can't perform a simple rename of a folder
or just can't perform #mv installation .installation
I think the webmaster should consider to take another job
or to read a book for dummies.

Well, I did not look inside the code how You perform that.

But at first sight, it is pretty strange, You do see an installation folder popping up in the master site. Not to mention the security issues. I don't like that either.

So I think it is more safe to move that directory to a hidden place.Better, an unique place such as .jms.ID.installation/joomla (ID=software ID) in the component directory.

More this directory should be provided with a lock/unlock system (chmod) So it can only be initiated when the clone site is created.

Another option could be a password zipped file.

So it would be nice to see a TAB screen (before verify patches), verify Prerequisites
where You can unlock things, upload/verify the installation folder, as verify folder permissions with the 'check' sign'. When this succeed, to go further to the TAB patches.
And to integrate lock rules.

As related to the first installation, it could be possible to provide an upload field,
where people need to upload the zipped version of their installation folder,
or to download that from a remote site related to the version of Joomla (which probably occurs right now ?)

Anyway I do have problems right now with all those issues.
When I don't find the solution I digg inside the code.

The solution is to just click on install button that does everything for you.
I really don't understand why this is blocking for you that JMS restore an installation directory instead of using the one that you have renamed.
Once the JMS patches are installed, if you don't trust the installation directory that we have restored and that come from the joomla 1.5.14, you can re-use your installation directory.
Have a look into the tutorial video that show you how to proceed.
www.jms2win.com/tutorial#jms12x-3

As you say, it should not be difficult for a webmaster to rename a directory.
The only thing that I have told you is that you can not do such operation before to have installed JMS patches because standard joomla cannot run with 'installation.php" present.
So start to install the JMS patches and after that you will be autorized to remove or renamed the installation directory because the joomla kernel will have enough modification to accept working with or without the "installation" directory.

Concerning the security, if you follow the advised that we have provided several times in the forum that consist in the installation of the master website into a speciifc directory, this mean that you can later deploy the slave site (if symbolic link is allowed) into a specific directory. When this is done, you can remove the installation directory in the deployed directory and it will be unavailable (No need to do chmod or whatever and the directory does not exists).
I always recommend to install the master website in a confidential domain and also consider the master website as a library or repository for the slave site.
As soon it is confidential and protected, there is no need to do such work on each directory like you propose as all the websites is hidden.
The slave sites will only have links on the master website and you can remove the "installation" from a deployed slave site once it is installed.
If you replicate an existing website, you can also define a rule in JMS templates to ignore the "installation" directory.


Concerning the permissions on the files, we already implemented a check concerning that but we know by experience that it does not detect the permission issue on all the environment. The real method to check if it is possible to write into a file is to really write inside. The function "is_writtable' does not work in all the cases, test the owner and group of the files does not necessary help and the function to do that are not necessary available on all the platforms, other security PHP modules and parameters may also have impacts on the permission (ie. does suPHP is used, does open_basedir is enabled, safe mode, ...)
If you know an accurate algorithm that would be able to check the permission in whatever environment and platform (unix, windows, ...) we would be happy to know it.