Login
Free Joomla Template by HostMonster Reviews

Hikashop Product Display Issue

Google Chrome does not display Hikashop Product Display pages on the first pass.  A refresh is required to get the page to show correctly.  Admin Tools software CSS and JS combining feature would cause Google Chrome to not obtain the css document on first pull.

This is fixed by disabling Browser Caching in System - Cache.

enable right click on images

May be somethink like:

Galleria.ready(function(){
    this.bind(\'image\',function(e){
        $(e.imageTarget).bind(\'contextmenu\',function(f){
            f.preventDefault();
            return false;
        });
    });
});

It disables right click options.

How to extract and restore a Joomla .jpa archive or backup?

How to extract and restore a Joomla .jpa archive or backup?

Upload your .jpa archive in public_html through your FTP client:

http://www.siteground.com/tutorials/ftp/ftp_client.htm

Download the Akeeba Kickstart script from:

https://www.akeebabackup.com/download/official/akeeba-kickstart.html

Upload the kickstart zip archive again in public_html or in the same folder where the you have the .jpa archive. Extract the content of the archive. This will put multiple files in the same folder. The listing will be similar to the following one:

da-DK.kickstart.ini
de-DE.kickstart.ini
el-GR.kickstart.ini
en-GB.kickstart.ini
es-ES.kickstart.ini
fr-FR.kickstart.ini
it-IT.kickstart.ini
kickstart.php
nb-NO.kickstart.ini
nl-NL.kickstart.ini
pt-BR.kickstart.ini
ru-RU.kickstart.ini
sv-SE.kickstart.ini
tr-TR.kickstart.ini
uk-UA.kickstart.ini
zh-CN.kickstart.ini

Access the kickstart.php script via your domain and browser. For example:

http://yourdomain.com/kickstart.php

If you load the web site from a subfolder (http://yourdomain.com/subfolder/) and you have uploaded there the files mentioned above (public_html/subfolder)  use the following link:

http://yourdomain.com/subfolder/kickstart.php

A notification window with the \"Things you should know about Akeeba Kickstart\" title will be open. You can safely close it by clicking on:

\"Click here or press ESC to close this message\"

After it is closed, comes the real restoration part.

1. Select the .jpa archive file you want to restore from the drop down list. In the second field supply the password if the archive has been password protected.

2. Write to files – Directly

3. Fine tune – these settings can be used to bypass the timeout settings of your host. For example, if you try to extract larger .jpa archive on a shared server, this will probably exceed the timeout settings and will cause the restoration to fail. Leave the settings as they are by default during the first attempt and play with them if it fails.

4. Hit the big green \"Start\" button to start the restore.

Another window will show up with a progress bar indicating the status of the restore. When it completes successfully, another big green button will appear. Its name is \"Run the Installer\". Click on it and then click \"Next\". If you restore a backup created on one host to another you might need to adjust the database settings at that step. At the DB restore step you should provide an empty database with a user permitted to access it. Except the database login settings, you can leave the rest of the settings in the DB restore section unchanged. If you restore on the same server where the backup has been created, the database settings will be the same and you should skip this step.

Click on the \"Next\" button to proceed. This will spawn another progress bar. Allow it to finish and click \"OK\". This will lead you to the \"Site Info\" section. Do not touch anything if you restore on the same server. If you restore to another, the only required change you should do is to check the box besides the \"Override tmp and log paths. Use the directories under your new site’s root\" label. Click \"Next\" again to reach the last step where the installation directory from the Joomla root folder should be deleted.

After the installation directory is deleted, you can access your Joomla front and back ends.

disable right mouse click code into galeria.ready

Anywhere inside < script > tag in your page.
For example

Galleria.loadTheme....
Galleria.ready.....

You could be interested also in disabling \"drag and drop\" possibility.
http://jsfiddle.net/ECftV/
(Alerts there are just for fun, you can remove that lines)

Example above disables this only on main images.
You can do it for all gallery

$(\'#galleria\').bind(\'contextmenu\',function(e){return false;}).bind(\'dragstart\',function(e){return false;});

or only for images inside gallery

$(\"#galleria img\").live(\'contextmenu\', function(e){return false;}).live(\'dragstart\',function(e){return false;});

jQuery in Joomla: I was wrong

For quite some time now, it’s been no secret that I’m a fan of jQuery and prefer it to MooTools for JavaScript development. However, Joomla ships with MooTools as the preferred JavaScript framework. Both jQuery and MooTools like using $ as a shortcut method name, which can cause conflicts. Fortunately, both frameworks have ways of disabling this shortcut so that you can use them side by side.

Unfortunately, if you’re not paying attention to the ordering of the JavaScripts, you can end up loading both before you have a chance of sending one into “no conflicts” mode. For quite some time now, I’ve advised fellow Joomla developers to always load MooTools first. It turns out that this advice is not correct, and can cause you to load up MooTools when you’re not even going to use it.

So I’d like to explain why I came to this conclusion in the first place, the correct way of avoiding the problem, and a call to solve this centrally so that people don’t have six copies of jQuery loading on their websites.

The real issue

The core issue has to do with the way JDocument adds JavaScript to the HTML document. As you call JDocument::addScript(), JDocument makes an internal list of all the JavaScript files it needs to load. Also, calling JHTML::_(‘behavior.mootools’) adds the MooTools framework to this list. You can also pass JavaScript in a string to be added directly in <script> tags through the JDocument::addScriptDeclaration() method. With these methods in mind, you would assume that you could add jQuery via JDocument::addScript() and the JavaScript snippet ‘jQuery.noConflict()’ through JDocument::addScriptDeclaration(), like this:

$document = JFactory::getDocument();
$document->addScript(\'path/to/jquery.js\');
$document->addScriptDeclaration(\'jQuery.noConflict()\');

This sometimes works. However, if (for instance) your module used jQuery and the next one used MooTools, you’d run into a conflict even though you had $document->addScriptDeclaration(‘jQuery.noConflict()’) in your code. The advice passed around by myself and the Joomla community was to do this in your code:

JHTML::_(\'behavior.mootools\');
$document = JFactory::getDocument();
$document->addScript(\'path/to/jquery.js\');
$document->addScriptDeclaration(\'jQuery.noConflict()\');

This ensured that MooTools got loaded first and that the conflict would not happen. This also forced MooTools onto the page regardless of whether or not it was being used. It turns out this approach doesn’t really address the real problem: Joomla loads all of your external scripts first, then loads all of your script declarations. So for instance, the following code snippets result in the same script ordering as the previous sample:

$document = JFactory::getDocument();
$document->addScriptDeclaration(\'jQuery.noConflict()\');
JHTML::_(\'behavior.mootools\');
$document->addScript(\'path/to/jquery.js\');
$document = JFactory::getDocument();
JHTML::_(\'behavior.mootools\');
$document->addScriptDeclaration(\'jQuery.noConflict()\');
$document->addScript(\'path/to/jquery.js\');

The fix

To genuinely solve the problem and not worry about MooTools, you need to first create a JavaScript file with the code jQuery.noConflict();. Then you need to load jQuery, then load the file containing the jQuery.noConflict(); code. Your code in Joomla would look like this:

$document = JFactory::getDocument();
$document->addScript(\'path/to/jquery.js\');
$document->addScript(\'path/to/jquery.noconflict.js\');

In this example, jquery.noconflict.js contains the following code:

jQuery.noConflict();

By doing this, it’s guaranteed that jQuery.noConflict() will get called immediately after jQuery is loaded by the browser. To recap, the ordering of MooTools and jQuery does not matter if you make sure jQuery.noConflict() is called immediately after jQuery is loaded. After you send jQuery into noConflict mode, you still must either use jQuery() instead of $(), or use one of the referencing methods described here in your jQuery-powered code.

But wait, I still have a thousand extensions all loading jQuery!

Ideally, each Joomla site should be loading either zero or one copies of jQuery. Having multiple copies of jQuery sitting around Joomla puts site owners in the position of having to manage conflicts. Also, distributing multiple copies of jQuery discourages the use ofGoogle’s JavaScript library CDN. We don’t want to foist this problem onto site administrators; they just want all of their extensions to work.

Fortunately, there’s an effort underway to standardize and document the use of jQuery in Joomla. If you’re willing to help out, join our Joomla People Group jump into the discussion. We should be able to document a way for extension developers to bundle a jQuery plugin with their extensions, as well as avoid version conflicts. Ultimately, a copy of jQuery should be installed and updated as necessary without the intervention of site administrators.