TOPIC: CTransifex 1.1 needs PHP 5.3

I'm not sure if you wrote it somewhere or even are aware but CTransifex 1.1 needs at least PHP version 5.3.0 since it is using the "parse_ini_string" function in the /models/language.php on line 37.
Maybe there are even more requirements but this is where my initial processing of the language files failed on my live server.

Also uninstalling CTransifex 1.1 and trying to reinstall 1.0 or 1.1 afterwards fails with the error "Component Install: DB function reports no errors". Not sure what happens there.

Hey Thomas,
I was not aware, but thank you for finding this. In the next version I'll add 5.3 as requirement in the script.php and people won't be able to install it on system that don#t support it.
Version 1.0 is also requiring php 5.3 as it also uses parse_ini_string

The error that you are mentioning is a joomla error. Search google and you'll find a solution for it.
Regards,
Daniel

Hi Daniel

Ah, I didn't try the version 1.0. Checking in the script.php is a good idea. Maybe also note it in your download section so people could see it before they even try to install.

The install error may be a Joomla bug or not, depends on how you look at it.
I tried to track down the problem and it is caused by your /assets/install.xml file. This messes up the uninstall function.
When uninstalling an extension Joomla tries to find the manifest file, and it does this using the findManifest function in /libraries/joomla/installer/installer.php. This will get a list of all xml files in your directory and then checks each xml file if it's a valid manifest file (starts with <extension> or <install>) and uses the first one found. Unfortunately in your case it finds the install.xml in the assets folder first, which of course is the wrong one. I guess it's a template for the language file manifests?

Renaming this file to a file extension other than xml should solve the issue.

Hi Daniel

I've found another issue. If you install more than one language pack, the second will just overwrite the first one in the #__extensions table (and thus the extension manager). This is because the "element" is set based on the name of the manifest file. In your case you always name it "install.xml", however it should be named the same as the extension. So it would make sense to name the manifest file something like "<extension>-<language>.xml" instead of "install.xml".

Also it would help if you add the language to the <name> tag in the manifest file, so one can distinguish multiple language packs in the extension manager. Since you already str_replace @@LANGUAGE@@ in your packager, you can use something likein your /assets/install.xml file and it should work I think.

Thanks for your work!
Thomas

Made a PR on GitHub so you can see the changes I would make.
github.com/compojoom/ctransifex/pull/1

Hey Thomas,
I was going to suggest that you make a pull request, but you did it already

I'll have a look and merge everything. I've never experienced the "cannot install" error and that is why I can't imagine why a file that is named install.xml is going to do any harm. At the end joomla looks for extension-name.xml in the root folder. Everything else gets ignored. (or at least this is what I thought)

Regards,
Daniel

Daniel Dimitrov wrote: I've never experienced the "cannot install" error and that is why I can't imagine why a file that is named install.xml is going to do any harm. At the end joomla looks for extension-name.xml in the root folder. Everything else gets ignored. (or at least this is what I thought)

That's what I thought as well and it took me quite some time to figure out why the uninstall of your extension wasn't completed.
Just in case you're curious, this is the code the installer uses to detect the manifest file.It's located in this file

/libraries/joomla/installer/installer.php

As you can see JFolder::files is told to search recursive through all subdirectories.
I guess it's the same function that is also used on install and some extensions still don't put their manifest files into the root folder of the zipfile.

What joomla version are you using? I tested it on 2.5.8 and 3.0.(not sure) and I never get this error?

It is true that the JFolder::files will get all the xml files in the package, but it will also stop on the first one (look at the foreach). And the first one is in the main directory.

Just curious why this happens to you and not to me

Cheers,
Daniel

I tested it with both versions 2.5.8 and 3.0.2.
In my case the first one was from the /assets/ directory.

Looking at JFolder::files() it uses readdir() to get the files in the directory, and it

Returns the name of the next entry in the directory. The entries are returned in the order in which they are stored by the filesystem.

So it seems to depend in which order the files were created when the extension was installed. And this maybe depends on the PHP version or whatever?

I just tested it using Joomla 3.0.2 on a XAMPP server (Apache 2.4.3 on Windows 7 with PHP 5.4.7) and on a Linux server (Apache 2.2.21 on OpenSUSE with PHP 5.3.8 ). Both produced this error.

Btw: I used the package from your download section, maybe you use another zipfile to install?

That is interesting. I just tested it on MS webmatrix and it installs fine there as well.
I'm just really curious why it happens to you and not to me

Regards,
Daniel

It's indeed interesting.

Just tried on another (productive) server: PHP 5.3.8 (running with fcgi) on a shared Linux server with Joomla 2.5.8. Happens as well.

What I do (just for reference)

1. Download file from compojoom.com/downloads/official-release...sifex/ctransifex-1-1 to PC
2. Install it from PC using the extension manager
3. Uninstall again using extension manager
4. Install again -> Error message

This WebMatrix thing looks interesting, didn't know this.
But I also get the error there, using Joomla 2.5.8 on MS IIS/8.0 and PHP 5.3.19 (fcgi).

Ok, I managed to reproduce this on 2.5.8

On 3.0 I get an sql error "something with assets" then when I repeat the installation it installs fine.

Funny why it happens on second installation and not on first one.

Daniel Dimitrov wrote: Funny why it happens on second installation and not on first one.

That's because the problem is withing the uninstall (doesn't delete the #__assets entry). The install works fine