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.
Related
I am trying to figure out in which file I need to add the Google remarketing tag. I know it needs to be added before the closing of the body tag. Can anyone point me in the right direction?
Thanks
here is I did in the past:
Depending on what kind of google tracking you are using you have a few different way to use:
1) If only add a custom code and should be in all the Magento page, use the "Miscellaneous Scripts" value going to admin section, System > Configuration > Design > HTML Head - Miscellaneous Scripts. (This will be included before head closing tag in page HTML.)
2) By native Magento already have Google Analytics tracking code and you can find this configuration going to admin section System > Configuration > Google API - Google Analytics.
3) If you are looking something more complex and use the Google adWords I used the extension magento connect link. For a particular Client I did some extra modification to include some extra code if a client subscribe to newsletter or a new client etc.
I hope you can find something helpfully in the post.
Best,
GrinGo.
There are different template file for different pages in magento so at first I think you should decide where to place it.For example if you want to place it in footer than you should place that code snippet in
"app/design/frontend/base/default/page/html/footer.phtml"
Similarly you can check other different template files to place your code.
NB:Best practice is to overide the core file of magento before making changes to it.
Hope this will help.
There's no indication as to which Magento version you're using 1 or 2. At the end of the day it depends how much technical knowledge you have and if you're using a version control system to manage your Magento build.
Miscellaneous Scripts as another answer mentioned earlier, this approach is straight forward and very easy to use to plug and play your code.
Google Module depending which version of Magento you use (CE/EE) there will be a built-in section for you to plugin your account ID in backend Magento configuration and then the platform will generate necessary code for you.
Write custom module by writing your own module you can place it the snippet anywhere on the page by targeting before_body_end node in your layout XML file. This is more technical but gives you more control over what you can do.
Google Tag Manager this also depends on if your Magento version comes pre-built with Google Tag Manager module, then you can create a container and place all your logic in there. This is also more technical and require the output of some values in JS format on the frontend to let GTM read the values.
At the end of the day go with what is easy to setup, portable and easy to manage. I usually go with Google Tag Manager as it takes time to create initial setup of exposing data on the frontend but then I have full control of what I want to do with that data through tag manager. In most cases you'll end up using the same data (ex. totals, shipping method, product IDs, SKUs, cost, etc.) in more than one third party API so this gives you flexibility to do just that.
I just want to create custom html with good css form with my own php as backhand code and javascript for validation.. Is there any extension for this?
I have seen few extensions but none of them allows me to add my own php backhand code.
Thanks
If you are not going to use Joomla's framework, then you may as well build the form outside of joomla and insert it into the article via an iframe (you may need to change the editor's permissions to allow you to do this).
It is worth looking into using the framework properly, however, as it does have easy-to-use mail classes and actually makes things easier when you get your head around it.
(Though to answer your actual question - this module appears to allow you to add raw php http://extensions.joomla.org/extensions/core-enhancements/coding-a-scripts-integration/custom-code-in-modules/3668 )
I m new to joomla world. pls can any1 tell how to use bootstrap size option in joomla 3.0?
and i have 1 more question, what is the use of index.html in every modules folder which has no content in it ?
Second question answer
Web servers list all its directory-content in the browser if there's not present an index.html, making it easy for attackers to click on any of the links and view the contents; worse, if it's a PHP file, which will invariably execute upon clicking. That brings three risks:
Direct access to a PHP file exposes sensitive information (e.g. the
server's path structure) to directly alter codes.
It makes easier uploading hacking scripts to a site through any of
its vulnerable component. This allows for direct web access which
compromises the site.
It reveals the names and size of the site's files and helps
identifying any vulnerable extension, making it an easy target
The index.html files prevent the file listings from such exposures.
The "bootstrap size" option in the module parameters has to be supported by the used module chrome. From the default system chromes, only the html5 one does support it. Depending on your template, there may be other chromes as well which do support it. But since it's a rather new parameter, most templates probably don't support it yet.
I need to develop a magento extension which adds some content to particular pages such as the product view page. More specifically, on product pages, a button/link needs to be added to add the product to a third-party wishlist site.
Now I did some research, and it's not entirely clear what the best approach would be:
Use event/observers to intercept the 'core_block_abstract_to_html_after' event and adding my html there if needed
Use local.xml in app/design/frontend/base/default/layout/ to add my blocks on the correct page using either 'reference' or 'update' tags. However, can I package this local.xml in my extension? And if so, will it not possibly overwrite a user's own local.xml.
Use Magento Widgets? It looks like widgets need to be added manually to a page in the admin CMS panel, while it would be preferred to have a switch in the admin configuration to disable or enable the inclusion of the extra content.
Ideally, a user of the extension would need to do mininal configuration (or XML editing), and the extension must be compatible with existing layouts or modifications done by the user.
There's no single answer here, like anything software related it's all a question of what works best for you, your team, and your users, but here's a few general rules of thumb.
CMS Widgets are for content management. You create a widget when you want to create a simple user interface where store owners can create typed content, which can then be inserted into a page. Not a good choice to distributing an extension that needs to modify a page, or for creating an on/off feature. The ideal use case is a Magento solution provider creates specific widgets and a widget workflow, and a store owners content people update the widgets and add them to pages while managing a site's content.
The local.xml file is for layout updates that are local to this specific store/theme, and require little programatic logic. Your specific mention of adding a local.xml to app/design/frontend/base/default/layout would be a particularly poor choice for an extension you're distributing, as a user would lose this as soon as they added their own local.xml file to a theme. The ideal use case for local.xml is a developer working for a store owner (i.e. has a long term relationship with this particular Magento installation) who needs to build new pages or non-management content/interactive modules. Third party extensions shouldn't add anything to local.xml.
The official blessed way to distribute an extension that modifies an existing page would be to
Create a module
Use that module to add a new layout xml update file (see files like catalog.xml in core modules)
Use this layout update XML file to make your changes
This gives you the same functionally as local.xml, but keeps your code separate from a local user's system code. If you can add your block and implement your feature using only the features of the layout update xml files (block, reference, action, ifconfig, etc ..) this is a good choice.
Finally, there's using a core_block_abstract_to_html_after observer. This will let you add a block using pure PHP. Some PHP developers (myself included) prefer using this method as it's more programmatically transparent than using layout update xml files. The downside of using this method is if you attempt to grab a reference to a block
$block = Mage::getSingleton('core/layout')->getBlock('some_block');
$block->setSomeMethod('foo');
and some_block doesn't exist, you'll get you a fatal PHP error for calling a method on a non-object. That means your observers end up having a lot of code like this
$block = Mage::getSingleton('core/layout')->getBlock('some_block');
if($block)
{
$block->setSomeMethod('foo');
}
One of the benefits of using layout xml update files is these sorts of error silently fail on a production store (although it's that same silent failure that's maddening when developing a feature)
Hope that helps, and good luck! When in doubt, use the technique that lets your get your job done — you can always re-factor later.
I believe Smarty templates has functionality built in that allows you to manage your site URLs from a config file so if something gets moved, you only have to update the URL in one place. Does this sort of functionality exist in CodeIgniter? If not, any pointers or examples on how/where to add it?
For example:
Instead of hard-coding the link it would be: Settings
But where would you want to set $links so that it was available everywhere? Or is it really best to just hard code them?
Take a look at the config class. It allows you to make custom config files.
It's not entirely made for URL's but you sure can use them.
The base url should be basically right at the start of /app/config/config.php, where app is the name of your codeigniter application folder. You access it through calls to the base_url() function.
Yes, it's called Routes, configuration located at config/routes.php. Documentation
If you ask about the rendered html of the links, then your best bet would be using site_url() in conjunction with constants, for example site_url(URL_SETTINGS);, there is no built in functionality for that, but I can say I don't think that is necessary as it would be used too rarely, but it would influence performance every single load.