<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ActiveCodeline &#187; upgrade</title>
	<atom:link href="http://activecodeline.com/tag/upgrade/feed" rel="self" type="application/rss+xml" />
	<link>http://activecodeline.com</link>
	<description>Blog site of Branko Ajzele, web application developer.</description>
	<lastBuildDate>Tue, 07 Sep 2010 05:59:18 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Magento upgrade and broken templates</title>
		<link>http://activecodeline.com/magento-upgrade-and-broken-templates</link>
		<comments>http://activecodeline.com/magento-upgrade-and-broken-templates#comments</comments>
		<pubDate>Sat, 02 Aug 2008 19:16:29 +0000</pubDate>
		<dc:creator>branko</dc:creator>
				<category><![CDATA[Magento]]></category>
		<category><![CDATA[template]]></category>
		<category><![CDATA[upgrade]]></category>

		<guid isPermaLink="false">http://activecodeline.com/?p=56</guid>
		<description><![CDATA[Few days ago I had a task of upgrading Magento ver. 1.0.19870.1 to Magento ver. 1.1.1. When you are doing something like that on your own development machine, you probably don&#8217;t care much about backing up your database and installation folder. On my development machine I had a clean install of version 1.0.19870.1 where I [...]]]></description>
			<content:encoded><![CDATA[<p>Few days ago I had a task of upgrading Magento ver. 1.0.19870.1 to Magento ver. 1.1.1. When you are doing something like that on your own development machine, you probably don&#8217;t care much about backing up your database and installation folder. On my development machine I had a clean install of version 1.0.19870.1 where I merely entered few products, categories and other minor things. I had no other theme besides custom one. Before I was ready to do a update to real, shared, remote development machine I decided to test the update on my machine. </p>
<p>Performing local update went smoothly as it gets. On my surprise, everything work as it should be. I was convinced I can go and make upgrade to remote development machine. I had no SVN setup to my remote machine so all my code transfer was done trough FTP. Basically if you&#8217;re performing your upgrade trough full archive file all you need to do is copy content from archive to your root Magento installation and overwrite everything you&#8217;re asked to overwrite. Sound&#8217;s easy, doesn&#8217;t it? Well it is easy and your upgrade should go clean and without any glitch, that is if you are using built in theme. If you&#8217;re using a custom made theme, chances are you&#8217;re rune into trouble like i did.<span id="more-56"></span></p>
<p>Magento is a very modular system. If you do a little check on default archive for Magento version 1.1.2 (latest, as of time of this writing) you will see it contains 6 383 files across 2 171 folders. This is huge number of files if you ask me. Magento&#8217;s philosophy for <a href="http://www.magentocommerce.com/design_guide/articles/how-magento-builds-content">building themes</a> is somewhat complex. When i say complex i don&#8217;t think in terms on hard to learn but in terms of everything is co cut up into meaningful peaces as they say. However, number of this meaningful peaces is huge. This alone is not the problem, although will take some time getting around. Problem is in the PHP code inside those meaningful little peaces.</p>
<p>Let me be specific. If you want to change something in your checkout page, let&#8217;s say make it different then it is in the default template then you go and create your theme according to the <a href="http://www.magentocommerce.com/design_guide">manual</a>. Then you realize, that if you want to change checkout page you need to change app/design/frontend/default/your_theme/template/checkout/cart.phtml to suite your needs. You do stuff like calling some Magento helper functions, modifying HTML, adding all sort of styles and so on. Magento works by first looking for files within &#8220;your_theme&#8221; folder. If corresponding file is there it will pick it up, if not it will use it&#8217;s own from the default theme. This is very modular if you ask me. However, there is one problem to it. What if someone deleted some helper or some other function you used inside your theme file? Well you would get errors and your online Magento powered shop would fail to work.</p>
<p>When you do upgrade you overwrite files from default theme folder. However, you preserve all the old files inside your custom theme folder. These are the files that worked with Magento version before the upgrade. In order for them to work after the upgrade all the functions called from this template should be existing. I&#8217;ve read a response comment on Magento forum where some said &#8220;templates for *** have changed significantly&#8221;, probably meaning something like &#8220;you&#8217;ll have to change your theme significantly because of it&#8221;.</p>
<p>I&#8217;m not here to judge Magento because of this. It&#8217;s a great product, it&#8217;s free, it has very bright future and so on. I&#8217;m just trying to lay out my conclusions. I was pretty surprised when my Magento shop broke after upgrade, when some things started disappearing and so on. On the other hand, it was quite good experience from which I learned a thing or two about Magento. And one advice before and after the upgrade; try to switch your site to default theme and first do a full check to see if everything is working here. If it is, then you&#8217;re ready to bug hunt your theme.</p>
]]></content:encoded>
			<wfw:commentRss>http://activecodeline.com/magento-upgrade-and-broken-templates/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Upgrading Magento using full Magento installation archive</title>
		<link>http://activecodeline.com/upgrading-magento-using-full-magento-installation-archive</link>
		<comments>http://activecodeline.com/upgrading-magento-using-full-magento-installation-archive#comments</comments>
		<pubDate>Thu, 31 Jul 2008 15:38:25 +0000</pubDate>
		<dc:creator>branko</dc:creator>
				<category><![CDATA[Magento]]></category>
		<category><![CDATA[upgrade]]></category>

		<guid isPermaLink="false">http://activecodeline.com/?p=51</guid>
		<description><![CDATA[If you look at Magento, or any other CMS system out there you can apply some basic logic to them. First of all, every system has some kind of configuration file. Every system stores it&#8217;s data (articles, posts and so on) inside the database. Every system has some content holder folder for storing stuff like [...]]]></description>
			<content:encoded><![CDATA[<p>If you look at Magento, or any other CMS system out there you can apply some basic logic to them. First of all, every system has some kind of configuration file. Every system stores it&#8217;s data (articles, posts and so on) inside the database. Every system has some content holder folder for storing stuff like images, pdf files, music and so on. Let&#8217;s look at WordPress as a comparison. WordPress uses “wp-config.php” to store relevant database information. Magento uses “app/etc/local.xml” to store relevant database information. Conclusion one: this is the first file you need to backup.</p>
<p>Next, let&#8217;s look a the their system files. Most of them if not all, do not change during their lifetime. Meaning, only few configuration files are subtle to change while other remain same as they were during the original archive package download.</p>
<p>To keep it short; in order to upgrade Magento you could do copy &gt; replace on entire Magento installation aka root folder. The only thing you need to exclude is the “app/etc/local.xml” file.<span id="more-51"></span></p>
<p>However in order to be on the safe side follow these few basic steps:</p>
<ol>
<li>Backup entire content of your root Magento folder</li>
<li>Delete all content of the folders “/var/cashe/” and “/var/session/”</li>
<li>Download new full Magento installation package from the Internet</li>
<li>Un-archive downloaded Magento installation package</li>
<li>Copy (with overwrite) entire  downloaded Magento installation package into the root of your site</li>
<li>Go back to your Backup and Copy back (with overwrite) your “local.xml” file containing database connection information</li>
<li>Reload your site (it should be upgraded now)</li>
<li>The URL PROBLEM&#8230; Chances are that your site will work but clicking on some of the links will get you no where. This is .htaccess problem. Just copy the one you have in your Backup folder onto your FTP and it should work.</li>
</ol>
<p>This article is a direct result of my todays first live update to a Magento site. My task was to update Magento ver. 1.0.19870.1 to Magento ver. 1.1.1. It worked like a charm. My biggest issue was the FTP. There were approximately 5 thousands files to download for backup and about 7 thousands file to upload.</p>
]]></content:encoded>
			<wfw:commentRss>http://activecodeline.com/upgrading-magento-using-full-magento-installation-archive/feed</wfw:commentRss>
		<slash:comments>23</slash:comments>
		</item>
	</channel>
</rss>
