[Michael Gilkes]

@benoit.lallemand. Thanks for posting. That is quite interesting! Now that I think about it, I understand why it is happening. The index to uniquely identify the listing is locally set for each article. So, it starts a zero for every article. If you have multiple articles, you will end up with duplicate ids for the listings.

To circumvent this, I would have to add an “offset id” parameter for the listing instance, which would offset the id by a certain amount in a particular article. I will have to add that for the next release.

[Michael Gilkes]

@jgbi. Thanks for your contribution. That is quite an interesting code snippet. Looks good.

Basically, for those who didn’t understand what you did, by setting root to true, you are telling the plugin to use JURI::root instead of JURI::base to create the full path to files.

[Michael Gilkes]

@agussol. Thanks for posting. I have been meaning to put this as an FAQ item. Here’s the explanation of what is happening:

It seems as though the problem is that IE9 is incompatible with mootools versions 1.1 and 1.2 (up to 1.2.4). If you click F12 and select “Console”, then refresh the page with the listing, you will see the following error come up: “SCRIPT5022: DOM Exception: INVALID_CHARACTER_ERR (5) mootools.js, line 1 character 21432”

Here is a discussion about the problem: http://mootools-users.660466.n2.nabble.com/Moo-mootools-and-ie9-some-relavant-bug-td6172026.html

Here is a possible solution: http://www.youjoomla.com/joomla-1.5-moo-1.2.4-and-ie9-bug-fix.html

So, the problem is not with my plugin, as you can see from the error itself and the same problem that others have experienced. Maybe you should consider to upgrade to Joomla 2.5 soon, since Joomla 1.5 will reach the end of its life in April 2012. However, if you want to stay with Joomla 1.5, you should upgrade to the latest minor release, 1.5.25, which provides Mootools version 1.2.5 (which I believe should work).

Anyways, I hope my analysis can help you.

[Michael Gilkes]

@megat. There is no lite version of the Easy Folder Listing Module. Version 2.0 of the module does this. You specify the drop down of the a non-system folder in the root directory, then you specify the subfolder in that.

[Michael Gilkes]

@hummina. Thanks for contacting me via email. i checked out your site, and identified the problem as the WYSIWYG editor adding extra tags to your text in the article. See the following screenshots. One is the one you sent, and the other is the same screenshot but I clicked on “Toggle Editor”:

Yours: http://imageshack.us/photo/my-images/853/easyfolderhummina.png/

Toggle Editor Clicked: http://imageshack.us/photo/my-images/194/humminatoggleeditor.png/

[Michael Gilkes]

@hummina. Thanks for posting. It seems as though you adjusted the text to suit the case of the folders’ names. You have changed it from:

{easyfolderlistingpro folder=’docs/publicdocs’}

to

{easyfolderlistingpro folder=’docs/PublicDocs’}

It should work now. Let me know. If it doesn’t work, send me an email with a link to the page, and create a temporary admin account for me to access it in the backend. If you are not comfortable with that, I will try to work with you via email, but this is the quickest way.

[Michael Gilkes]

@hummina. Thanks for posting.

From the error message that Joomla lists, it seems that the path ‘docs/publicdocs’ does not exist. One thing to keep in mind is that web servers are typically case-sensitive. So, for example, if the folders are actually named “Doc” and “PublicDocs”, then specifying “doc/publicdocs” will not work. You will have to specify “Doc/PublicDocs”. This actually happened to another user of the plugin.

Now, make sure that your docs folder is in the root of the Joomla installation. If you are still having trouble, please post a link to the webpage.

[Michael Gilkes]

@mjriding. Thanks for posting. Actually, I haven’t really tried this, to be honest. So, although I made the plugin, I can’t help you on extending it to be part of a form. At the heart for the Easy Flash Uploader plugin is SWFUpoad 2.2.0.1. Your best bet on improving it is to start looking at the documentation and demos.

From my recollection (and I could be mistaken), although SWFUpload can be part of a form with other fields, the uploader will still upload separately from the other form fields submission. However, don’t quote me on this.

I am sorry that I can’t be of more help to you. If more people want this feature, and are able to articulate how they expect the uploader to work as part of a form with other fields, I will gladly look into improving it, or even making a multi-form alternative to this plugin.

[Michael Gilkes]

@mjriding. Thanks for posting.

Have you checked the FAQ? If not, please have a look at the FAQ for this particular problem on Windows: https://www.valorapps.com/faq.html?catid=3

For Windows, you have to install the fileinfo dll. If this doesn’t work for you, then you can specify an asterisk in the mime type field and use the file extension types to control the files uploaded.

As a matter of follow-up, in @frawoer’s case, his server OS was SunOS, so he needed a custom solution.

Let me know if the FAQ item helped.

[Michael Gilkes]

@li_gordon. Thanks for posting. You may send me an email explaining what you have in mind. Email me at: michael[at]valorapps[dot]com

There is a contact us link at the bottom of the Valor Apps website.

[Michael Gilkes]

@KingCobra. Awesome! Thanks for responding and sharing the result with everyone. Usually, most of the javascript errors stems from jQuery conflicting with Mootools (especially the older versions of jQuery).

Mootools is really a mature and good Javascript framework. I first learned jQuery, thinking it would be easy, but coming from a programming/Computer Science background, when I used Mootools, I felt more at home. Mootools can do everything jQuery can do, and it would be good if developers stuck with Mootools, since it is the the javascript framework that Joomla supports natively. That is why I changed all my jQuery code to Mootools.

[Michael Gilkes]

@KingCobra. Thanks for posting. Have you checked your browser’s console? You should have a look a the console.

Looking at my console, I see the following:

TypeError: ‘undefined’ is not a function (evaluating ‘$(document.body).adopt(this.overlay, this.window)’) modal.js:112

This could mean that you need to update your modal.js file. However, from my experience, I think the problem is that you have jQuery 1.4.4 on the page (loaded by scriptegrator), and it is conflicting with the Mootools modal (SqueezeBox) code. Either (1) update your jQuery to the latest version (1.7), or (2) Remove jQuery all together.

[Michael Gilkes]

@aignashev. Thanks for posting.

This is a known issue. It is stated clearly on the product page (look in the ‘Known Issues’ section): Easy Folder Listing Pro

This is uniquely tied to the Javascript and Mootools. It seems that the webkit based browsers (Chrome and Safari) add spaces between the rows every time you hide and show a row. It shows perfectly in Firefox, Opera, and IE9.

[Michael Gilkes]

@Fredd13. Thanks for posting. I had a look at your site. Then, I decided to test out your claim that the sorting isn’t working. So, I downloaded all your files and placed them on my server, and tested each mode in the plugin. The sorting works perfectly for me. Here are the links to show you what I found:

• List – Name – Ascending
• List – Name – Descending
• List – Size – Ascending
• List – Size – Descending
• List – Date – Ascending
• List – Date – Descending

So, if I have tested it with your files, and everything works, then how is it that yours does not? Did you edit the plugin’s code? Let me know if you made any changes.

I also tested the the settings in Joomla 1.5. Everything seems to work, as you can see from my screenshots.

I don’t know what to tell you considering that your own files are sorted perfectly with the plugin when I try it. I don’t know if the charset encoding on your server file system affects the sorting. That is just speculation on my part.

[Michael Gilkes]

@agileox. Thanks for posting. From your description, the module, as well as ACL on the module, works as expected.

The question is what do you want to restrict access on?

1. If you restrict access on the module, the module will only show for the user group that it was restricted to.

2. If you restrict access on an article (that contains the module), the article will only show for the user group that it was restricted to.

Let’s say the access level for the Module is set to “Registered” and and the access level for the article that contains the module is set to “Public”, then any user can see the article, but only registered users will see the module on the article page. Public users will not see the module on the article page. They will only see Public content. From what you explain, this is what you have set up.

On the other hand, if you set the access level for the Module to “Registered” and you also set the access level for the article to “Registered”, then only registered users will see the article with the module. Public, or guest, users won’t even see the article link at all.

This is how Joomla works. It isn’t unique to my modules. Hope this helps. If you need any further clarification, let me know.

[Author]

Posts