When attempting to install DTReg 2.6.3a on a site running JMS 1.1.24, I was able to install it on the master site (babatree.org), but each time I try reinstalling it on a slave site (zenvc.org), I get this message:

* JInstaller::install: File '/home/zenxing/public_html/tmp/install_4bb4f884f3b16/install.dtregister.php' does not exist.
* Component Install: Could not copy PHP install file.

After this, the component seems to be corrupted on the master site as well and the only choice I can see is to uninstall it, which I have now done.

I haven't had this problem with any previous installation of DTRegister, including 2.6.1, which I have now reverted back to. 2.6.1 installed again without any problem on both master and slave sites.

Any thoughts as to what in JMS would cause this to happen? I would love to be able to use DTRegister 2.6.3.

Thanks for any help.

Jesse

Jesse, perhaps it would be time to consider upgrade to JMS 1.2.x that contain the JMS tools that can be used when an extension has specific stuff.

Edwin, is the upgrade to 1.2 seamless - just 1 click install with Joomla, or do I need to uninstall 1.1 and recreate the master/slaves again with 1.2?

Normally the install of the JMS 1.2 can be done over the JMS 1.1.
By security it is recommended to perform a backup.
The procedure consists in the "uninstall of the patches" to remove the JMS 1.1 patches and restore an standalone Joomla.
When done, install JMS 1.2 over the current JMS 1.1 and re-install the JMS patches.

All the slave sites definition will remain on your system.
We just recommend to open and resave one existing slave site or just create a fake slave site defintiion with whatever. Just to for JMS rebuild an internal new JMS 1.2. structure.

You can also try to install it directly over the current JMS 1.1.
At the orgin it was require to uninstall the patches before the upgrade because some files had to be replace.
I think that with latest JMS 1.2.26 or higher this is perhaps no more required because they are addition conditions that had require to update the same "antical" files that should be detected and updated.

Personnally when I have upgraded recently one production environment from JMS 1.1.8 to JMS 1.2.24, I have started to perform a backup of my current master.
I have restored on a local machine and tested the upgrade to JMS 1.2 to check that everythng was OK. I have started to un-install the patches before the upgrade to JMS 1.2.
After, I have re-applied the procedure in production.