After upgrading a website from opencart 1.5 to 2.3 I can't see the old uploaded images in file manager. My files are in /images/data/... while the file manager loads on /images/catalog/ and doesn't let me access any files beyond this folder. Is there a way to change the default location for file manager?
Luckily the older products still have the right links to their images, but since any new will have to be stored under /catalog directory, I will not be able to upload any new ones to already well made file structure.
admin/config.php will give you the directory of your image files, you can also change it to point at the correct location.
Related
I'm trying to get VuePress to work well with GitHub Pages and a custom domain. I have the site working -- https://www.southertonrr.com (repo) -- as long as I manually add a CNAME file to my output folder ('./dest', or in my case, './docs', because that's where GitHub Pages looks for the site) every time after I issue a build command. Otherwise, I assume the build command deletes everything in my output folder and rebuilds the entire site.
Is there a way to get vuepress build to either leave that file alone, or copy a CNAME file from my ./src to my ./docs? Should I be looking at the configureWebpack config to use webpack to do it? (I'm new to webpack.)
Different product completely, but I noticed that Docusaurus for React has a CNAME config setting that does this for you, so I thought I'd check to see if the VuePress community had something similar.
See relative document
Sometimes you may need to provide static assets that are not directly referenced in any of your Markdown or theme components - for example, favicons and PWA icons. In such cases, you can put them inside .vuepress/public and they will be copied to the root of the generated directory.
I was trying to upload an image using Sitecore [Version 6.5] media library to my existing sitecore website. I see the Advance Upload Files option is completly missing. Later, I tried to install a default sitecore instance and I see the Advanced Upload option is there. But it is completely missing to the existing sitecore website.
Here, is the snapshot of my site where the Advanced upload option is completely missing:
And here is the snapshot of my default sitecore site where the Advanced upload option is there:
To fix this, I tried to change couple of configuration files. But still the same issue. The Advanced upload files option is completely missing. Did you face the same type of issue or if you know how to fix this issue, can you please share your thoughts. Or if I need to change any of the configuration files, then can you share your thoughts about that change of any of the configuration file?
Thanks
Upload files (Advanced) button is hidden in 2 cases:
Folder does not use Media Folder template. Just check your folders - maybe they use standard Folder template instead of Media Folder.
Upload.Classic setting is set to false. Open /sitecore/admin/showconfig.aspx and look for Upload.Classic value. When it's set to true, Sitecore uses flash upload instead.
If none of above is the case, maybe you have some custom code which hides Upload files (Advanced) button from you editors.
Am very new to magento, created one site using magento. All the functionality are working fine in localhost. When am upload that code into online(server), i got one issue. except that all functionality are working fine.
While am uploading an image i got the issue "Unable to create directory".
Images are uploading to tmp path but not moving to target path. Because when am press the button 'upload files', I can able to see the upload percentages. That is why am thing the files are not moving due to dynamic directory creation fails.
I have tried lot but i can't able to make it as work.
I had tried the following solution,
1. Changed the media file permission to 777.
2. Created one tmp directory under /var/ directory and assigned manually in as tmp directory by change the line 91 of lib/Zend/Cache/Backend/File.php ('cache_dir' => null to 'cache_dir' => 'var/tmp').
3. Changed the php.ini file under the magento root directory.
Newly added lines are,
magic_quotes_gpc = off
short_open_tag = on
extension=pdo.so
extension=pdo_mysql.so
4. Checked whether GD library installed or not. It was installed.
5. Changed scope attribute in Magento admin panel -> Catalog -> Attributes -> Manage attributes. After this you should find image, small_image & thumbnail attributes. Then am changed all these attributes scope to Global.
Many thanks in advance. Please share your thoughts. Feel free to post your comment also.
Finally I got solution at 22-Aug-2014.
Problem is PHP version issue, megento need php 5.2.13 but my server contains php 5.2.12
After updated php version, image upload working fine.
We are using Sitecore 6.5 and have a multi-site Sitecore solution (with lots of library code we have inherited)
Publishing the Media Library by item from Staging to Production but we are not seeing the image on the web.
The images are in the web database and the path to the images in the web site is good.
Error we are getting when the file is requested (same in browser window address bar) is http://domainname/error?aspxerrorpath=/~/media/OSS/Images/WaterAndWildlife/myimage.jpg.
There is no media prefix in the web.config
Any idea?
....Looking into it now but site is going live tomorrow so help very appreciated! Help!!
We faced a similar problem when, in production, media files were not published which resulted in 404 errors.
Solution: The problem was that media files were not saved to the database because a file path was provided with the Sitecore media files while uploading.
So the images were saved on the file system instead of in the database. But based on our web.config configuration we were fetching images from the database.
If you are facing a similar issue, just download the media image, remove the file path, and save it. Then re-upload the same image, save and publish the image.
Hope your problem will be solved.
One question, are these staging and production environments separate code files? if they are, what is the setting in your web.config for the settigns UploadAsFiles? because if that's true it will store them on server and the images will be on staging but not on prod. But usually if this setting is true and the files are getting stored in file system, specially in CM/CD environment it should push the physical files on publish as well, but sometime there might be other issues going on like permission etc..... and the files cant get to the destination.
"<setting name="Media.UploadAsFiles" value="false">"
I am doing a website(Joomla) and I am using admiror gallery. Everything is working fine while I was working in the localhost but now that I migrated it to a live server, I am having problems in uploading images in the gallery.
The first is when I create a new folder to contain my new images. When I create it and try to upload a zip file, it's taking forever to load only to find out that it's not even uploading at all. When I looked into it, the reason is when a new folder is created, the permission is 755 by default, thus, making changes on the folder is not allowed. I need to change the file permission to 777 and now I am able to upload my images but there is another problem that occurs. The thumbnails in the backend are showing broken images. This is because the 'thumbs' directory in home/administrator/components/com_admirorgallery/assets/thumbs/ is again set to 755. I tried to change it to 777 and reupload the images again. The images gets uploaded but the problem with the thumbnails is still there. I checked again the folder and the permission is reverted back to 755.
Is there something I can do with this? Any suggestion is appreciated. Thanks in advance.
You should check the files and folder owner, not only permission.
PHP user (Joomla) is the creator of thumb folder, thus it should be able to create files in that directory. Also, it is not safe to have 777 on live site.
Shambhala made a suggestion that should help. Also you should use AkeebaBackup when migrating from local to live server, I never had problems with it.