Python 2.7, Magento Community 1.8 API connection issues - php

I am using the python-magento API with little luck making a connection. This API is attempting to use Magento's XML-RPC and connection to Community Magento 1.8...
My local install is Python 2.7 (64) on Windows 8, while Magento is on a PHP 5.4 stack.
After a few alterations and a handful of API's used, this is the primary error with python-magento API, attempting connection from Pycharm and DataNitro...
Traceback (most recent call last):
File "C:/Users/xxx/Documents/PYTHON/magento_test_connect.py", line 2, in <module>
magento = MagentoAPI("xxx.com", 80, "userxxx", "passxxx")
File "C:\Python27\lib\site-packages\magento\__init__.py", line 20, in __init__
self.login()
File "C:\Python27\lib\site-packages\magento\__init__.py", line 59, in login
self._session_id = self._client.login(self._api_user, self._api_key)
File "C:\Python27\lib\xmlrpclib.py", line 1224, in __call__
return self.__send(self.__name, args)
File "C:\Python27\lib\xmlrpclib.py", line 1578, in __request
verbose=self.__verbose
File "C:\Python27\lib\xmlrpclib.py", line 1264, in request
return self.single_request(host, handler, request_body, verbose)
File "C:\Python27\lib\xmlrpclib.py", line 1297, in single_request
return self.parse_response(response)
File "C:\Python27\lib\xmlrpclib.py", line 1473, in parse_response
return u.close()
File "C:\Python27\lib\xmlrpclib.py", line 793, in close
raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault 2: 'Access denied.'>
Process finished with exit code 1
I was looking for some direction, but now I am going to throw a bounty as I see making a connection to Magento with Python is not documented well on the web.
The code I have scaled down to is...
from magento import *
magento = MagentoAPI("xxx.com", 80, "userxxx", "passxxx")
magento.help() #just to see some results
going to the direct url path (to check on firewall issues), I get...
<methodResponse><fault><value><struct><member><name>faultCode</name><value><int>630</int></value></member><member><name>faultString</name><value><string>Unable to read request</string></value></member></struct></value></fault></methodResponse>
I have entered all of the details into Magento admin and gave full privileges. Thought about using the REST API, but after reading this unanswered question, looks to be having the same issues.
**
Changing up my code a bit...
**
import magento
url = 'xxx.com'
port = 8080
apiuser = 'userxxx'
apipass = 'passxxx'
with magento.MagentoAPI(url, port, apiuser, apipass) as product_api:
order_filter = {'created_at':{'from':'2013-01-15 00:00:00'}}
products = product_api.list(order_filter)
the error...
socket.error: [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
I was able to set this up on another Magento install and it worked, showing...
Resources:
cart: create, info, license, order, totals
cart_coupon: add, remove
cart_customer: addresses, set
cart_payment: list, method
cart_product: add, list, moveToCustomerQuote, remove, update
cart_shipping: list, method
catalog_category: assignProduct, assignedProducts, create, currentStore, delete, info, level, move, removeProduct, tree, update, updateProduct
catalog_category_attribute: currentStore, list, options
catalog_product: create, currentStore, delete, getSpecialPrice, info, list, listOfAdditionalAttributes, setSpecialPrice, update
catalog_product_attribute: addOption, create, currentStore, info, list, options, remove, removeOption, types, update
catalog_product_attribute_media: create, currentStore, info, list, remove, types, update
catalog_product_attribute_set: attributeAdd, attributeRemove, create, groupAdd, groupRemove, groupRename, list, remove
catalog_product_attribute_tier_price: info, update
catalog_product_custom_option: add, info, list, remove, types, update
catalog_product_custom_option_value: add, info, list, remove, update
catalog_product_downloadable_link: add, list, remove
catalog_product_link: assign, attributes, list, remove, types, update
catalog_product_tag: add, info, list, remove, update
catalog_product_type: list
cataloginventory_stock_item: list, update
core_magento: info
core_store: info, list
customer: create, delete, info, list, update
customer_address: create, delete, info, list, update
customer_group: list
directory_country: list
directory_region: list
giftmessage: setForQuote, setForQuoteItem, setForQuoteProduct
sales_order: addComment, cancel, hold, info, list, unhold
sales_order_creditmemo: addComment, cancel, create, info, list
sales_order_invoice: addComment, cancel, capture, create, info, list, void
sales_order_shipment: addComment, addTrack, create, getCarriers, info, list, removeTrack, sendInfo
Process finished with exit code 0

After many tests, a 1.7 install worked while the 1.8 remained under block on the same server and configurations. The only conclusion is 1.8 is not completed for API use and this issue is (as of 6/23/13) a 1.8 Magento bug.

Not sure if thread originator is still having an issue but I ran into problems with python-magento and xmlrpc with Magento 1.8.
from magento import *
m = MagentoAPI('mag1', 80, 'user', 'pass')
fails with
<ProtocolError for mag1:80/magento/api/xmlrpc: 404 Not Found>
The default PATH in python-magento is /magento/api/xmlrpc.
Changing this to '/index.php/api/xmlrpc' worked for me:
m = MagentoAPI('mag1', 80, 'user', 'pass', path='/index.php/api/xmlrpc')
succeeds.
Problem caused by new rewrite processing in Magento 1.8. See here for more info:
Magento API error when accessing.
Hope this helps.
Jerry.

Related

Custom Cache per Country - Wordpress php [Disable Cache from function]

On our website at www.EllasBubbles.com, we are using a functions.php script to execute an alternative stylesheet to users who are outside of U.S/Canada. This script is as follows:
// [International] - Dark Mode
add_action( 'wp_head' , 'custom_inline_css', 200 );
function custom_inline_css() {
// Get an instance of the WC_Geolocation object class
$geolocation_instance = new WC_Geolocation();
// Get user IP
$user_ip_address = $geolocation_instance->get_ip_address();
// Get geolocated user IP country code.
$user_geolocation = $geolocation_instance->geolocate_ip( $user_ip_address );
// For all countries except 'US'
if($user_geolocation['country'] !== 'US' && $user_geolocation['country'] !== 'CA'){
?>
<style>
<?php include 'international.php'; ?>
</style>
<?php
}
}
We use cloud flare to manage our Cache. I have properly setup bypass rules for these two files:
ellasbubbles.com/wp-content/themes/flatsome/international.php
ellasbubbles.com/wp-content/themes/flatsome/assets/css/flatsome.css
When loading the site from an international VPN, the "Dark Mode" (Outside U.S/Canada) version is displayed. However, when disabling the VPN; we are stuck on Dark Mode. Which is a bypassed file with Cloudflare Cache - and simply makes no sense to me.
This leads me to believe that the instance of the WC_Geolocation class is being cached somewhere on the Wordpress website. I have searched everywhere for a solution, and can not determine the best way to perform this custom CSS per country. Can we disable caching from function custom_inline_css ? Should I change international.php to css? Is there a better way to go about this?
Update 1: When I disabled caching from the entire website in cloud flare, this works fine!
Update 2: When I disable caching from everything inside ellasbubbles.com/wp-content/*; this still does not work properly..what file am I missing?
Update 3: I disabled all folders one by one to no avail
Please help me help everyone

Is it possible to change the output width of PHP Shell_Exec?

I'm looking to parse the output that I'm getting back from PHP shell_exec. But some of the output that's returned is in tabular format and the data is wrapping within the columns as shown here...
Name Installed Proposed Message
Version version
Views Bulk Operations 7.x-3.3 7.x-3.4 Update available
(views_bulk_operations)
Chaos tools (ctools) 7.x-1.12 7.x-1.13 Update available
CAS (cas) 7.x-1.5 7.x-1.7 Update available
Custom Search 7.x-1.18 7.x-1.20 Update available
(custom_search)
Date iCal (date_ical) 7.x-3.5 7.x-3.9 Update available
Entity API (entity) 7.x-1.8 7.x-1.9 SECURITY UPDATE available
Field Group (field_group) 7.x-1.5 7.x-1.6 Update available
Media (media) 7.x-1.6 7.x-2.16 SECURITY UPDATE available
Insert (insert) 7.x-1.3 7.x-1.4 Update available
Views (views) 7.x-3.16 7.x-3.18 SECURITY UPDATE available
Views Data Export 7.x-3.0-beta8 7.x-3.2 SECURITY UPDATE available
(views_data_export)
Views PHP (views_php) 7.x-1.0-alpha 7.x-1.0- Update available
1 alpha3
Athena (athena) Unknown Unknown Project was not packaged
by drupal.org but
obtained from git. You
need to enable git_deploy
module
To make it easier to parse, I was hoping to be able to change the width of the output so the data doesn't wrap.
I assumed that specifying the width of the console with stty would work, but it doesn't. I tried this...
$output = shell_exec('stty cols 180; cd /; cd ' . $drupal_sites_folder_path . $list_of_drupal_sites[22] . '; drush pm-updatestatus');
...but the output width is still set to 80 cols.
Any suggestions on how to change the width of the output from shell_exec?

Magento - API not being updated

The previous provider killed several kittens by changing the core many times of a Magento 1.6.2.0 distribution.
So, in order to solve an issue in record time, we had to screw and hit the kittens' corspses: we still maintain the modified API: catalog_category.assignProduct.
So far, we have this API for the method:
public function assignProduct($categoryId, $productId, $position = null, $identifierType = null)
{
$datos = explode('|', $categoryId);
$productId = array_shift($datos);
$categorias_actuales = Mage::getModel('catalog/category')
->getCollection()
->addIsActiveFilter()
->addIdFilter($datos)
->addLevelFilter(3)
->getAllIds();
$incat = function($cat) use ($categorias_actuales) {
return in_array($cat, $categorias_actuales);
};
$result = array_combine($datos, array_map($incat, $datos));
try {
$product = Mage::helper('catalog/product')->getProduct($productId, null, $identifierType);
$product->setCategoryIds($categorias_actuales);
$product->save();
} catch (Mage_Core_Exception $e) {
$this->_fault('data_invalid', $e->getMessage());
} catch (Exception $e) {
$this->_fault('internal_error', $e->getMessage());
}
return $result;
}
The intention of the API was to assign many categories at once for a product. However this is a modified version because the previous was prohibitively slow. And the curious fact is that this worked until recently. It's intention was to:
only the first parameter is used, and instead of an integer value, a kitten was killed here and the API now expects a string like "productId|catgId1|catgId2|cargId3|..." where the first value is a product id and the second to last values are categories ids; each of them being integer values. The parameter is broken by pipe character ("|") and the product id is popped. In this way, we have the product id in one var, and the categories array in another var.
get the categories collection keeping only the active ones in level 3 (i.e. depth for the category in the tree) whose ids are among the specified ones. This means: if provided categories are array(3, 5, 7, 8) (e.g. from a "245|3|5|7|8" parameter, being "245" the product id) and one of them does not exist or is not active (e.g. 7 is not active and 8 does not exist), the returned value in $categorias_actuales is [3, 5].
as for debugging porpuse, map each input category to existence and validity. this means: existent&&active&&level=3 categories will have "true" as value, while non-existent or non-active categories will have "false" as value. For the given example, the returned array would be: array(3 => true, 5 => true, 7 => false, 8 => false), since 7 is not active and 8 does not exist.
in the try-catch block: a. retrieve the product; b. set the filtered ids (in the example: [3, 5]) as product categories in the just-fetched product; c. save the product.
However, I have the following issues:
The function returns true, so returning $result would not give me the array $results as return value (my intention was to know in which categories was the product actually inserted).
Changing to false instead of $result in the return statement had no effect at all: the obtained/displayed value from the API call was still true.
Throwing a new Exception("something's going on here") had no effect at all. Still true at output.
dying (die('something's going on here')) neither had effect. Still seeing (guess what?) true at the output.
Edit: Also tried a syntax error!! (guess what? nothing happens).
It's not only that I tried these steps, but also refreshed the cache (System > Cache Management > select all and refresh, and even clicking the "Flush Magento Cache" button).
Questions:
1. given the issues before: how can I debug that API call?
2. what could be causing the product not being saved with their categories? By calling category.level I can see that the given ids (i.e. given in the first parameter to category.assignProduct) exist.
I'm a n00b # magento API and perhaps I'm missing something usually obvious. Any help would be appreciated.
Did you disable compilation? You can do it in one of these two ways.
System -> Tools -> Compilation in admin
Use SSH/shell and navigate to your magento root. Do the following commands:
cd shell
php -f compiler.php disable
Also, if your web server runs PHP APC with apc.stat set to 0 (you can check this by running php -i | grep apc.stat or looking for it at any phpinfo() output), please restart your apache2 web server or if you use php5-fpm -- restart that one, too.
Then, if all else fails, try looking for an equivalent file at app/code/local.
e.g. if your file is somewhere in app/code/core/Mage/Path/ToApiFile.php, look for the local version at app/code/local/Mage/Path/ToApiFile.php.
Finally, a very useful shell command for searching code instances:
$ cd app/code/
$ grep -rin "function assignProduct" *

Magento 404 on Admin Page

About a week ago, I was working in a test environment for a new site. I left for an hour, came back, and now cannot get to the admin page, as in ‘http://magento.localhost.com/admin’ results in a No Route 404. I am the only one with access to this, it is not live in any sense. I am using VBox with Ubuntu to host the environment. In terms of possible fixes, so far I have tried…
Making sure core_store, core_store_group, core_website, and customer_group table ids are set to 0 (as described in this and many other articles - http://www.nude-webdesign.com/fix-for-magento-admin-error-404-page-not-found/)
Playing with the /app/code/core/Mage/Core/Controller/Varien/Front.php method _isAdminFrontNameMatched to display the adminPath (it’s ‘admin’)
Cleared the var folder, emptied browser cache. Site’s caching was and is turned off.
Adding 'index.php' to the url still results in a 404.
As per Magento Admin 404, the file 'app/etc/use_cache.ser' doesn't exist for me.
On the day of this occurring, I was simply playing around with some layout files I had copied to a module I made and the theme’s media queries (all of which were reverted to their original state even before this problem started to occur).
Does anyone have any suggestions as to what is wrong here? Any other possible reasons this could be happening?
Thanks for anything.
EDIT 1:06pm 9/10/2013: In response to Alan Storm's method of retrieving controller names that Standard.php is looking for, I was returned many "missing" controller files. However, after downloading a fresh copy of 1.7.0.2 to find those files, they weren't present in their either. Here is my output from Alan's var_dump suggestion in Standard.php:
..."/public_html/app/code/core/Mage/Index/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Paygate/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Paypal/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Widget/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Oauth/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Authorizenet/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Bundle/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Centinel/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Compiler/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Connect/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Downloadable/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/ImportExport/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Api2/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/PageCache/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/XmlConnect/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/Adminhtml/controllers/Controller.php"
..."/public_html/app/code/community/Phoenix/Moneybookers/controllers/Controller.php"
..."/public_html/app/code/core/Mage/Captcha/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/CurrencySymbol/controllers/Adminhtml/Controller.php"
..."/public_html/app/code/core/Mage/CurrencySymbol/controllers/Adminhtml/IndexController.php"
Resolved 3:39pm 9/10/2013: Ok, it's fixed albeit rather bluntly. I took the output of Alan Storm's var_dump suggestion to mean I had created an error somewhere in the core code pool (which is not something I intended on doing, screwing with the default code that is). Unfortunately for sake of exact learning, I then replaced it all with the default core code pool of 1.7.0.2. This was done before Alan updated his original answer with more suggestions that I never investigated. Thanks Alan, you're rad.
A no route 404 error usually indicates Magento can't find the controller file it thinks it should load (usually due to a misconfiguration)
The easiest way to diagnose this is to hop to _validateControllerClassName
#File: app/code/core/Mage/Core/Controller/Varien/Router/Standard.php
protected function _validateControllerClassName($realModule, $controller)
{
$controllerFileName = $this->getControllerFileName($realModule, $controller);
if (!$this->validateControllerFileName($controllerFileName)) {
return false;
}
$controllerClassName = $this->getControllerClassName($realModule, $controller);
if (!$controllerClassName) {
return false;
}
// include controller file if needed
if (!$this->_includeControllerClass($controllerFileName, $controllerClassName)) {
return false;
}
return $controllerClassName;
}
and drop some logging or var_dumps around the return false statments. This should tell you which files Magento is looking for and can't find — it's usually enough to point to the problem.
if (!$this->validateControllerFileName($controllerFileName)) {
var_dump($controllerFileName);
return false;
}
$controllerClassName = $this->getControllerClassName($realModule, $controller);
if (!$controllerClassName) {
var_dump($controllerClassName);
return false;
}
// include controller file if needed
if (!$this->_includeControllerClass($controllerFileName, $controllerClassName)) {
var_dump("Couldn't include: $controllerFileName");
return false;
}
Update: It's normal for Magento look for the controller file in multiple places — every module that registered as containing adminhtml controller files needs to be checked.
However, almost all the controller files being looked for are named /Controller.php. For the default /admin index page this should be IndexController.php. This makes me think your system thinks it's supposed to look for a controller with a blank name, (likely the default controller value since /admin (and not admin/index) is the URL you're using)
There's myriad reasons this could happen — many revolving around a core file being changed or a configuration node in a module set to the wrong value. If the solutions below don't work for you you'll need to try diff-ing your code base vs. a clean one, disabling every custom module and if that fixing things turn modules back on until the problem module is found, or dive deep into debugging Magento routing code to figure out why your system is unhappy.
One common cause for this behavior is an invalid value (or no value at all) being set for a custom admin path at
System -> Configuration -> Admin -> Admin Base URL -> Use Custom Admin Path
If the value for "custom admin path" is blank, or contains and additional /, this could be interfering with the routing.
Since you can't access the admin, try running the following SQL query
select * from core_config_data where path like '%custom_path%';
...
292 default 0 admin/url/use_custom_path 1
293 default 0 admin/url/custom_path admin/
If you see results similar to the above, or admin/url/custom_path is blank/not-present but admin/url/use_custom_path is still 1 — then that's your problem.
Try deleting these configuration values (admin/url/use_custom_path) and (admin/url/use_custom_path) from core_config_data.
If that doesn't apply to your system, per my blank controller theroy my best guess would be for some unknown reason the code at
#File: app/code/core/Mage/Core/Controller/Varien/Router/Admin.php
public function fetchDefault()
{
// set defaults
$d = explode('/', $this->_getDefaultPath());
$this->getFront()->setDefault(array(
'module' => !empty($d[0]) ? $d[0] : '',
'controller' => !empty($d[1]) ? $d[1] : 'index',
'action' => !empty($d[2]) ? $d[2] : 'index'
));
}
is populating the controller key with a blank value.
In my case, my admin was giving me 404 because there's no store set.
I solved it by running the following query
SET SQL_SAFE_UPDATES=0;
SET FOREIGN_KEY_CHECKS=0;
UPDATE `core_store` SET store_id = 0 WHERE code='admin';
UPDATE `core_store_group` SET group_id = 0 WHERE name='Default';
UPDATE `core_website` SET website_id = 0 WHERE code='admin';
UPDATE `customer_group` SET customer_group_id = 0 WHERE customer_group_code='NOT LOGGED IN';
SET FOREIGN_KEY_CHECKS=1;
SET SQL_SAFE_UPDATES=1;
You can check if you get the below error logged in var/log/system.log
ERR (3): Recoverable Error: Argument 1 passed to Mage_Core_Model_Store::setWebsite() must be an instance of Mage_Core_Model_Website, null given, called in /.../app/code/core/Mage/Core/Model/App.php on line 634 and defined in /.../app/code/core/Mage/Core/Model/Store.php on line 395
Before anything check your configuration file ( app/etc/local.xml) and make sure that you have "admin" as value for the frontName tag.
ex.:
<adminhtml>
<args>
<frontName><![CDATA[admin]]></frontName>
</args>
</adminhtml>
Usually when you try http://yoursite.com/admin it gives you the admin area
Try using an url like that http://yoursite.com/index.php/admin
and if it works probably you need to only modify the rewrite rules or follow the suggestions (see the link below)
I got this problem on a shop with custom admin url www.shop.com/customadminroute/ and System -> Configuration -> Web -> URL options -> Add Store Code to Urls: Enabled
In this case the following module should fix it:
https://github.com/romfr/404adminlogin
Thanks to Blog post of Carmen Bremen:
http://neoshops.de/2012/09/07/magento-404-fehlerseite-beim-admin-login/

Magento 1.10 Enterprise Salesrule Product Subselection Error

So I am trying to get up a fixed amount sales rule in Magneto. When I login to admin I go to Promotions --> Shopping Cart Price Rules and create a new rule. When I go to the Conditions tab (From the left menu) I start to create my sale rule condition. When I try to select "Product subselection" from the dropdown menu in the conditions tag. It return and foreach php warning -->
Warning: Invalid argument supplied for foreach() in
/var/www/staging/app/code/core/Mage/Rule/Model/Condition/Abstract.php
on line 246
I've also notice that some of the rules that I've ported over to this magento instance has the same error. But seems to only happen when "Product subselection" is set from the port-over or when I try to create one from scratch.
This link describes similar issue I am having (Sorry it's partly in Russian) http://magento-forum.ru/topic/851/
I've also read that this was a core issue back in 1.5. But was fixed http://www.magentocommerce.com/bug-tracking/issue?issue=11214 (May need to login to Magento to view this issue)
I verified that the code has been updated in app/code/core/Mage/Rule/Model/Condition/Abstract.php on line 246
Can anyone provide me with additional information on how I can go about fixing this bug. I have checked multiple instance of Magento Enterprise 1.10 with the same data set and all have this same bug. Thanks in advance and let me know if I can provide more information.
Since Magento Enterprise Edition 1.10 is based on community edition 1.5, it makes sense to a patch from Magento core team to fix that particular bug. And you will be safe to modify core in this case, since you are applying core code.
The issue was fixed in CE 1.6.0.0. According to the following blame it was fixed by modifying method called getValueSelectOptions()
https://github.com/LokeyCoding/magento-mirror/blame/magento-1.6/app/code/core/Mage/Rule/Model/Condition/Abstract.php#L246
So you just need:
Open app/code/core/Mage/Rule/Model/Condition/Abstract.php
Locate getValueSelectOptions() method
Replace its contents with the following code from changes made by code team:
public function getValueSelectOptions()
{
$valueOption = $opt = array();
if ($this->hasValueOption()) {
$valueOption = (array) $this->getValueOption();
}
foreach ($valueOption as $k => $v) {
$opt[] = array('value' => $k, 'label' => $v);
}
return $opt;
}
Save file and ensure that the issue is fixed.

Categories