Feature Requests on Uservoice

• 
• 

Details

Published on Friday, 26 October 2012 15:20

Since a few years already we use Uservoice where you can add feature requests and vote for them:

http://joomgallery.uservoice.com

We would like to mention again that we want to manage feature requests only on that platform because in our forum they disappear very fast. Besides that, it is possible to identify easily on Uservoice which features are required more than others. This way we can concentrate on important features first.

So, please don't post your feature requests in our forum anymore, but use solely Uservoice for that.

Additionally we would like to define some rules here which should simplify understanding of the features for you and us:

1. Feature requests must have a clear and understandable title.
2. Please use the big field for an extensive description of your feature request with which people can understand the use cases.
3. Create one entry for each request and don't put more than one in a single entry.
4. Please use the integrated search before posting a new feature and don't create duplicates (for that you may have to use different keywords for your search).
5. Entries must be written in English language (or German).
6. Uservoice is used only for feature requests. Please use our forum for bugs and support questions.
7. Of course no spam or something like that is allowed.

If one entry breaks one or more of these rules it will be removed. We hope to preserve clearness this way.

We are anxious to implement the features with the highest number of votes, but we reserve to postpone entries if they are difficult to realize with the current software architecture of the gallery. However, as long as a feature request is not declined or removed you can be sure that it is still considered for inclusion. We are just waiting for an opportunity (e.g. if other things have to be realized afore as preparations).

New features are basically only included into the JoomGallery version with the highest currently existing Main Release Number (cf. our Versioning). Simultaneously, we are supporting a JoomGallery version with smaller Main Release Number, but this one gets just bug fixes once a version with higher main release number was published.

Community Builder Tab at Github

• 
• 

Details

Published on Friday, 28 September 2012 09:39

Since we have concentrated very much on adding new features to JoomGallery, there was no time for developing and improving Community Builder Tab of JoomGallery, unfortunately. Now, we are starting to make JoomGallery ready for Joomla! 3 and so there still won't be any time for CB tab. Therefore, we decided to move the code of the tab to Github, so that people with more knowledge about Community Builder or other volunteers can contribute easily to the code.

On Github you can fork the repository of the tab with one click and start adding fixes or new features. After that you are able to send a pull request with your changes so that they can be reviewed and merged into the master branch. This way you are able to contribute back to the community and realize your own feature requests!

It would be very cool if you become part of that and fork the tab here:

https://github.com/JoomGallery/jg-cb-tab

This way the Community Builder tab will be built by the community :-)

If you have any questions about JoomGallery compatibility and other things, please feel free to open an issue at the repository on Github. We will try to solve all problems together with you so that the tab integrates perfectly into Community Builder and JoomGallery.

Problem with certain system plugins

• 
• 

Details

Published on Friday, 03 February 2012 10:40

While developing and supporting JoomGallery 1.5.5 we detected a problem which is related to very many third party system plugins.

In our opinion, these plugins don't respect a certain attribute of Joomla by what problems may occur if the site uses search engine friendly URLs.

We want to explain this correlation here and ask the developers of these plugins to check their code concerning this matter and to fix it where appropriate.

For illustration we will have to go into greater detail: As probably known by many developers there are four system plugin events in Joomla at the moment which are triggered in the following order: 'onAfterInitialise', 'onAfterRoute', 'onAfterDispatch' and 'onAfterRender'.

In the following primarily the events 'onAfterInitialise' and 'onAfterRoute' are important as well as a core parameter of Joomla called 'format'. This parameter, which usually is delivered within a URL, determines which document type (see $document->getType()) of Joomla shall be rendered. By default, this is 'html', thus an ordinary HTML page. Because of that 'format' isn't usually delivered for HTML pages (the default value 'html' is used then).
Other possible values are 'error', 'feed', 'pdf' and 'raw' (they match with the sub-directory names of folder 'libraries/joomla/document'). For example, if you want to create a PDF file and output it you will have to use 'format=pdf' explicitly in the URL so that Joomla renders this document type automatically.

The actual problem can only occur if search engine friendly URLs are enabled in Joomla (it doesn't matter whether it's the Joomla Core SEF or a third party SEF component). Since 'format' isn't explicitly in the URL anymore now (but implicitly in the SEF URL), Joomla isn't able to "know" that another document type than 'html' is requested until event 'onAfterRoute': Only now the SEF URL was parsed and 'format' is available explicitly again.

However, this alone still isn't responsible for the actual problem. That one occurs not until a system plugin is installed and enabled which fulfils the following conditions:

• It uses the event 'onAfterInitialise' or the constructor.
• In at least one of these, it calls the document library of Joomla.
  This may happen directly with:

  $document =& JFactory::getDocument();

  or also indirectly with e.g.:

  $mainframe->addCustomHeadTag($html);

If these conditions are fulfilled (which happens with very many system plugins unfortunately), 'JDocument' is loaded before 'format' is known explicitly to the system.

Thus the line

$instance->setType($ntype);

of function 'getInstance()' in file 'libraries/joomla/document/document.php' irrevocably determines the document type of the current request with 'html' (this cannot be changed later on)!

An extension which requests another document type (e.g. JoomGallery requires 'format=raw' for displaying a single image) cannot work correctly anymore with that.

Conclusion

Since 'format=html' is determined afore it's sure that definitly 'html' is requested because of these certain system plugins we think that these plugins are responsible for the problem.

Plugins which want to change the HTML output of a page shouldn't do that until it's definitly sure that an HTML page is actually requested. This is the case at event 'onAfterRoute' at the earliest.

We hope that many developers among you read this text und try to rewrite the plugins which call 'JDocument' in order to let them only use the events 'onAfterRoute', 'onAfterDispatch' and 'onAfterRender'. Tests on our site have shown that this is mostly practicable without much effort.

Thank you for reading this very theoretical text!