Why does magento use xml files for themeing? [closed]

Your answers, in turn:

"I don't understand why Magento uses XML for theming."

In many MVC systems, determining what content and data are available in the view means dealing with (creating & customizing) controller actions. Layout XML gives even frontend developers the ability to add and remove view elements and their data ("Blocks" in Magento) to different routes without having to rewrite action controller classes.

"I read that I need to create local.xml declaring what gets in and out of the theme."

Not necessarily. If you have no customizations of layout XML, you won't need a local.xml file. Moreover, if you have layout XML customizations for ONLY the homepage, you can add your layout update XML to the page data via the CMS admin.

"[W]hy [is] the CSS/JS/media directory is completely separate from the template directory[?]"

This is simply a security feature. All files under ./skin can be directly accessed via the browser, and all files under ./app cannot be accessed via the browser, including theme-related files under ./app/design. Is this a logical, developer-friendly strategy? Not at all, and Magento is addressing this in Magento 2, which is available on github.

"[Why are there] a million directories (sarcasm) that I need to get into to make a modification[?] I assume they are using some kind of MVC model but it is by far nothing I have ever seen."

Magento is indeed an MVC framework, and a robust one at that. It is, as you've noticed, quite distinct, especially in the PHP frameworks realm.

• Models are PHP classes under app/code/[codePool]/Namespace/ModuleName/. By convention, they are under the Model directory. They come in three general flavors: data models, which conventionally reside directly under the Model/ directory, and resource models & resource collections which conventionally reside under Model/Resource as of Magento 1.6.
• Views are PHP classes which conventionally reside under app/code/[codePool]/Namespace/ModuleName/Block/. They may or may not be rendered along with template files (.phtml). Unlike many MVC frameworks, Views in Magento often load their own data independent of route / action.
• Controllers are PHP classes which are found under app/code/[codePool]/Namespace/ModuleName/controllers/`.

"If they are attempting to make pretty URLs with all these directories I'm pretty sure they have heard of htaccess."

Not at all. The only thing which connects URLs to action controllers is configuration (this is true of all MVC classes outside of the Mage namespace). SEF URLs are achievable via configuration in multiple ways as well as via database rewrites which may be found in core_url_rewrite table. Magento does use an .htaccess file only as a means of routing appropriate requests to the system entry point, index.php.

"I looked into the phtml files and most of them look like their just calling these XML elements, is it possible to use plain old HTML and PHP to create a theme? Or am I forced to use their XML methods?"

Templates are dumb. They are pointless without the View class in which they are rendered - literally included()ed. The methods and data available to them come from their (often) layout-configured View class. For an example of view configuration, see app/design/frontend/base/default/layout/cms.xml: the <block type="core/template" name="page_content_heading" template="cms/content_heading.phtml"/> line declares an instance of Mage_Core_Block_Template with the cms/content_heading.phtml template from the frontend theme.

"[T]he theme folder at app/design/frontend has two folders base and default which im thinking each of these are interfaces for example a group of themes i would like to use. i modified the design_change db"

It's good that you are investigating these things; an explorer's approach will be helpful as you learn the framework. Themes in Magento are defined by three components: an area (frontend or adminhtml), a package name, and an actual theme name. In the filesystem, these settings map out to two places, as you've noticed. They are ./app/design/AREA/PACKAGE/THEME/ and ./skin/AREA/PACKAGE/THEME/. There are two more aspects to theming in Magento: theme asset type and fallback.

There are four theme asset types: layout, template, translation, and skin. The path that the system uses to find a given theme asset is based on configuration as well as some hardcoded paths. The absolute fallback point for theme assets is the base package's default theme. Appropriate Magento configuration has you first declaring a package (e.g. 'my_package' under System > Configuration > Design. With no theme settings declared, the system will simply look for assets under the default theme; this would map to app/design/frontend/my_package/default/template/. If you were to declare a "Templates" theme in Design configuration (e.g. "my_templates", the system would first look there and then look under the default theme. There is also a "Default" configuration setting which, if set, will be used for all theme asset types (e.g. "my_default"). This is all happening in Mage_Core_Model_Design_Package and it looks like the following; we'll use our example settings and the "cms/content_heading.phtml" param from above:

1. app/design/frontend/my_package/my_templates/template/cms/content_heading.phtml (if found, use this one, don't look anywhere else)
2. app/design/frontend/my_package/my_default/template/cms/content_heading.phtml (if found, use this one, don't look anywhere else)
3. app/design/frontend/my_package/default/template/cms/content_heading.phtml (if found, use this one, don't look anywhere else)
4. app/design/frontend/base/default/template/cms/content_heading.phtml (if not found here, someone screwed up, and an exception will be logged to the system log at ./var/log/system.log)

This design fallback is used for two reasons: allows failsafe places for developers to store theme assets (base/default) and allows for multistore reuse and DRY overriding of theme assets.

That said, this is not an ideal architecture, and as mentioned, this is going away in Magento 2 - all theme assets will be stored inside their respective module's directory.

Only reading will be able to help you much here. Once you get the hang of it, the xml layouts are pretty handy, it's just a pain learning how they work.

You can indeed ignore a lot of the xml stuff if and just put stuff inside the template files, but as you will read from other sources, it's not always best practice to work this way (though I'm sure every Magento developer does it on occasion).

Your best reference is often the Magento code itself. So long as you never touch anything inside base/default, you will always have a reference of how it's "supposed" to work.

Magento is definitely a Swiss Army Tool. You can get things done in many ways, each of which has it's pros and cons. Sometimes hardcoding stuff into templates/layouts is the way to go... sometimes you need to use static blocks and CMS (if a client wants to be able to edit something, for example).

Again, keep at it.. it is certainly frustrating to learn, but you will eventually pick up on the nuances and will start to feel more comfortable.