While Gallery2 is still very very much alive and kicking, this extension is dead.

The support forums, a long list of postings pleading for help... Unanswered.

The required JoomlaLib 1.3.0 and the link to it lead to a wiki... It contains a set of links to modules which in turn return "File Not Found."

No mention of JoomlaLib 1.3.0 as a descrete entity, but a dozen different listings, all of which seem to address seperate specializations of the code library... all abandoned.

The roadmap for the dev wiki shows the project also to be a forgotten dream, and without this particular addition, the extension won't run.

The extension requires and depends upon an additional developer for code and both the extension developer and the developer of the library it requires have fallen from the face of the Earth.
No point in this extension being listed if the developers aren't supporting it and the required bits and pieces can't be downloaded.

This seems to be excellently well written. Installs clean, uninstalls clean. It has a nice appearance and displays well IF you have shell access, or a flexible host administrator. For those who are unable to modify php.ini, even if the system meets all other requirements, this seems to be a non-player, and support will be non-existent. It isn't that they don't have an active forum... They just won't be bothered with you.

If you have trouble, uninstall it. If you ask for help you will be sent a link to basic php information or you will be told to RTFM. Your request will be answered promptly though...

For those who do not have control over their php installation, who don't wish to return to school in order to use an image gallery, or simply don't understand the instructions, use anything else.

This extension COULD use image upload methods more consistent with other Joomla extensions. With this extension, you will do it the way the author set it up or not at all. No support.

The instructions indicate that a "bucket" folder may be used to ftp upload and then the images may be published from there. No bucket folder in the indicated directory and no way to create one... The extension interferes with ftp authentication for the extension directory and you might not be able to either create the folder or upload to it...

A convenient set of system checks is provided... Your system may seem to pass the checks and still fail to use this extension. Asking in the forum will return stock replies.

This extension can interfere with the ability to control CHMOD permissions and FTP authentication for the directory.
Anything beyond that suddenly became a non-issue.

Kudos:
a great extension. It installed easily and quickly. It's full featured, yet fairly simple to set up. The directions were well written and anyone who can follow the directions to microwave a burrito can have this set up in a reasonable period of time. This allows for very professional presentation of location, as well as allowing multiple locations to be displayed as markers... Perfect for small organizations, a chain of local stores, venue location for events as menu items, affiliated businesses or organizations...

Issues: (almost too trivial to mention)
The ad banner in the component CP jumps when mousing toward the buttons.
The geolocation marker which on Google's own site pop's up a dialog for "From/To" address and an input textbox doesn't do so in this extension. I know this can be made to interact correctly because the Joomlicious contacts page image hack does this correctly... It is a much simpler tool than this and lacks tons of features that this extension provides.

This module does work, but required a little detective work to figure out why it didn't at first.

In as much as the author support is entirely in Russian, and no real support is available in English. I hope the moderator will make exception for a little support suggestion here because this module can be made to behave even in those cases where it initially locks the user out of the administration backend. It should either be supported for the user community or removed from listing as unsupported/undocumented, but it is not as erratic as it appears to be for usability. It is very very simple and requires exact format requirement for the IP address or range.

It is a valuable addition, with a few caveats. Undertanding why it may not behave should be better stated. I'd hate to see this unique tool removed simply because it is poorly documented, but one can't RTFM if you don't read Russian.

I originally entered the allowed IP range in wildcard notation. Access failed on relog.

I momentarily renamed the .php and .xml files long enough to log back into the back end after it failed. I changed the names of the files back. I changed the entry to the exact IP rather than a wildcard range and I logged out and then back in and it worked fine.

On examination of the php file it will also accept ranges in Netblock Notation (Cisco). It will not accept IP Mask Notation. It will not accept wildcard notation (192.168.*.*) It has a very simple but effective RegExp filter built into the input stage and it will accept ONLY valid netblock notation.

192.168.128.0/17 etc... will define a valid range format for people who access their server remotely from dynamic IP lease addresses... Non-overlapping ranges can be added, seperated by commas.

I would be certain to add any ranges your ISP is likely to use especially if they are upgrading hardware regularly. At the very least keep a note of this problem in your notes. Your IP lease could change in several months and leave you scratching your head as to why you can't get back in. Fixing it takes about 1-2 minutes.

As the name implies, this extension blocks access to unauthorized access to joomlaroot/administration/index2.php by IP.
It is not a backend tool for blocking frontend access.

This extension at first blush looked very promising. There was a freeware version that allowed me to get a good feel for it and it seemed fully featured.

It was upon my attempting to purchase their commercial product, which is a trivial cost, that I realized that being on the user end of their cart was clumsy, and a little annoying. It has subtle but serious issues in real world application.

One issue; the Required fields in the payment form made no sense, and some of the elective fields should not have even been displayed. The required fields should be under the control of the shop owner, especially as questions such as requiring Gender, is totally unnecessary for validating a transaction and could be offensive to some customers. I found this question specifically posted on the support forums, with no validation or reply from the developers, and no solutions offered by the community.

A similar issue; the display of inappropriate elective fields in the form. Joomla is all about dynamic content. If a form field would be totally inapproriate, I would prefer that my shopping cart not make me look the fool for asking.
This became apparent with the Tax ID field. There is no appropriate reason for a company in South Africa, to even ask for that information of a company in Cincinnati, Ohio.

The user form DEFAULTS to South African Rand as the currency... When the user is clearly not going to be accustomed to transacting anything but $US. Again, an issue of dynamic content not being properly implimented.

The selection of products to be added to the catalog, did not allow for selecting multiple unique items, and then adding them all to the cart at once. I had to wade through 3 screens, for each of 3 items before I could add the three softwares I wished to buy to the cart. Two of the pages I had to wade through were essentially identical in content. It was a wasted extra step between the customer and the purchase. I had to waste this extra step three times, which I would not expect a customer to tolerate. This is pure poison to capturing an impulse purchase. By the time a customer finished shopping, they would have been overcome by their better reason as well as tangible eneue.

The form suggested that they needed a physical address "for invoicing purposes." While a physical address is a perfectly legitimate field for validating a transaction or arranging carriage, neither makes sense for digital content. I expect my receipt/invoice for digital content to be delivered by email within a very few minutes of the transaction. While I'm almost positive that the shopping cart will actually do this, I do not wish to have my shopping cart software commit this faux pas, suggesting that it will be snail mailed. At the very least this demonstrates poor attention to detail for the representation of his own SC site.

Phone number as a required field...
Someone is going to call Ohio, from South Africa...?
At this point I would EXPECT a customer to become a little uneasy and feel that the question as a REQUIRED field was little more than data mining. In the current atmosphere of internet shopping paranoia about the sensitivity of private information, I expect to be able to set up my shopping cart to request sensible and reasonable required data fields that do not alarm my own customers. I would expect to lose at least 5% of my potential sales at this point just from "Shopper Anxiety."

Payment Gateway... They allow only one. I consider this extremely poor form in as much as I would have appreciated being able to use Paypal or at least be offered the option.
If this is a problem for the author of the extension, why should I believe this is not going to be an issue for me?
This is just one of those circumstances where I would expect the seller to demonstrate their own product in use of this feature. Several postings in the forums indicate that the software "drops the ball" on orders using Paypal and that orders must be manually completed. The forum also claims the issue to be addressed. The implimentation should be evident on the author's own SC site if for no other reason than as a demonstration of the feature at work in a live site.

I'm certain that this is a functional software. I set it up and fed it dummy data for a week to confirm this for myself, but function is only part of what I require. I also require that the software represent me with finesse in the same manner that I would represent myself if I were speaking to a customer on the phone or in person. This extension does not appear to allow the seller to do this without becoming an unwitting member of the developement team.

The seller's own shopping cart demonstrated to me that one of two things is true. Either the software is truly inflexible, or the seller did not take the time to set his own site up to take advantage of Joomla's dynamic nature. Either the software is a poor representation of the seller, or the seller has represented it's facility poorly. Neither scenerio is acceptable for any site I would want to build. Though the software is fuctional, and indeed very nicely featured.

This extension also commits what is in my opinion is the ultimate cardial sin. When uninstalled it failed to uninstall cleanly. I consider this extension a strong but immature software. There are basic issues that would need to be addressed (for which no real answers exist for longstanding questions in their own forums) before I would consider this ready to install on a live site.

I was left with the impression that I was being asked to buy something that the author himself could not demonstrate in action. Bloody poor show. My alternative would have been to spend a large amount of time figuring out which of these are serious issues and which have solutions which are accessible. I have a desire to impliment, not develope, a solution. I was able to find no real assurance that this was the case.

Respect and facility in a digital storefront are almost as important as search rank. The software can be as functional as it is, and still be undesirable as a real world solution.

It uninstalls... Yeah!!!

Support is in German. The forge home page indicates that there hasn't been much done with this for a while. A shame...
The installation requires only the modest attention one would give to a cookie recipe. Very clean, very easy IF you folow the directions. It uninstalls cleanly.

The display in CP doesn't seem to display any actual traffic. I tested the log against artificially generated traffic and nothing showed up. In addition two new members registered on the shopping cart while this was happening. They showed up in user manager, but nothing in the IP log.

A nice looking tool. I hope the author gives it another look soon and updates it. I would really like something like this. I would be willinbg to bet the problem is a simple one. Either a documentation problem, or some small bug in the logging code.