Notice: Undefined variable: rootNode in C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Eav\Model\Entity\Attribute\Source\Config.php on line 53
Trace:
#0 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Eav\Model\Entity\Attribute\Source\Config.php(53): mageCoreErrorHandler(8, ‘Undefined varia…’, ‘C:\Domains\exam…’, 53, Array)
#1 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Adminhtml\Block\Widget\Form.php(196): Mage_Eav_Model_Entity_Attribute_Source_Config->getAllOptions(true, true)
#2 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Adminhtml\Block\Customer\Edit\Tab\Account.php(54): Mage_Adminhtml_Block_Widget_Form->_setFieldset(Array, Object(Varien_Data_Form_Element_Fieldset))
#3 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Adminhtml\Block\Customer\Edit\Tabs.php(58): Mage_Adminhtml_Block_Customer_Edit_Tab_Account->initForm()
#4 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Block\Abstract.php(642): Mage_Adminhtml_Block_Customer_Edit_Tabs->_beforeToHtml()
#5 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Block\Text\List.php(43): Mage_Core_Block_Abstract->toHtml()
#6 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Block\Abstract.php(643): Mage_Core_Block_Text_List->_toHtml()
#7 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Block\Abstract.php(503): Mage_Core_Block_Abstract->toHtml()
#8 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Block\Abstract.php(454): Mage_Core_Block_Abstract->_getChildHtml(‘left’, true)
#9 C:\Domains\example.com\wwwroot\magento\app\design\adminhtml\default\default\template\page.phtml(58): Mage_Core_Block_Abstract->getChildHtml(‘left’)
#10 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Block\Template.php(144): include(‘C:\Domains\leoa…’)
#11 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Block\Template.php(176): Mage_Core_Block_Template->fetchView(‘adminhtml\defau…’)
#12 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Block\Template.php(193): Mage_Core_Block_Template->renderView()
#13 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Adminhtml\Block\Template.php(81): Mage_Core_Block_Template->_toHtml()
#14 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Block\Abstract.php(643): Mage_Adminhtml_Block_Template->_toHtml()
#15 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Model\Layout.php(526): Mage_Core_Block_Abstract->toHtml()
#16 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Controller\Varien\Action.php(347): Mage_Core_Model_Layout->getOutput()
#17 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Adminhtml\controllers\CustomerController.php(117): Mage_Core_Controller_Varien_Action->renderLayout()
#18 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Controller\Varien\Action.php(376): Mage_Adminhtml_CustomerController->editAction()
#19 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Controller\Varien\Router\Standard.php(248): Mage_Core_Controller_Varien_Action->dispatch(‘edit’)
#20 C:\Domains\example.com\wwwroot\magento\app\code\core\Mage\Core\Controller\Varien\Front.php(158): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#21 C:\Domains\example.com\wwwroot\magento\app\Mage.php(459): Mage_Core_Controller_Varien_Front->dispatch()
#22 C:\Domains\example.com\wwwroot\magento\index.php(65): Mage::run()
#23 {main}

Yes, it screams "undefined variable" which is rootNode but through Magento’s excellent use of object oriented spaghetti, the error does not in anyway reveal what is truly causing rootNode to be undefined nor where to even begin looking.

In AccountController.php and Register.php there is this reference $data = $this->_getSession()->getCustomerFormData(true); and this reference $data = new Varien_Object(Mage::getSingleton(‘customer/session’)->getCustomerFormData(true)); respectively. I’ve searched using grep and within eclipse’s file search but can find no other reference to getCustomerFormData.

I can find no reference to getCustomerFormData other than these two lines of code. So what is this supposed to be accomplishing?

Most of us in ecommerce application development have already heard of Magento. Some would call it new ecommerce killer app. I myself stand with that statement for many of reasons. However I would like to call it with one more name, developer killer app. This developer killer is what I literally had in mind. Magento is currently one of the most difficult PHP systems out there a developer could learn and master. [Source, {}activecodeline, What makes Magento so hard to learn (emphasis added)]

I have put so much effort into learning this system that I both never want to touch it again AND must do more Magento development so that this exercise of gaining knowledge does not go to waste.

Today’s links for Magento success:

• Netbeans
• Eclipse
• ZendFramework
• MAGENTO_v1.3.2.4—Database_Diagram.pdf by ggoodwin
• ZendFramework Quikstart

• Class Mage_Eav_Model_Entity_Setup
• Installing Custom Attributes with Your Module
• Magento Architecture
• ERDs and other diagrams
• database diagrams
• Question about adding selects, radio buttons, and checkboxes to registration form.
• Designing for Magento
• Themeing Magento
• Categories, Products, and Attributes – part 1
• Categories and Attributes in Magento: Part 2

As I work through understanding how Magento handles layouts, I struggle to find a simple list of actions and perhaps I’m trying to hard. So far the is this:

addJs

addCss

addLink

addItemRender

unsetChild

setHeaderTitle

setTemplate

Ah! I found a reference! See page 7 of Magento Layout Files Reference (see also same document, different format).

Update: The Magento wiki has this defined under Designing for Magento.

I’ve been wrestling with Magento for the last month or so and I’m still trying to figure it out.

The general architecture is so mind-numbingly complex, that even if I completely understood it, I’d need to write a book to cover it.

An RFC is a request for comments which "is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems." (Wikipedia) RFCs set the standards that define how the Internet works. RFC3696 and RFC5321 explain that the maximum length of an email address is 254 characters.

There appears to be some confusion over the maximum valid email address size. Most people believe it to be 320 characters (64 characters for the username + 255 characters for the domain + 1 character for the @ symbol). Other sources suggest 129 (64 + 1 + 64) or 384 (128+1+255, assuming the username doubles in length in the future).

This confusion means you should heed the ‘robustness principle’ ("developers should carefully write software that adheres closely to extant RFCs but accept and parse input from peers that might not be consistent with those RFCs." – Wikipedia) when writing software that deals with email addresses. Furthermore, some software may be crippled by naive assumptions, e.g. thinking that 50 characters is adequate (examples). Your 200 character email address may be technically valid but that will not help you if most websites or applications reject it.

The actual maximum email length is currently 254 characters:

"The original version of RFC 3696 did indeed say 320 was the maximum length, but John Klensin (ICANN) subsequently accepted this was wrong."

"This arises from the simple arithmetic of maximum length of a domain (255 characters) + maximum length of a mailbox (64 characters) + the @ symbol = 320 characters. Wrong. This canard is actually documented in the original version of RFC3696. It was corrected in the errata. There’s actually a restriction from RFC5321 on the path element of an SMTP transaction of 256 characters. But this includes angled brackets around the email address, so the maximum length of an email address is 254 characters." – Dominic Sayers

[Source, EPH, Email Address Length FAQ]

Every day I learn something new! (even when I should have known it for a couple of decades)

Links I have used in my work today:

• Font Size Intervals
• Vertical

So now that we are clear that you are probably collecting identifying information about the visitors to your site, do you have a privacy policy? A privacy policy states how you will use that identifying information. For instance, perhaps you sell it to mailing lists. Or perhaps you specifically do NOT sell it to mailing lists but aggregate it to be able to explain to your potential advertisers that 70% of your site’s visitors are women between the ages of 22 and 35.

If you have a privacy policy, as a human, I can follow the link to that policy, read it, and try to interpret it. But why should I do that when I may not even understand what I’m reading? Shouldn’t the browser or other software handle the privacy policy for me? Yes! And on April 16, 2002 the W3C recommended the Platform for Privacy Preferences Project or P3P which is "a machine-readable language that helps to express a website’s data management practices." What this comes down to is that you can set your privacy preferences in your browser and if the website’s policy does not match, the browser blocks cookies from that site. Certainly there is a bit more to it than that but for most users, it boils down to blocking cookies.

P3P is a bit of a pain in the neck but every website (and that means your blogs) should have a privacy policy. This is definitely something I will encourage of each of my clients.

If you are a professional software developer, or aspire to be one, you will need to know a lot of of things. Various maths, stats, languages, frameworks, methodologies, tools, etc. Fads and buzzwords will come and go, all during your career. You’ll master some, ignore some, laugh at some. … You have got to be able to read other people’s code. [Source, Design by Gravity, How to Read Other People’s Code — and Why]

Worthwhile read by Christopher Schanck

Consider the job of a doorman at a nightclub. He has been given a procedure. When someone enters the club, he increases the number on a counter in his hand. When someone leaves the club, he decreases the number on a counter in his hand. He is now given a rule which is as long as the number of people in the club is less than a particular number, let’s say 740, then he should let the person in the front of the line in. Once the counter hits 740, he doesn’t let people in. Nice and simple. Now let’s say the manager has a thing for a certain type of woman so he makes an exception to the rule. Any pretty blond woman under the age of 30 wearing a tank top and skirt above the knees immediate gets in without standing in line. We have introduced several opportunities for error but let’s focus on the most obvious one. If 740 people are in the club and a pretty blond 23 year old in a mini-skirt and tank top walks up, does the doorman let her in or send her to the back of the line?

Back to our graphic artists. When you are designing a layout for a website, the layout is typically created as a single image then sliced into smaller images. If you are designing a horizontal navigation bar, when slicing it up do not make two images 41 pixels tall, one image 42 pixels tall, one image 43 pixels tall, and the creme de la creme, the final image 44 pixels tall, and expect me to easily line up the text below the images. Especially don’t do this when the extraneous pixel height is all white space! Thank you. That is all.

/rant