cloudinary / cloudinary_magento

Cloudinary's Magento extension. Upload product images to the cloud, manipulate them to match your graphic design and optimize images for better user experience

Magento 1 Cloudinary Module

Magento 1 module for integration with Cloudinary.

---

Install From Magento Admin (Using Magento Connect Manager)

1. Log into your Magento admin panel & navigate to System > Magento Connect > Magento Connect Manager.
2. Under "Direct package file upload", upload the package file that's included in this repository (var/connect/Cloudinary_Cloudinary-*.tgz).
3. Install the package...

Install Manually

1. Download & copy/drag the directories app, lib & skin into your Magento 1 root dir.
2. Clear cache from Magento admin panel or by running rm -rf var/cache/* var/full_page_cache/* under your Magento 1 root dir.

Install Using Modman

1. If you don't have modman installed, install it first according to the official instructions & then follow the instructions for Magento users.
2. cd into your Magento 1 root dir & run modman init (in case you haven't done it already).
3. Under your Magento 1 root dir, run modman clone Cloudinary_Cloudinary https://github.com/cloudinary/cloudinary_magento
4. Clear cache from Magento admin panel or by running rm -rf var/cache/* var/full_page_cache/* under your Magento 1 root dir.

Update Using Modman

1. Under your Magento 1 root dir, run modman update Cloudinary_Cloudinary
2. Clear cache from Magento admin panel or by running rm -rf var/cache/* var/full_page_cache/* under your Magento 1 root dir.

---

https://www.cloudinary.com/

Copyright © 2018 Cloudinary. All rights reserved.

cloudinary_magento's Issues

Automatic DPR detection not working

Hi
when configuring the option "Image Device Pixel Ratio (DPR)" to "2.0" all images will be generated twice there original size, whether the browser is retina or not
According to cloudinary documentation, lazyloading has to be added to automatically deliver the best quality
$.cloudinary.responsive();
https://cloudinary.com/blog/how_to_automatically_adapt_website_images_to_retina_and_hidpi_devices

Data reset in after_save observer

We enable everyday some products with a cronjob that changed the status of product
We noticed that url-rewriting are no more generated in the product save() function
after debuging the problem come from the observer of cloudinary and exactly from this line

cloudinary_magento/app/code/community/Cloudinary/Cloudinary/Model/Catalog/Product/Media.php

Line 26 in 4d7cc09

$product->load('media_gallery');

It reload the product default data, so the product is no more considered with changed data, and the default magento function "refreshProductRewrite" will no more reindex
when removing this line all work fine

Change Preference for Plugin for class: Magento\Widget\Model\Template\Filter

In this module exists a preference of Magento\Widget\Model\Template\Filter to overwrite a method: mediaDirective.

Since this method exists in core, it is advisable to use Magento 2 plugin instead of using preference.

about INSTALL.md and composer

Hi i am a bit confuse,

Is this package the same repo,
"connect20/Cloudinary_Cloudinary": "1.1.0"

If it is can be nice to change it in the install.md,

Thanks,

Non existant classes

When I am running:

setup:di:compile

I am getting this:

Class Cloudinary\Api does not exist

And in Admin if I try to save config I am getting that Cloudinary class is not defined, and it is used in:

/app/code/Cloudinary/Cloudinary/Core/Security/CloudinaryEnvironmentVariable.php

Am I missing some library or what is it?

I am having Magento2 Commerce Cloud solution.

M1 Indexing Issue

Has anyone else experienced an issue with re-indexing from the command line with this extension? I just switched a Magento 1.9.3.9 store to Cloudinary and after installing the latest extension version our reindex job is failing with the following error:

PHP Fatal error:  Interface 'CloudinaryExtension\ConfigurationInterface' not found in app/code/community/Cloudinary/Cloudinary/Model/Configuration.php on line 16

The extension is otherwise working just fine. Issue with the autoloader when running via the cli maybe?

Warning: The use statement with non-compound name 'Cloudinary' has no effect...

... in /var/www/htdocs/.modman/cloudinary_magento/app/code/community/Cloudinary/Cloudinary/Model/System/Config/Credentials.php on line 4

Encountered using PHP 7.2.11.

MySQL index on cloudinary_synchronisation table

When tracing PHP processes to asses performance overhead, I came across these queries when loading a category page:

16:20:35.668544 write(5, "\211\0\0\0\3SELECT `cloudinary_synchronisation`.* FROM `cloudinary_synchronisation` WHERE (`cloudinary_synchronisation`.`image_name`='hde007_3.jpg')", 141) = 141
16:20:35.672296 write(5, "\211\0\0\0\3SELECT `cloudinary_synchronisation`.* FROM `cloudinary_synchronisation` WHERE (`cloudinary_synchronisation`.`image_name`='hde007_2.jpg')", 141) = 141
16:20:35.674254 write(5, "\211\0\0\0\3SELECT `cloudinary_synchronisation`.* FROM `cloudinary_synchronisation` WHERE (`cloudinary_synchronisation`.`image_name`='hde007_2.jpg')", 141) = 141

... About 50 of those, one per product image in this category I guess. It's not terrible but did add about 0.2 seconds to my page load (not from full page cache).

mysql> EXPLAIN SELECT cloudinary_synchronisation.* FROM cloudinary_synchronisation WHERE (cloudinary_synchronisation.image_name='hde007_2.jpg');
+----+-------------+----------------------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table                      | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+----------------------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | cloudinary_synchronisation | ALL  | NULL          | NULL | NULL    | NULL | 1242 | Using where |
+----+-------------+----------------------------+------+---------------+------+---------+------+------+-------------+

It would be good not to trouble the database at all, but we should at least be using an index for these queries. The sample data doesn't have a of images, but the MySQL CPU overhead of this unindexed WHERE is going to start adding up for larger catalogues. Query cache should mostly mitigate this, but there will be cases where query cache is disabled or invalidated for this table, any time it changes.

For now, I'd suggest adding an index on the image_name field when the table is created.

I'll send a pull request on: src/app/code/community/Cloudinary/Cloudinary/sql/cloudinary_setup/install-0.1.0.php

Cheers,

Will.

"Unable to set target directory" Backend Error

Hello, when installing the extension everything goes fine, however when I first tried to access the Cloudinary > Manage panel in the backend main menu, I get the error "Unable to set target directory" and the first stack trace line:

/ var/www/dev1/htdocs/app/code/community/Cloudinary/Cloudinary/Model/Resource/Cms/Synchronisation/Collection.php(12): Varien_Data_Collection_Filesystem->addTargetDir('/var/www/dev1/htdocs/media/wysiwyg/')

I investigated and found that the media/wysiwyg/ directory did not exist on my fresh install of Magento 1.9.2.1. After creating the directory manually, the issue is resolved and the Cloudinary extension appears to function as expected.

I do not know if this issue was my own fault, but it seems Magento did not create this directory during installation and the Cloudinary extension assumes it exists.

Cloudinary is Useless in the CMS Pages!

We should have parameters/configurations to define the "w_" and "h_" as well; currently, we can only apply universal parameters/configurations.

We could be using this as an efficient way to add the proper width that is taken from the browser/device: https://github.com/aFarkas/lazysizes/tree/gh-pages/plugins/rias

Cloudinary Broken if using Composer

When a user installs using Composer, because the library has been committed to the source, Composer will redownload the source and thus PHP throws an error due to duplicated function names.

Suggest that you remove the library from the lib folder asap - to resolve this.

Access to beta for Cloudinary

New version incoming!!
If anyone would like to have access to the improved and simplified beta please tag below. I am going to be getting it added to Develop branch once we have finished QA'ing

Adding youtube and vimeo videos

how can we add youtube and vimeo videos in image product gallery?

Cannot save the Cloudinary configuration

I notice that when trying to save the configuration or uploading an image the method \Cloudinary_Cloudinary_Model_System_Config_Free::validateImageUrl is called.

The method above is making a call to the sample image, which returns a 404 and with the method above throws a throw new Mage_Core_Exception($this->formatError($response)); which makes impossible to save the configuration.

Module does not work with symlinked media folder

In magento it is very common to have the media folder as a symlink, pointing to a shared resource of images.
This is common in a multi-server setup where images are shared across servers.

In admin, when adding images to CMS pages, the storage thumbnails do not work, as the incorrect REAL path is passed as the image url, which is incorrect.

To reproduce the problem:

• In your magento base folder move the media folder to a new folder called 'media_REAL' mv ./media ./media_REAL
• symlink that to the magento_REAL folder as media: ```ln -s ./media_REAL ./media

You will have a folder setup as such:

Access magento admin, and attempt to insert an image into the cms content area.
You will find none of the thumbnails show:

Checking given paths:

notice the usage of media_REAL which makes the image path incorrect.
Expected would simply be /media/

This is a serious issue, and is requiring disabling of teh module, as our content staff cannot work on content, effectively stopping site work.

We are thus paying for a service we cannot use. Please attend urgently.

409 Already Exists results in unsynchronized image

If an image already exists in Cloudinary, the returned 409 AlreadyExists error should be caught and the image tagged as synchronized.

Installing latest version causes admin menu to dissapeer

Installed the extension via Magento connect using https://connect20.magentocommerce.com/c1b490ed2f887a5e9e7536e0a63fd69b/cloudinary+Cloudinary_Cloudinary-2.8.3
Successfully.

However, when returning to admin, the entire admin menu has vanished. Can still see the dashboard, though cant seem to access other admin pages.
(cache off, no compilation etc, obvious stuff)

Inspector reveals, the admin menu isnt just hidden, its never generated.

Removing code/community/Cloudinary/* resolves.

Using Magento ver. 1.9.3.8

Any ideas?

Fatal error: Uncaught Error: Class 'Cloudinary' not found in /var/www/htdocs/.modman/cloudinary_magento/lib/CloudinaryExtension/CloudinaryImageProvider.php:114

With version 2.9.6, installed via modman:

#0 /var/www/htdocs/.modman/cloudinary_magento/lib/CloudinaryExtension/CloudinaryImageProvider.php(34): CloudinaryExtension\CloudinaryImageProvider->authorise()
#1
/var/www/htdocs/.modman/cloudinary_magento/lib/CloudinaryExtension/CloudinaryImageProvider.php(42): CloudinaryExtension\CloudinaryImageProvider->__construct(Object(Cloudinary_Cloudinary_Model_Configuration), Object(CloudinaryExtension\ConfigurationBuilder), Object(CloudinaryExtension\UploadResponseValidator))
#2 /var/www/htdocs/.modman/cloudinary_magento/app/code/community/Cloudinary/Cloudinary/Model/Catalog/Product/Media/Config.php(30): CloudinaryExtension\CloudinaryImageProvider::fromConfiguration(Object(Cloudinary_Cloudinary_Model_Configuration))
#3 /var/www/htdocs/app/code/core/Mage/Core/Model/Config.php(1357): Cloudinary_Cloudinary_Model_Catalog_Product_Media_Config->__construct(Array)
# in /var/www/htdocs/.modman/cloudinary_magento/lib/CloudinaryExtension/CloudinaryImageProvider.php on line 114

Some images are not served from Cloudinary

I just started using the extension and it's worked well so far, mostly on product images, however I noticed that some images don't get served from Cloudinary, eg: category images, logo, etc.

Is there any helper function or something I can use in the code to make sure the image is used from Cloudinary and not my server?

Great work on the extension btw!

Select Images from Media Gallery

Hi!

I have a feature request.
When editing a Magento product media gallery (in Admin Panel of course) it would be really nice to be able to choose/assign from existing images in the Cloudinary Media Gallery (in addition to the Magento "standard upload files"-feature).

Thanks for your attention!

Your magento subfolder setup prevents using composer for install

Hi,

Am I missing something here? You have negated ability to use composer for install.

You have placed magento 1 and magento 2 code in subfolders in the same repo.
Each has a composer.json, however composer cannot install from subfolders. (ref: composer/packagist#472)

So basically, having done the subfolders, you have negated ability to use composer to install either package.

You should consider separate repos for magento 1 and magenrto 2 versions of the code, since, in reality they are two different platforms...

Error in logs: Strict Notice: Declaration of Cloudinary_Cloudinary_Model_Cache::save() should be compatible with Mage_Core_Model_Abstract::save() in public_html/app/code/community/Cloudinary/Cloudinary/Model/Cache.php on line 0

Hi,

as per subject: lots of occurrences of error:

Strict Notice: Declaration of Cloudinary_Cloudinary_Model_Cache::save() should be compatible with Mage_Core_Model_Abstract::save() in public_html/app/code/community/Cloudinary/Cloudinary/Model/Cache.php on line 0

Magento ver. 1.9.3.2 with all patches up-to-date to latest.

wysiwyg-images with problems if media behind a symlink

We encountered a strange behavior with the cms-image-synchronisation because the wrong image_names (pathes) got into the cloudinary_synchronisation table.
After some investigations we found out that Mage::helper('cms/wysiwyg_images')->getStorageRoot() yielded the real_path of the symlinked file.
As that file was written into the filesystem-collection and compared with the database entries the extension never found any synced wysiwyg images and tired to sync everything again, resulting in more and more database entries, because after a sync/already exists it got written with the wrong path (realpath prepended with /media) into the table.
#14 fixes this by using not the real_path but the path Mage::getBaseDir() is returning so the pathes from the database and the ones from the filesystem-collection can be the same again.