I have just started using the MAGMI image attribute processor and am having a few issues.
Initially, I was getting open_basedir errors, but I have (I think!!) temporarily disabled open_basedir for the domain.
Now however, I am getting the following:
error creating /media/catalog/product/d: 2,mkdir(): No such file or directory
for all the images being processed.
My configuration is as follows:
Server setup is on a Plesk 10 VPS.
Value for filesystem path in MAGMI: '/httpdocs'
Image processor local images store: 'media/import/'
Magmi version 0.7.17
Other posting by dweeves suggest a faulty value for filesystem path, however when I try and enter the full filesystem path into the field (i.e. /var/www/vhosts/domain.com/httpdocs) this is replaced with simply 'httpdocs' suggesting magmi knows its there already.
Any ideas??
If you are running this on a fresh magento install and have never added an image before, the "catalog/product" directory will not exist so you must create it. The image plugin assumes that is there.
Related
This one is puzzling me for 2 days now. I've found a solution for a 404 in admin, but it is not the same that is happening here. I have exactly the same version of Magento in my local copy and production server: 1.7.0.2. The extension works great in local. I packaged it using Magento Connect and installed in production the same way. All files are there. It shows in the menu and in Configuration section, but when I click the menu to go to the report, I get the beloved 404. I loged out and in, flushed cache zillion times (including deleting the files manually) but nothing changed.This are the URLs in both envs:
(Dev)http://localhost/magentos/index.php/salestaxes/adminhtml_salestaxes/index/key/c4b8ecb58fa2062f696cacfd340/
(Prod)https://www.myserver.com/index.php/salestaxes/adminhtml_salestaxes/index/key/332e617e74a92a39a40cf5d3/
As you can see is exactly the same. I don't know wahy then I'm getting the error. Can somebody point what can I do to solve this? DO I need to check any setting? What can cause this?
This is a var_dump that I get in the router _validateControllerClassName() method:
string(115) "/home_path/public_html/app/code/community/Surpassweb/SalesTaxes/controllers/Adminhtml/SalestaxesController.php"
string(100) "/home_path/public_html/app/code/community/Surpassweb/SalesTaxes/controllers/IndexController.php"
This is the output of Alam's 404 module:
Controller Name
Controller Name: adminhtml_salestaxes
The controller name adminhtml_salestaxes matches the following controller file, but this file does not exist.
home_path/public_html/app/code/community/MyCompany/SalesTaxes/controllers/Adminhtml/SalestaxesController.php
The file is there and has 755 permissions.
This is the first line in may controller:
class MyCompany_SalesTaxes_Adminhtml_SalesTaxesController extends Mage_Adminhtml_Controller_Action {
Thanks for your time.
Are you absolutely sure the file is there? Named the same? With the same character capitalization? And that you're not in a production setup with multiple frontend webservers?
If you'll indulge me — copy the path of the controller from the Better 404 page to your computer's clipboard. Then type
$ ls -l [PASTE]
into your terminal window. My bet if the file won't be there. Also try
$ls -l app/code/community/Surpassweb/SalesTaxes/controllers/Adminhtml/
to see what files are there.
Looking at the information you provided, Magento is looking for a file named
app/code/community/MyCompany/SalesTaxes/controllers/Adminhtml/SalestaxesController.php
I don't know what your actual file is named, but looking at the class name
MyCompany_SalesTaxes_Adminhtml_SalesTaxesController
leads me to believe it might be incorrectly named SalesTaxesControlle.php. Notice the T in sales taxes is capitalized, vs the lowercase t Magento is looking for.
For some reason magento isn't registering the route to your app.
Either apache doesn't know to let magento handle it or magento doesn't know what to do with it.
Check your htaccess files and virtual host configs for the two environments.
Right off the bat I can see they're not exactly the same. One is http and one is https.
Those are probably two different virtual host configs and could be slightly different.
Next I would make sure the config xml for your module is included in magento/app/etc/modules/ folder. Make sure the module is enabled. There should be a line for that in your modules config xml file.
If you deployed it to the local vs community folder, check the magento/app/etc/local.xml and make sure disable_local_modules is set to no.
Good luck. Troubleshooting in live is always fun.
I am having an issue uploading images but clearing the image search path is not working to solve my issue. (Found in another post)
This is the error i get:
Image attributes processor v1.0.25 - error copying media/catalog/product/5/4/54402.jpg : download error,URL cmsdistribution.com/product-files/image/54402.jpg is unreachable
Image attributes processor v1.0.25 - error copying media/catalog/product/5/4/54402.jpg : download error,URL cmsdistribution.com/product-files/image/54402.jpg is unreachable
Image attributes processor v1.0.25 - error copying media/catalog/product/5/4/54402.jpg : download error,URL cmsdistribution.com/product-files/image/54402.jpg is unreachable
The media/catalog/product folder and everything below is set to 777 and the URL i am calling in the csv looks fine and i can find it in a simple browser (Seen 3 times above (once for image, small_image and thumbnail with the only other column in the sheet being sku))
Has anyone else played with image importing? Am i missing something?
I have had to remove the http www dot etc from the codes above as i am being caught out for spamming in the post
Try using the latest svn version of Magmi. The image processor had a "bug" for handling redirected images (checking only 200 response on HEAD request for download check).
The latest svn version has a fix for this.
Ok I got Drupal 7.19, mySQL 5.1.66-cll PHP 5.3.21
Now I searched for he above error and found various answers of various age, however it doesn't address, my problem.
I get the error for any file bigger than 100k
went through php.ini settings.php as well as account settings, which is now 5000k.
and max post and max file are way higher.
The site has only 2 image fields, the original as well as one other. It doesn't matter which one is used in a content, the field settings for the original one were never changed and the themed installation came with images larger than 500k.
While for the time I can live with resizing images before uploading, it nevertheless is a pain in the .... and I really would appreciate any help.
I had a similar problem which i resolved via the php.ini file as well as the apache mod_security user.conf file.
My httpd is apache2, which has mod_security enabled, which also did not allow me to upload over 100k image file in Drupal. Apparently this is a common problem for the web-hosting provider (liquid web) because it took no more than 3 minutes to resolve.
First the php.ini file was altered (on CentOS it is in /usr/local/lib/) with lines:
;upload_tmp_dir = /tmp (yes it has a semi-colon at the start)
and also the line:
session.save_path = "/tmp"
Second file that was altered is the modsec2.user.conf file located on (CentOS) at /usr/local/apache/conf/
(appended at the bottom of the file in the last 2 lines):
SecUploadDir /tmp
SecTmpDir /tmp
Then /etc/init.d/httpd restart (or reload) apache and you should be able to bypass this limit for file uploads by mod_apache if it is enabled. Best of luck and please know that this is my first answer on stack so please be considerate.
just you can request your hosting provider
to added into the sites whitelist.conf file :
<IfModule mod_security2.c>
<LocationMatch .*>
SecRuleRemoveById 340147
</LocationMatch>
</IfModule>
I moved website to new server, domain stay the same, files structure stay the same, but path to public_html has beed changed. Database has been also moved.
I tried to clean cache, but i dont think I made it. This is error i get:
Could not find action file at: /home/account_name/domains/domain.co.uk/public_html/manager/controllers/default/welcome.php
account_name is different now.
I havent access to the old server, so I cant login and clear cache. I tried to do it using php script I found, but it didnt help.
Moving to new server documentation - there is welcome.php error and how to fix it, but since I haven't access to website from old server, I can't do it.
Also I can't login and clear cache in admin panel, because this message in when i wan get access to it.
I also change in db, in modx_workspaces->path from {core_path} to home/account_name/domains/domain.co.uk/publis_html/core, but didn't help.
How can i clear cache or if it's not the case, what should I do to make it work?
Update
I have change location in settings:
config.core.php
connectors/config.core.php
core/config/config.inc.php
manager/config.core.php
In .htaccess I couldn't find path to website, I didn't change anything.
I remove all content from core/cache/, except one file (.gitignore), and if I go to domain.co.uk/manager/ it's blank page, no content at all. And still can't log in.
Clear the cache on the new server manually VIA FTP or from a shell.
Change that modx_workspaces thing back
did you change all your settings in core/config/config.inc.php ?? if not do so, that is where you will set most of your paths & database credentials.
you have a backup? good!
Now upgrade to the same version of modx, that should fix all your path issues. [make sure you are not logged into the manager while trying to upgrade]
When moving the site to the new server rather watch two things:
the right paths into this files
/config.core.php
/core/config/config.inc.php
/connectors/config.core.php
/manager/config.core.php
the folder /core/cache/ is empty. They can be cleaned simply by removing the contents via ftp.
and correct the value in the database back to {core_path}
I created a Working Joomla 2.5 website in a sub domain. When I moved the site to the root and out of the sub domain folder I get the following error when I log out. Fatal error: Call to a member function init() on a non-object in /directory/templates/rt_clarion/error.php on line 20
The build works fine in the sub domain but not in the root. I've tried the stock Joomla Templates and I still get an error at logout. I tried disabling the Joomla SEF, nothing. Anyone have any ideas what might be?
The site was moved by using akeeba backup and restoring it in the root directory.
I'm using Joomla 2.5.4, K2 v2.5.7, Rockettheme Template Clarion v1.2. Again the build works flawlessly in the subdomain.
First step find out what is causing the server to throw a 500 error - check your servers log file. It may be a simple as a permissions problem, eg. most servers are configure to throw a 500 error if the destination has permissions of 777.
After moving a Joomla! installation from a sub-domain you may need to update the Global Configuration - you can either do this through the Admin screens or by directly editing configuration.php. This often happens when people create the Joomla! site in a sub-directory and the move the site and delete the sub-directory.
The things you need to check are the paths to things like log & tmp directories, e.g.
public $log_path = '/host/public_html/asite/sub-directory/logs';
public $tmp_path = '/host/public_html/asite/sub-directory/tmp';
May need to be changed to:
public $log_path = '/host/public_html/asite/logs';
public $tmp_path = '/host/public_html/asite/tmp';
I'd suggest renaming the template directory and reinstalling that template since that is where the error is occurring, unless you're comfortable exploring the configuration/options for re_clarion
1) Switch to the default template: If you still have errors, the problem is coming from new installation. If not, it's your template (go step 2).
2) Backup your Clarion template folder on your HDD and uninstall it from your backend.
3) Install it again and check for errors. If everythings is OK, overwrite your Clarion folder with backuped data.