Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
If you have trained a new Magento developer what were some if any dummy tasks you have given them. Besides reading all of the articles out there and doing the examples, I am looking for some ideas to give developers to work on after reading as much about Magento as they could without actually working on a task.
If anyone has any good ideas please let me know, You can even post some good code snippets of possible answers and what not. This might be a good thread to keep if we get a lot of good answers, for us tech leads out here responsible for training.
They could be frontend design template or building modules, it doesn't really matter. If someone posts a really good example, I will mark that one as the answer.
Not sure this is appropriate for Stackoverflow, but not sure where else to put it where it would be answered with quality responses.
The tasks I've given before really depend on what the developer needs to do as part of their normal job. I tend to give tasks that force the "rabbit hole" situations early on in the process, and make sure that the developer has enough support to come and ask when they get stuck.
For frontend developers, the best thing to do is develop an actual theme, or whatever tasks need to be accomplished in some current project. As examples, ask them to:
Create a new theme directory w/ skin directories, etc
Change a template (the product/list.phtml and product/view.phtml are both common here) to accomodate some desired new functionality.
Add a JS lib to the product page for zoom or some other functionality, to be loaded cleanly using Magento's facilities.
Create a new page, including complete controllers and layouts as appropriate, with functionality to be fleshed out by a backend developer.
Change the CSS to the One Page checkout to fit the new site theme, without breaking CSS for the rest of the site.
For backend developers, again the best thing is the real thing. Developing backend modules takes some significant familiarity, but hitting the highlights isn't too bad. Examples:
Start a new Magento module.
Override a core Magento class with one from the local module
Create some administrator functionality to deal with the new module.
Add an ACL so that this functionality can be enabled / disabled for particular admin users.
Integrate with frontend code (see the frontend developer above) to provide the functionality to the end user.
Append to the system configuration to use the new functionality as part of the normal system.
These are just general ideas, but they will quickly force a developer to gain some understanding of the way Magento is laid out and how it operates. Of course, it can take weeks or months of supportive mentoring to get the developer to the point where they are a self-sufficient developer on Magento, but that's largely a matter of filling out the details after items like this.
Hope that helps!
Thanks,
Joe
This is what we send applicants to see if they even know what magento does/how it works ... not sure if this is what you meant ...
Please perform the following:
Override a controller action:
Override the Mage_Customer_AccountController keeping all the original functionality except that the logoutAction redirects to the home page immediately not the logoutSuccess page.
Override a model function:
Override the Mage_Customer_Model_Customer model keeping all the original functionality except that the getName() function always returns "Magento Rocks".
Modify a Block:
Change one of the blocks used on the customer/account/index page to display a message of your choice.
Add an Observer:
Add an observer so that after the order has been created on the frontend the last name gets changed to "Is Awesome"
Its not really practical ... at all ... but it lets us see if people can code in Magento in a decent way instead of just modifying core files and such. As with almost anything in Magento there are different ways to accomplish the various tasks, perhaps have them figure out the different ways or have them determine which way would be most appropriate.
Note: Just to emphasize so that no one points it out, these "tasks" were not designed for practical use and in fact you probably will NEVER do any of these, they were intended to see if someone could actually do things (override a model method etc) the Magento way.
Related
I am trying to help out an organization that hired some developers to create their website back in 2016, and the developers haven't touched the site since 2016.
I don't know enough about Sage to know if the developers really screwed things up, or if what they have done is the way things need to be done in Sage. One example of something that has me scratching my head (in between banging it on my keyboard): some page content - content that needs to be updated on at least a yearly basis - is hard-coded into template files, so that in order to update the information, you have to go in past the warnings about using the Theme Editor, figure out which included template contains the content, and update it there.
NOT something your typical office employee is likely to be able to do, yes?
My question is: is it even worth trying to keep this site running under Sage, or should I rebuild the site using a more user-friendly template? The site currently has fewer than 2 dozen pages plus a dozen or so posts and I would say is unlikely to get a whole lot larger, given the available resources.
Thanks for any advice you can offer.
The problem to me doesn't seem to be so much about the Roots Sage theme framework, but that the developers didn't follow the most basic rules regarding WordPress theme development--separating the content from presentation. Hardcoding content into a template is just bad practice, and this would make any site difficult to edit no matter what framework it was built on.
If it's as simple as printing the content into a template so that page editor content changes can be reflected on the frontend, it may be a simple as adding the_content() to the corresponding page template overrides and removing the hardcoded content.
FWIW: Sage 8 templates are not that different from your standard WP templates, it's not using a templating engine like Blade, so you should be able to customize the templates if you're already familiar with standard WP templates.
So probably no need to burn it all down.
I'm developing a site for my company and I also need to modify the native component "mailto" to fit our needs.
I'm working with a joomla 2.5
I was wondering if future updates occur, what will happen to the lines I've added, for example, in "\components\com_mailto\controller.php"...
I haven't find answers on the net.
Also, for the same reason, I've modified the default layout of an article. Should I rename it? and if yes, how, because I couldn't do it (when I've tried the article did not display).
Thanks for your help
Before starting to edit core Joomla components, should should always have a look at the options you have. I don't believe in editing core file as it simply causes problems for updates when released, therefore in my opinion, you have 2 options:
I always make a note of all my requirements and start looking for a 3rd party extension that caters for my requirements.
If I cannot find a 3rd party extension and don't particularly want to start digging into it's code, I would go with developing a plugin. Plugins are used to manipulate the behavior or something and therefore come in extremely handy for when you would require core editing.
Editing the layout of an extension view is completely fine, but it's strongly recommended you make a Template Override so that if the extension does ever get updated, your changes won't get overridden.
So to answer you initial question, any line you have added to the controller.php file will get overridden when you decide to update the extension.
Hope this helps
While the answer from Lodder is totally valid, as a last resource you can also consider forking the com_mailto as a separate component.
This has some disadvantages:
you need to rename all the files involved (controllers, models, views)
you need to maintain it and keep in in sync with future updates (consider than you are now on 2.5.x and in a year you might want to upgrade to 3.x).
i'm trying out joomla! CMS, and in my job we're very fond of one-page sites. Is there any way of making a fully functional website with it? The main reason we need the CMS is because of the way the client wants to update they're webpage.
Ok before you do anything, have a real think to yourself, is Joomla really the best option? Your client requires a 1 page website, therefore what would be the point in loading a full blown CMS just for that. Joomla, when zipped up, is more or less 8MB. Out of all honestly, I would even find the likes of Wordpress still too big for a project of this size.
What I would really recommend is having a look round on the web for a very small CMS that simply includes a small backend with the ability to create, update and delete articles.
Have a look at this for example:
http://www.elated.com/articles/cms-in-an-afternoon-php-mysql/
This would be a brilliant way to start. It has a small backend for you to manage articles, and you can start building up a completely custom template, exactly to your client's liking. I'm not too sure on the programming skills but if you're fairly new to it, then this would be a good place to start and gain knowledge.
Given that the above is what I would personally recommend, you may not want to do that or may not have the time, therefore if you really want to stick with Joomla, you should find a template that fits your needs in regards to module positions. Else you can add your own custom positions to the template. Have a read through the documentation as it will give you the necessary information
Hope this helps
I was looking for a solution myself for quite a while. I came up with the following two soutions:
Like #mattosmat said for a joomla one page site the simplest solution actually is it to declare one section as the main componenent and create the other section with cusom-made joomla modules.
Use wordpress with the advanced field plugin to create a single-page website.
Actually if a clients wish is it to create a single page website with cck and cms features i create these projects in wordpress and not in joomla anymore in my opinion its the wrong plattform.
I Have One Word!!!
BOOTSTRAP!!!! IS the way to go.. simple,succinct,beginner friendly. Doesnt matter if you really make it in Joomla! or anything else.
And for head start, look up "Scrollspy" in Bootstrap.
I have been learning to develop my own plugins and components for joomla! 2.5.
After a couple of months of developing features for my site, I am starting to realise that some of the components I have created could have probably been just as effective if I'd developed them as a plugin for com_content or com_user.
My question is what's the best way to decided if a full component is needed and when is it ok to use one or multiple plugins to give the same functionality.
My feeling at the moment is that plugins are a much nicer way to go due to them being self contained. Maybe I've answered my own question, and components are needed when interaction between elements is more complicated, where as plugins can be used for very modular functions.
Anyone else have a view?
Components and Plugins are completely different types of extensions.
Components are applications/systems that will appear in the content area such as VirtueMart and where the articles are shown. Consider them as software for you computer.
Plugins are there to manipulate Joomla and/or there extensions it's using. They contains functions that are associated with trigger events. So in a nutshell, they are there to extend the functionality of an existing extension.
So so answer your question, have a think about what you are creating and if will be an aplication or something to extend functionality.
Hope this helps
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I want to insert google analytics tracking code in my joomla site.
so i registered in the official site of google and saw there is an advanced tab with three more options than standard.
Do i have to check "i want to track dynamic pages" and "i want to track php pages"?
Do these options provide me better results or they are necessary for a dynamic site based on php like joomla?
Also where do i place the tracking code? Because of some bugs some say it is better just after the tag whereas other say just before the tag.
Thank you
General SEO advice: with Joomla you don't need to track pages dynamically, if you want, you can turn on SEF and use robots.txt, ror.xml and sitemap.xml (the first and last files are very important to google).
I also recommend on using Google webmaster tool to update Google whenever you post a new article as well as to check if there are crawling errors and remove "bad" URLs from google.
Like I commented on the other answer, tracking code should be located just before the closing tag for your web page - I recommend on placing the tracking code in the template! (even though you can copy and paste it separately into each article - this option should be done only on rare cases that you need to pass different parameters to GA from different articles.
Update:
Regarding your comment: yes, if you go to the "admin" section, then to "tracking code" you'll see the following option:
All it does is provide a different way of including the tracking code in your pages. I got to admit that I didn't use this option with a few Joomla and WP websites I've dealt with, and it still works totally fine. But if Google recommend on doing so - by all means go ahead and do it!
Judging by this source on setting up GA, it is important for PHP websites that you include the google tracking script at the bottom of the page before the </BODY> tag. I'm struggling to find any information that would give relevance to the questions you have mentioned above, beyond the fact that choosing different checkboxes shows you different instructions to setting up your script.