we are using magento with onestepcheckout module in our shopping system. But when the payment process fails and when we get an error about payment, not all but some translations fails on the checkout page.
Has anybody face this problem before. I will be very happy if there is an solution.
P.S. I can solve the situation by hard-coding the translations. But I dont want to use this method.
Thank you
When a module developer creates a module, it's up to them to make sure that each and every phrase that could be translated is marked for translation. In Magento this means
Strings in template files are passed through the ->__ method
Labels, parameters, and other strings in XML fiels are marked with translate attribute
As an individual developer, if you're not developing applications/modules intended for translation it's easy to fall into the habit of not doing the above. Also, the areas of Magento's XML configuration system that can (vs. can't) be translated aren't well documented. It's easy to miss a string or two, and localization (along with everything else) is almost never tested.
All of which is a long way of saying, contact your vendor and file a bug. If you want to play capitalism, since you've already hard-coded the translations, fix the core problem yourself and offer to sell the solution back to the onepage people.
Related
I want to make an extension that injects videos on product pages.
I already read a lot of documentation in Magento website but, sincerely, I have no clue where to start. What's the difference between Magento Extensions and Widgets? Can I develop my extension using only JavaScript? Do I really need to use PHP to develop one?
So many questions, can't find a focus. Can you please share a simple follow trough for me to read on? Thanks.
Credits : Marius
https://magento.stackexchange.com/questions/8344/how-to-write-a-custom-extension/8345#8345
Here is what I usually do:
Always develop with error_reporting on.
Always develop with isDeveloperMode set to true. Just add SetEnv MAGE_IS_DEVELOPER_MODE 1 to your httpd.conf file (or corresponding file for nginx or something else)
If the extension is linked to a core functionality add the
dependency in the declaration file <depends><Mage_Catalog /></depend>
If the module is for community use, use community as codepool to
give the developers the chance to override some classes without
modifying the code directly
Put your frontend design files in app/design/frontend/base/default
to make them available for all themes.
Put your admin design files in
app/design/adminhtml/default/default and do not change the admin
theme. I may want to change it in one of my modules.
Prefix your layout file names and template folder name with the
company name to make it easier to isolate them.
easylife_articles.xml and app/design/.../easylife_articles
Put your static resources (js, css, images) in a similar folder as
the template files easylife_articles/images/doh.png
Attach a simple text file with how to uninstall the extension: What
files need to be removed, what tables need to be dropped, what
config settings need to be removed from core_config_data table.
Do not write queries directly in models, blocks or helpers, use a
resource model for that.
Do not write queries using the table names directly Select * from
sales_flat_order where .... Use a Zend_Select and transform the
table names using ->getTable('sales/order').
Use the base url to include js files in template. Wrong
<script type="text/javascript" src="../js/some.js"></script>.
Right <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
Do not rewrite classes unless is necessary. Use observers and if
it's not possible use helper methods that receive as parameter and
instance of a class that you wanted to override. Wrong:
Override Mage_Catalog_Model_Product to add the method
getProductArticles(). Right. In your helper add
getProductArticles(Mage_Catalog_Model_Product $product)
If you override classes put a list of them in a readme.txt file
Use the default admin path for the admin section of your module.
Wrong admin url articles/adminhtml_articles/index. Right admin url admin/articles/index
Add ACL for your admin sections. I may want to restrict access to
some of the admins.
Do not add an other js framework (jquery, mootools, ...) if it's not
necessary. Write you code in prototype.
Make you template html W3C valid (this is for OCD developers like myself).
Do not put images in the media folder. Use skin. The media
folder usually is not versioned and this makes it harder to move the
website on different environments.
Test you extension with flat catalog on and off. In order not to double the development time use Chaos Monkey
Test your extension with cache on and cache off.
Avoid using uppercase letter in the module and class names. If not
properly tested this may cause issues on different OS. This is more a recommendation, not a 'must'.
Dispatch events in your code to make it easier for developers to
alter the functionality.
Follow the same coding standards that Magento uses and comment your code.
[Edited] Do not use php short tags (<? $this->doSomething() ?>). Use full tags (<?php $this->doSomething()?>). Also don't use short echo tags, yet. (<?="D'oh";?>). Use (<?php echo "D'oh";?>)
Translate your texts using $this->__ and add the locale translation file with your texts (app/local/en_US/Easylife_Articles.csv) at least for en_US language. Not all
websites are build in English and the identification of texts to
translate is time consuming.
If you sell an extension offer at least basic support. Or at least
answer the support e-mails you receive.
Do not make constant calls to your servers through your extension for licence validation. Once, at installation is more than enough (I don't like this approach either, but it's better than to make calls all the time).
(Inspired by this question)
Develop with the log activated and from time to time take a look at
the var/log/system.log file. The errors listed here are not shown
even with developer mode on. If there is at least one error you end
up with a large log file after a few months of running the extension.
If your extension affects the checkout process or the orders in
some way, make sure it works with multi-shipping, or if it
shouldn't work with multi-shipping, make sure it doesn't affect it.
Do not replace the default Admin Notification bar (or feed URL). If
I'm interested on what you have to offer I will subscribe to your
newsletter. Let me see what Magento has to say. It's more important
to me.
If you encrypt your code files with Ioncube (or something
else)...well...I just hate you and I hope your business goes bankrupt
That's what have so far. I will add more as soon as I think of something else.
You will definitely need XML and PHP, because this is mainly what Magento is built on.
Additionally to the official documents, there are a lot of helpful and very diverse tutorials out there that explain the mechanics of Magento. A web search helps, and I can recommend everything by Alan Storm, for example this litte module: http://alanstorm.com/magento_list_module
As soon as creating an extension works for you, you will also find a lot of tutorials on how to alter the product-view, or you can then post a more specific question here or on magento.stackexchange.com.
I am new to this software. I was just wondering how to create/edit/check header, side, and footer link. What I have noticed so far from numerous searches is that it requires some type of actual manual programming. And also if it is not a template, I would have to add it through Static Blocks or Edit it through a .phtml/.php/.xml file which I have no idea to do. Assume I have the latest software. Any help is appreciated.
You can create a shop in english without manual coding at all. But you will get the result you asked for. A hard application without any customisations which probably will not be valid IRS-wise(for example, the invoices in Greece have to contain very specific things. If not they are not valid and you get fined.). The header and the footer are customised by Static Blocks from the backend of Magento without trouble. You will have to search for a documentation of your template ofcourse. There are so many information and we cannot give it to you with just one post. You will have to study and ask the right questions!
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.
i'm in the process of adding a US site to my current UK site. I'd like to do this as transaprently as possible so that we don't lose any traffic to existing links. We're currently running this under version 1.4.1.1 of Magento on a shared hosting setup.
The new website (US) will be essentially the same as the current (UK) site, but with US Dollar pricing instead of Pound Sterling.
We currently have a GeoIP setup whereby visitors are redirected to either UK or US site whilst utulising the same URL. This essentially means that we have switch statements in our index.php to indicate what run code to use.
Here's my question:
what's the best way of selecting/overriding the GeoIP selection via the standard store switcher selector dropbox? Both websites are being populated in the dropbox, however, since both are utilising the same URL (www.example.com/boutique) the default one is the only one that's being selected.
I've also tried the &_store= as well as the &_website= arguments with no success.
Any ideas? are URL rewrites in .htaccess the answer? if so, any ideas as what to use?
P.S. this is the method that's pretty much being followed however my aim is to let users override their location-specific website (e.g. US) if necessary:http://www.magentocommerce.com/wiki/4_-_themes_and_template_customization/navigation/multiple-website-setup#multiple_website_setup_for_useuuk_storespricing
Have you tried using a getUrl() method to build the store arguments for you? It can help clear up those little misunderstandings, for example I'm pretty sure the store parameter is supposed to have three underscores but cannot really remember so I use the function instead.
The best way to over-ride is to have a little php program, e.g. 'countries.php' that sets a cookie depending on the country code that you choose or 'auto' to test regular geoip. Then in your index.php have an 'if cookie then use cookie code else use geoip code'. Naturally the cookie can only be set by your test program.
And yes, you only need set 'website' not 'store'. There is no benefit in your US customers being able to see your UK prices (and vice-versa) so don't even bother with setting up a frontend drop-down. Or, if you really want, you can have rest-of-the-world customers choose their currency/website and put your own cookie-setting code in the header for them, with a couple of nice flag icons.