Can you guys share some pros & cons about Magmi ?
I am evaluating for our Magento 1.12 implementation, Since we are updating feeds frequently also the feed contains huge data.
Thanks.
I've been using Magmi for almost a year now to perform mass Magento imports for wide client base.
Pros:
Very Fast imports (thousands of products in a matter of seconds)
Plugin system that allows you to extend the core functionality of Magmi (extremely powerful for custom data imports)
Surprisingly stable and maintained for the latest versions of Magento
Cons:
Lacks authentication (you'll have to setup some authentication so nobody can access it. It's pretty easy to do) -
Magmi's latest versions now include an authentication layer that requires a Magento Admin Login to access it's UI.
The UI is somewhat unintuitive and ugly (it's by developers for developers. It wasn't made to look pretty)
It will make you realize how silly the standard Magento import methods are (lets face it, they're slow)
For your case (updating feeds frequently), Magmi will work just fine. You can essentially upload a new CSV, and call Magmi either from an HTTP request, or using the included command line functionality. It's very straightforward to setup and easy to maintain.
Related
I have created an ecommerce store, and I'm using PayPal "Add to Cart" Buttons with what they call 'hosted' buttons (PayPal stores the buttons on their servers) for each of my products.
For reference on how they work (and why I use them):
You create a button(product) inside your PayPal Dashboard and you define the quantity available (most of them are 1 in my case)
You copy the HTML code into your website (or just copy the link)
The user buys the product (and the quantity falls -1)
The reason I use this setup is because my website is static, and PayPal provides the Quanity (SKU) Management - so no one can buy a product that no longer exists - even if he can access the button/link.
My Problem
The PayPal GUI dashboard for creating buttons is very time-consuming, I would like to have the ability to edit/create etc. buttons in bulk.
I had search and search for a solution online but have found nothing.
Possible Solution
The only thing I've recently gave some thought was the PayPal Button Manager API and the Ruby SDK in particular, but even if I've studied programming and I'm really eager to keep learning more, I don't know yet what to do in order to make the API calls.
I can't understand from their documentation and I have found zero tutorials online for such a thing.
Failed Solution
As I was familiar with WordPress I tried installing a plugin called PayPal Button Manager but it hasn't the ability to edit in bulk, which is what I'm trying to do.
All in all, I want to:
Create, Edit, Delete, Update in bulk PayPal Hosted Add to Cart Buttons
If using the Ruby API, I would much prefer doing so in a local environment
I'm using Jekyll for my static site, so I'm having Ruby installed and have read multiple times that it's an 'easy' to learn language. But if you can think of something else, I'm open.
If you have Wordpress, then you have a local database, and might end up much happier with a solution that stores quantities locally in that database, such as the WooCommerce plugin, with the following additional plugin for payment: https://woocommerce.com/woocommerce-and-paypal/
Your proposed solution of using PayPal Standard Buttons with the legacy PayPal Button Manager API .. is extremely unconventional in contrast, and would be considered a "terrible, horrible, no good, very bad" hack by most.
difference between create an api using magento
standards and create a php file in the root and
get and send response using simple php code.
is there any security reason we use magento standards ?
any difference in speed of response ?
is there any security reason we use magento standards ?
The standard Magento APIs have been tested significantly more than anything that has yet to be written, so, yes, in terms of security, it's better to avoid writing something custom.
any difference in speed of response ?
Yes, Magento's SOAP APIs are terribly slow. Haven't done much testing with the newer REST API, so I'm not sure if that's any faster.
A third, somewhat obvious, point is that Magento's APIs are already written and can be used on any site out of the box (with minimal configuration). Writing a custom API means that it has to be installed on the site before it can be used.
Also, thinking outside of the box, sometimes it's beneficial to reverse the process. Instead of Foo talking to Magento, let Magento talk to Foo. Of course, this depends on what you're doing, but sometimes this is a much better way of implementing a form of communication between Magento and another system.
I understand that this is a very broad question and could get flagged but I need inputs from experienced programmers and will ask it anyway. If there is another forum where I can post this question, please let me know.
Currently we manage all our application information in an Excel spreadsheet. At a high level it contains an app id, the server names that it is hosted on and the name of the environment. The Excel spreadsheet has become too large and I am looking to build a simple application for it.
Ideally, I would like to write this app on Windows as everyone uses Windows but dont know how to go about it in Windows. I then thought of using MySQL and PHP or Perl (CGI) to build this but thought of exploring something new. I read about Joomla and a few other CMS products which make it very easy to build websites but am not sure whether these allows me to pull information from a database.
I am seeking inputs on what would be a good way to way to build this application.
Use Joomla! CMS is a good choice and to pull data from database you may use webservice calls. So, you will able to create a CMS website using joomla and will able to pull data easily from database with the help of webservice.
You can get webservice support in joomla by installing component redCORE in joomla.
Component: https://github.com/redCOMPONENT-COM/redCORE
Wiki: http://redcomponent-com.github.io/redCORE/?chapters/webservices/overview.md
Other videos: https://www.youtube.com/watch?v=UzJkC7f9fJE
https://www.youtube.com/watch?v=1NRT5jh3Ewc
Joomla dev group discussion https://groups.google.com/d/msg/joomla-dev-cms/3OctbkIZlQw/5d_1MLrzbgYJ
You can also post questions in Joomla forum http://forum.joomla.org/
I think Joomla is a great option to handle big loads of information. If you already know PHP and don't need to reinvent the wheel, it's cool. The way of handling data in Joomla is using Components.
If you want to try, it would be as easy as installing a local copy of Joomla, building the field structure on component-creator.com installing it and importing the data inside the component using phpmyadmin.
I want to build an automated routine that exports orders from Magento to another ERP. I started down the road of the magento SOAP/XML API's. However we are finding this solution slow for large numbers of orders.
Now I realize that the flat order tables (sales_flat_order, sales_flat_item etc) seem to contain all of the information I need. Is this file reliable and kept up to date? Is there anything that I will be missing in this case (other than custom attributes of course). Are these files likely to change in event of upgrade?
Magento API's
http://www.magentocommerce.com/api/soap/introduction.html
Magento Data model
http://www.magentocommerce.com/wiki/2_-_magento_concepts_and_architecture/magento_database_diagram#magento_database_downloads
thanks
Assuming you are using a newish version of Magento (1.4.2.0+) I would say the sales_flat_* tables should be entirely reliable (might be beforehand also, I'm just unqualified to comment). The api works with an instance of sales/order, which is based off of that table anyway.
With regards to custom attributes, if these are something you will need for your export, you can actually make Magento copy the information into the sales_flat_* tables without too much fuss.
Is there any tutorial available for how do i add custom fields on front end check out step like PO number,Job name , customer comments etc as well as in admin->create->order.
My usual motto is to find (and buy if needed) a module that already has the functionality you seek. Especially when the life of this project involves version upgrades because then you can seek a pre-packaged solution from the provider.
I regret every bit of custom code I have added to our Magento install. Because now I've got to maintain the site to just keep working in addition to figuring out my hacks. Time to devote more time to replacing hacks with off-the-shelf extensions, which would have been much faster in the first place.
I know this attitude goes somewhat against the stack overflow thinking of I can do anything, but really, Magento's job is to enable someone to do less work.
Two years later, an update: after the gentle poke of a downvote (probably for appearing to shrug off the question), I am back to revisit and share some of what I've learned. The programming aspect of additional fields is the concept of persistence of the data.
If you're ok with the custom fields only appearing in the transactional emails following the order, then the task is as "simple" as adding the fields to the form somewhere and then updating the controller to to catch and insert the post data into the email. You can use a custom variable in the back end to readily expose this to the email templates. And a Magento SE on programatically creating a custom variable.
Getting persistence into the back end requires adding database fields via an installer in your module. The iCoreThink blog lays out the steps clearly and explains why, how to confirm your work, and then provides real-world implementation, like displaying to the customer in their account. The "other blog" mentioned below has a great example of this, though his example is specifically related to billing and shipping.
Resources from my upvotes and bookmarks:
» This iCoreThink blog post is my favorite reference so far and what I'm following now.
» I was using Templates Master's FireCheckout which includes their own checkoutfields module, but I've abandoned their single view checkout for the flow of Magento's one page checkout. I'm now trying to adapt their checkout fields (and use their controller) into my template for checkout.
» I thought for sure Alan Storm wrote an article about Checkout custom fields, but I don't see one.
» This Magento SE lists a couple blogs and a paid extension. The excellence blog is ok, but his style is too rote for me and I don't learn anything. The other blog discusses the procedure for building your module and installing the database fields.
» The unexpected-IT blog demonstrates and informal hack to add the code to core files (but sadly doesn't show how to override those files by copying them to app/code/local) and the steps to manually perform to get the column and fields added in the database. Apparently is perfect for 1.4 and below, but comments seem to explain what to do for 1.5 and up.
This last hack-ish change is my personal favorite as it seamlessly adds the extra bits into existing Magento admin pages and "feels like" less work. Caveats: I wouldn't do this without using version control and it will absolutely break if any core code changes happen between version upgrades.