English (United Kingdom)
Jms Multi Site, formerly joomla multisite.
Create, share multiple joomla sites in few clicks !
Message
  • EU e-Privacy Directive

    This website uses cookies to manage authentication, navigation, and other functions. By using our website, you agree that we can place these types of cookies on your device.

    View e-Privacy Directive Documents

Welcome, Guest
Please Login or Register.    Lost Password?

Trouble with JMS basic 1.3.33
(1 viewing) (1) Guest
Go to bottomPage: 12
TOPIC: Trouble with JMS basic 1.3.33
#12076
Trouble with JMS basic 1.3.33 10 Years, 7 Months ago Karma: 0
Hi guys,

I'm newbie of JMS multisite component. I try to install it on a fresh Joomla installation with french translation.

I tried with:
- Joomla 3.3.0
- Joomla 3.2.X
- Joomla 2.5.20

In all cases the installation work but I can't get the multisite work...

Environment:
- PHP 5.3.10
- CP: ISPCONFIG3
- OS: GNU/Linux Ubuntu
- PHP wrapper: PHP-FPM

The workflow:
- fresh installation of Joomla
- rename installation directory to installation.msites
- go to administrator aera
- install of com_multisites_V1.3.33_basic.zip component
- after installation complete go to checkpatches

in the task I see everything in red except: administrator/components/com_multisites/multisites.xml

When I try to apply the patches (click on Install) I got an alert:

JFolder::create: Infinity loop detected
Unable to create destination
Eror during the installation of "administrator/defines.php"

Of course I tried to put everything in 777 but the trouble remain !

Do you have an idea of what could be wrong ?

Regards,
Renaud
score42
Fresh Boarder
Posts: 4
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#12078
Re: Trouble with JMS basic 1.3.33 10 Years, 7 Months ago Karma: 54
The error message is a problem of permission.
When you have an inifinite loop, this is generally due to the fact that Joomla can not create a directory and it loop in trying to create a directory.

You can sometimes bypass the problem of permission, when using the FTP Layer that you can define in the "global configuration".
Ensure that the FTP user is the same as the files and folders owner present in your website.

Which kind of server adminstration do you use ?
Such kind of problem is frequently encounter with "Direct Admin" and with some old "Plesk".

You need to verify the ownership of the files and folders and now if your apache run with the owner of the file or use a static name like "apache" owner.
when the suPHP module is present in apache, it should use the owner of the file that is executed but in your case, this does not seems the case.
edwin2win
Moderator
Posts: 5370
graph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#12079
Re: Trouble with JMS basic 1.3.33 10 Years, 7 Months ago Karma: 0
Hi Edwin,

Please find below my replies to each questions

edwin2win wrote:
The error message is a problem of permission.
When you have an inifinite loop, this is generally due to the fact that Joomla can not create a directory and it loop in trying to create a directory.

You can sometimes bypass the problem of permission, when using the FTP Layer that you can define in the "global configuration".
Ensure that the FTP user is the same as the files and folders owner present in your website.


I tried this option but nothing more change.

Below the extract of the FTP sessions:
Code:


10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/configuration.php" 200 1947
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/administrator/components/com_config/model/application.php" 200 7945
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/administrator/components/com_config/models/application.php" 200 526
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/libraries/cms/installer/installer.php" 200 50752
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/libraries/joomla/database/database.php" 200 5385
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/libraries/joomla/filesystem/path.php" 200 6905
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/libraries/joomla/session/session.php" 200 21614
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/libraries/joomla/user/user.php" 200 18873
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/libraries/legacy/view/legacy.php" 200 19085
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/components/com_content/helpers/route.php" 200 5140
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_multisites/backup/components/com_content/models/articles.php" 200 20965
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/configuration.php" 200 1947
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_config/model/application.php" 200 7945
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_config/models/application.php" 200 526
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/administrator/components/com_menus/models/menutypes.php" 200 11448
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/libraries/cms/installer/installer.php" 200 50752
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/libraries/joomla/database/database.php" 200 5385
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/libraries/joomla/filesystem/path.php" 200 6905
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/libraries/joomla/session/session.php" 200 21614
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/libraries/joomla/user/user.php" 200 18873
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/libraries/legacy/view/legacy.php" 200 19085
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/components/com_content/helpers/route.php" 200 5140
10.12.11.125 - c1_xxxxxx [27/May/2014:14:33:52 +0200] "PUT /var/www/clients/client1/web61/web/components/com_content/models/articles.php" 200 20965



As you can see all FTP interaction got an "200" as reply which means that everything was fine.

The user use "c1_xxxxxx" have the read/write abilities over the whole "/var/www/clients/client1/web61/web" directory and sub-directories. The Apache user as well.


Which kind of server administration do you use ?
Such kind of problem is frequently encounter with "Direct Admin" and with some old "Plesk".


As described in my original post I use ISPCONFIG3. Which is an opensource panel. I'm an experimented sysadmin (I owned the whole hosting infrastructure) and I use this panel just for convenience. I know that this panel use special unix flag (immutable)in the root directory "/var/www/clients/client1/web61/" to prevent some kind of hacks. But your module shouldn't go before "/var/www/clients/client1/web61/web" which is the public web root directory (equivalent to public_html for some panels).


You need to verify the ownership of the files and folders and now if your apache run with the owner of the file or use a static name like "apache" owner.
when the suPHP module is present in apache, it should use the owner of the file that is executed but in your case, this does not seems the case.


The apache user and the ftp user execute the PHP operation under the local userid (unix). I'll send you in PM the URL to test the phpinfo() and see by yourself.

I look inside the error.log and I see nothing about the folder/file creation failure.

I enabled the maximum verbose message in Joomla but we didn't see more information. The only thing happened (before we try to apply patches) is this message:

Code:

Strict Standards: Only variables should be assigned by reference in /var/www/clients/client1/web61/web/administrator/components/com_multisites/controllers/patches.php on line 33 Strict Standards: Only variables should be assigned by reference in / var/www/clients/client1/web61/web/administrator/components/com_multisites/controllers/patches.php on line 34 Strict Standards: Only variables should be assigned by reference in /var/www/clients/client1/web61/web/administrator/components/ com_multisites/controllers/patches.php on line 40 Strict Standards: Only variables should be assigned by reference in /var/www/clients/client1/web61/web/administrator/components/com_multisites/views/patches/view.php on line 39 Strict Standards:  Only variables should be assigned by reference in /var/www/clients/client1/web61/web/administrator/components/com_multisites/views/patches/view.php on line 42 Strict Standards: Only variables should be assigned by reference in /var/www/clients/ client1/web61/web/administrator/components/com_multisites/views/patches/view.php on line 45 Strict Standards: Non-static method MultisitesController::_getVersion() should not be called statically in /var/www/clients/client1/web61/web/administrator/ components/com_multisites/patches/joomla/check_jms_vers.php on line 31 Strict Standards: Non-static method Edwin2WinModelRegistration::getLatestVersion() should not be called statically in /var/www/clients/client1/web61/web/administrator/components/ com_multisites/models/patches.php on line 239 Strict Standards: Only variables should be assigned by reference in /var/www/clients/client1/web61/web/administrator/components/com_multisites/views/patches/view.php on line 46 Strict Standards: Non- static method MultisitesController::_getVersion() should not be called statically in /var/www/clients/client1/web61/web/administrator/components/com_multisites/patches/joomla/check_jms_vers.php on line 3


For you information these tests were made with Joomla 3.3.0 (final release).

Thanks for your support,
Renaud
score42
Fresh Boarder
Posts: 4
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#12080
Re: Trouble with JMS basic 1.3.33 10 Years, 7 Months ago Karma: 0
Up up up Edwin do you have any suggestion about my feedback ?

Regards,
Renaud
score42
Fresh Boarder
Posts: 4
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#12083
Re: Trouble with JMS basic 1.3.33 10 Years, 6 Months ago Karma: 54
To find the effective file or folder that cause the problem of permission, there is no other solution than add debugging things inside the Joomla core to get the name of the file (or folder) that can not be update or installed.

The PHP Strict that you get when providing more error reporting is not a fatal error and does not provide any information on the file or folder that forbid to be processed.

The "inifinite loop" message is generated inside the source /libraries/joomla/filesystem/folder.php
edwin2win
Moderator
Posts: 5370
graph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
#12086
Re: Trouble with JMS basic 1.3.33 10 Years, 6 Months ago Karma: 0
Oki I've apparently fix the issue (in Joomla 3.3.1 at least) by according an open_base directive on "/" path....

Why do you need to have access to the root path ?

Regards,
Renaud
score42
Fresh Boarder
Posts: 4
graphgraph
User Offline Click here to see the profile of this user
The administrator has disabled public write access.
 
Go to topPage: 12
get the latest posts directly to your desktop
2Win, Multisite(s) are trademarks of Edwin2Win.
Joomla