magento / magento2 Goto Github PK

Prior to making any Submission(s), you must sign an Adobe Contributor License Agreement, available here at: https://opensource.adobe.com/cla.html. All Submissions you make to Adobe Inc. and its affiliates, assigns and subsidiaries (collectively “Adobe”) are subject to the terms of the Adobe Contributor License Agreement.

Home Page: http://www.magento.com

License: Open Software License 3.0

HTML 8.21% PHP 83.24% JavaScript 5.35% CSS 0.57% VCL 0.02% Less 2.60%

magento magento2 php ecommerce-platform ecommerce hacktoberfest

magento2's Introduction

Magento Open Source

Welcome to the Magento Open Source project! Magento Open Source software delivers basic eCommerce capabilities to build a unique online store from the ground up.

However, for those who need a full-featured eCommerce solution, we recommend Adobe Commerce, which includes our optimized cloud architecture and hosting as well as AI-powered merchandising and analytics.

Get started

Get help

Help center

Contribute

Our Community is large and diverse, and our project is enormous. As a contributor, you have countless opportunities to impact product development and delivery by introducing new features or improving existing ones, enhancing test coverage, updating documentation for developers and end-users, catching and fixing code bugs, suggesting points for optimization, and sharing your great ideas.

Maintainers

We encourage experts from the Community to help us with GitHub routines such as accepting, merging, or rejecting pull requests and reviewing issues. Adobe has granted the Community Maintainers permission to accept, merge, and reject pull requests, as well as review issues. Thanks to invaluable input from the Community Maintainers team, we can significantly improve contribution quality and accelerate the time to deliver your updates to production.

Leaders

Adobe highly appreciates contributions that help us to improve the code, clarify the documentation, and increase test coverage. Check out our Community leaders, superstars, and superheroes on the leaderboard.

Labeling

We use labels in the GitHub issues and pull requests to help the participants retrieve additional information such as progress, component assignments, or release lines.

Labels applied by the Community Engineering team

Security

Security is one of the highest priorities at Adobe. To learn more about reporting security concerns, visit the Adobe Bug Bounty Program.

Stay up-to-date on the latest security news and patches by signing up for Security Alert Notifications.

Licensing

Each Magento source file included in this distribution is licensed under OSL 3.0 or the terms and conditions of the applicable ordering document between Licensee/Customer and Adobe (or Magento).

Open Software License (OSL 3.0) – Please see LICENSE.txt for the full text of the OSL 3.0 license.

Subject to Licensee's/Customer's payment of fees and compliance with the terms and conditions of the applicable ordering document between Licensee/Customer and Adobe (or Magento), the terms and conditions of the applicable ordering between Licensee/Customer and Adobe (or Magento) supersede the OSL 3.0 license for each source file.

Communications

We are dedicated to our Community and encourage your contributions and welcome feedback through events, our DevBlog, Twitter and YouTube channels, and other Community resources.

To connect with people from the Community and Adobe engineering, join us in Slack. We have a channel for every project. To join a particular channel, send us a request at [email protected], or sign up.

Popular Slack channels

If you are a new Community member, check out the following channels:

general is an open chat for introductions and Magento 2 questions
github is a support channel for GitHub issues, pull requests, and processes
public-backlog for discussions of the backlog

magento2's People

Contributors

Stargazers

Watchers

Forkers

doap cajuclc oliver-montes warnermusic pborreli sessa guniorobot zhibek arabgento relue michaellehmkuhl natxetee improove jigneshthummar codefueluk riki4321 hightemp herveguetin cgdangelo esimionato winman tim-reynolds dburos colinmollenhour msoftware petk magentron amenk pooja12 gron1987 ariellephan zifius acmenna hunslater aiascq saleemshafi jimsolesociety hafeez3000 nayjest studio-webb dolfly rorteg barbazul lukebranch harris2004 mrzone vblanco7 btoledano richclever magento-japan akira28 nemphys piyushlathiya devzorg molotovbliss prattski andrewwaite mariuszgomse jonathanselander deivisonarthur protobalsas bahenry bogdanmuresan jpepper07 mywebcom daver1226 maheshkajale no2pixel oxidant geelweb tmotyl edmondscommerce buzzellp nayanchamp fivedigital pierre-pizzetta magentobi josephmaxwell summer-hu dilermando maps90 jesuserodriguez stormwild stephan321 clearandfizzy glidtest mageplus nozturn fabiosandias javiertejero artyom4d matiasepalacios mrjoseph dynamicguy nickimproove myatech svetli iammahmudur matthewhaworth jarodrose

magento2's Issues

Move saving logic outside the View part

It's necessary that saving logic should be in model or controller, not in block like this

class Mage_Checkout_Block_Onepage_Shipping_Method_Available extends Mage_Checkout_Block_Onepage_Abstract
{
................................................
    public function getShippingRates()
    {

        if (empty($this->_rates)) {
            $this->getAddress()->collectShippingRates()->save();
..........................................................

Because it's not clear (hidden) logic. Blocks should be used only for View part of MVC.

Suggestions

Hi, i hope that is not a wrong place for general suggestions for Magento 2.

What i wish is following:

jQuery as JavaScript Framework. The Community of jQuery is bigger, more Plugins ...
For default SEO friendly Layered Navigation with no Duplicate Content generation.
More Performance. I need a big machine with some optimiziations like Varnish to run Magento fast. The performance is often the reason why people/companies use a other shopsystem than Magento.
A better Dataflow Import- and Exportengine with possibility to export easy products with assigned categories.
Improved Multilanguage Support. The best solution for Multilanguage i found in Drupal 7. Here you can set a lot of Multilanguage Settings how to handle the Language checking and you can define a prefix for the languages.

For example, i have a german Magento Online-Shop:

http://www.domain.de (German; without Prefix)
http://www.domain.de/en/ (United Kingdom)
http://www.domain.de/fr/ (France)

etc.

Germany has specify laws for eCommerce. At the moment we use different german market extensions from the Magento Community to have all these things.

http://www.magentocommerce.com/magento-connect/market-ready-germany.html

It has some bugs or issues. I think that is better for Magento and Users/Developers to have it for default in Magento Core. Germany has a great ecommerce market.

A better Translate Engine than the CSV engine. Drupal 7 use a Database Translating Engine which is fast and easy to edit.

Greetings, Alexander

Block must know nothing about his parent

Why? Example from life: children will never know all about his parents. So i think, you need to change Mage_Core_Block_Abstract::setParentBlock method to Mage_Core_Block_Abstract::setParentName. And rewrite Mage_Core_Block_Abstract::getParentBlock to

public function getParentBlock()
{
$layout = $this->getLayout();
if ($layout) {
return $layout->getBlock($this->_parentName);
}
}

Can not import product by System -> Import/Export -> Dataflow - Profiles -> Import All Products

Can not import product by System -> Import/Export -> Dataflow - Profiles -> Import All Products.
1、no left nav menu
2、no commit menu

ImportExport module produces PHP strict notices

The ImportExport module especially the model Mage_ImportExport_Model_Import_Entity_Product is accessing non existing array keys without checking them first. This leads to a system.log full of Notice: Undefined index:

Notice: Undefined index: sku  in /app/code/core/Mage/ImportExport/Model/Import/Entity/Product.php on line 1717
Notice: Undefined index: _type  in /app/code/core/Mage/ImportExport/Model/Import/Entity/Product.php on line 1240
Notice: Undefined index: _type  in /app/code/core/Mage/ImportExport/Model/Import/Entity/Product.php on line 1241

What is the use of Mage_Core_Block_Flush ?

Maybe this block can be removed?

What is the use case for it?

Design suggestion for cross browser compitablity

I suggest to add browser name and version in body class

for example

right now Magento shows body class name as follow for home page
<body class=" cms-index-index cms-home">

Suggested class name for chrome

For Firefox

For IE

by doing this Magento can remove IE specific conditional css as well

This will help when we want to add browser specific css and even browser version specific css, so when ever i want to make change for perticular browser i just need to write .MSIE .className { property:value; } this is applied to all IE if i want more specfic solution .MSIE9 .className { property:value; } this change only applied for IE9

Please share your thoughts on this

Default libraries in Magento

The biggest hurdle of the current Magento installation is creating a consistent whole for a shop. The default installation in consistent throughout, but when you start installing modules from third parties everything gets messy. This is not because the third parties do a bad job, but because there aren't any default solutions (libraries, css classes, html components, etc.)

Twitter bootstrap is a great example and set of standards how to do things. Create the such a theme yourself you might say, but besides the work involved, it isn't the problem that a consistent theme is impossible to create, but making all modules compatible is. Having a great set of defaults lets module developers build their modules in a standard way without having to resort to their own solutions.

Especially in the Components section and Javascript Plugin section there are a lot of interesting ideas that greatly enrich the possibilities for developers.

It would be also great if we had default libraries for:
Lightboxes (fancybox is great)
Nivo Slider

The point is not that the libraries should be used throughout Magento, but they should be available in the system so that other developers will use them.

Error happenes when installation

First I create database in mysql, then I import the data of magento_sample_data_for_1.6.1.0.sql. When I install the magento2, there are a lot same errores. In page, the following error:

Zend_Db_Statement_Exception Object
(
[_previous:Zend_Exception:private] =>
[message:protected] => SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.customer/eav_attribute' doesn't exist
[string:Exception:private] =>
[code:protected] => 42
[file:protected] => D:\xampp\htdocs\magento2\lib\Zend\Db\Statement\Pdo.php
[line:protected] => 234
[trace:Exception:private] => Array
(
[0] => Array
(
[file] => D:\xampp\htdocs\magento2\lib\Varien\Db\Statement\Pdo\Mysql.php
[line] => 110
[function] => _execute
[class] => Zend_Db_Statement_Pdo
[type] => ->
[args] => Array
(
[0] => Array
(
[:id] => disable_auto_group_change
[:entity_type_id] => 1
)

                    )

            )

        [1] => Array
            (
                [file] => D:\xampp\htdocs\magento2\lib\Zend\Db\Statement.php
                [line] => 300
                [function] => _execute
                [class] => Varien_Db_Statement_Pdo_Mysql
                [type] => ->
                [args] => Array
                    (
                        [0] => Array
                            (
                                [:id] => disable_auto_group_change
                                [:entity_type_id] => 1
                            )

                    )

            )

        [2] => Array
            (
                [file] => D:\xampp\htdocs\magento2\lib\Zend\Db\Adapter\Abstract.php
                [line] => 479
                [function] => execute
                [class] => Zend_Db_Statement
                [type] => ->
                [args] => Array
                    (
                        [0] => Array
                            (
                                [:id] => disable_auto_group_change
                                [:entity_type_id] => 1
                            )

                    )

            )

        [3] => Array
            (
                [file] => D:\xampp\htdocs\magento2\lib\Zend\Db\Adapter\Pdo\Abstract.php
                [line] => 238
                [function] => query
                [class] => Zend_Db_Adapter_Abstract
                [type] => ->
                [args] => Array
                    (
                        [0] => SELECT `main`.*, `additional`.* FROM `eav_attribute` AS `main`

INNER JOIN customer/eav_attribute AS additional ON main.attribute_id = additional.attribute_id WHERE (main.attribute_code = :id) AND (main.entity_type_id = :entity_type_id)
[1] => Array
(
[:id] => disable_auto_group_change
[:entity_type_id] => 1
)

                    )

            )

        [4] => Array
            (
                [file] => D:\xampp\htdocs\magento2\lib\Varien\Db\Adapter\Pdo\Mysql.php
                [line] => 422
                [function] => query
                [class] => Zend_Db_Adapter_Pdo_Abstract
                [type] => ->
                [args] => Array
                    (
                        [0] => SELECT `main`.*, `additional`.* FROM `eav_attribute` AS `main`

                            )

                    )

                [5] => Array
                    (
                        [file] => D:\xampp\htdocs\magento2\lib\Varien\Db\Adapter\Pdo\Mysql.php
                        [line] => 422
                        [function] => query
                        [class] => Zend_Db_Adapter_Pdo_Abstract
                        [type] => ->
                        [args] => Array
                            (
                                [0] => SELECT `main`.*, `additional`.* FROM `eav_attribute` AS `main`

A problem of Manage Categories

In a store view, when I modify some attributes, I must No checked "Use Default Value" of "Available Product Listing Sort By" and "Default Product Listing Sort By", or I can't succeed to modify these attributes. But after I No checked these and succeed to modify the category, "Use Default Value" of "Default Product Listing Sort By" is checked! At the most worse, I can't check "Use Default Value" of "Available Product Listing Sort By" again for ever!

Camel Case Directories Not Allowed in Module Package Names

I have been working on porting over some of my modules to Magento 2 to get a head start on Magento 2 module development. I was having a really difficult time getting the adminhtml menu items to display. I was following the example in the Mage_Cms module. I was getting an error that stated, "Param resource doesn't pass validation".

I posted it on Twitter, and @mzeis sent an example of his attempt with admin menus and it worked fine for him.

The only difference that I could tell between our code was the our module package names. My module was named "LyonsCore_Core" and his was "Emzee_BackendTest".

So, I tried to rename my module to "Lyonscore_Core" (no camel case in the package name), and then it worked just fine.

So, this is either a bug, or something needs to specify that camel case directories are not allowed as module package names.

Can you commit to repository a folder dev/tests/static ?

Hello!

After a conference MageConf 2011 in Kyiv I have found the following articles:
https://wiki.magento.com/display/MAGE2DOC/Automated+Static+Code+Analysis+Tests
https://wiki.magento.com/display/MAGE2DOC/Magento+Automated+Testing+Guide

In these articles a static code analysis describes.
But in this Git repostitory I can't found a directory "dev/tests/static".

Is it correct or this code won't be publicated in the future ?

Use Flyweight pattern for blocks in layout updates

I think it's necessary to use Flyweight pattern for blocks in layout updates that does not have their own state information. In more cases when developer need only to display some template he uses a Mage_Core_Block_Template without any parameters for example

<block type="Mage_Core_Block_Template" name="my.banner" template="banners/some_banner.phtml" />

For such situation you can create "Context" object that will observe all parameters for block by his name. It can decrease usage of memory during displaying View part of system.

Enable automated CRUD setup for Adminhtml Grids

As a programmer, I would like complete CRUD functionality out of the box when creating Adminhtml grids

Grid Massaction Bandwidth Usage of setGridIds

If a grid supports massaction / select all, all the ids of all pages of a grid are included in the page in the setGridIds call (see Mage_Backend_Block_Widget_Grid_Massaction_Abstract). If the shop has for example 10000 products this is around 50 KB of data that is included on every page of the product listing.

To improve performance, the currently included grid IDs could be stored in the session server-side and the mass action select all could reference to this session storage for example by an unique hash.

String based error handling in Mage_Sales_Model_Quote:addProductAdvanced etc.

The function addProductAdvanced and the underlying functions return strings if an error occurred.

One example from Mage_Catalog_Model_Product_Type_Abstract::_prepareProduct:

    try {
        $options = $this->_prepareOptions($buyRequest, $product, $processMode);
    } catch (Mage_Core_Exception $e) {
        return $e->getMessage();
    }

They should use exceptions instead - so a better handling of the different cases for an error can take place such as

distinguishing between the different kinds of errors
logging backtraces

As a result, parts like

    if (is_string($cartCandidates)) {
        return $cartCandidates;
    }

can be omitted then because the exceptions are passed automatically.

Add support to remove links from customer navigation

Right now, the only way to accomplish this is to copy the layout file that adds the link to the customized theme and remove the <addLink> line, or override Mage_Customer_Block_Navigation.

My proposal is that <action method="removeLink"><name>whatever</name></action> be supported so it can be added into local without the cost of parsing extra XML files or risking future magento upgrade incompatibilities

Create Setup class with possibility to create tables with translatable fields

It's necessary to create Setup (or some behavior) class that would give api to easy implement modules with fields that must be available on different languages. This class can create some additinal tables automatically for example i have table "news" and i want that fields "title" and "description" will be available for a few languages (the api of business models and collection must be the same as for non-translatable table). Table "news" has few fields. There are id, title, description, is_active, created_at.

In the install file of module i create a ddl table object and set some parameter (or behavior object) that responsible for the creation of the additional table with template name %base_tablename%_translation (e.g. news_translation). This table contains all translatable fields (e.g. title, description) id and store_id. Id field is the same that is in base table (e.g. news). Also you need to add primary index for (id, storeid).

For example,

$table = $installer->getConnection()
    ->newTable($installer->getTable('news'))
    ->addColumn('block_id', Varien_Db_Ddl_Table::TYPE_SMALLINT, null, array(
        'identity'  => true,
        'nullable'  => false,
        'primary'   => true,
        ), 'News ID')
    ->addColumn('title', Varien_Db_Ddl_Table::TYPE_TEXT, 255, array(
        'nullable'  => false,
        ), 'News Title')
    ->addColumn('description', Varien_Db_Ddl_Table::TYPE_TEXT, '2M', array(
        ), 'News Description')
    ->addColumn('creation_time', Varien_Db_Ddl_Table::TYPE_TIMESTAMP, null, array(
        ), 'Block Creation Time')
    ->addColumn('update_time', Varien_Db_Ddl_Table::TYPE_TIMESTAMP, null, array(
        ), 'Block Modification Time')
    ->addColumn('is_active', Varien_Db_Ddl_Table::TYPE_SMALLINT, null, array(
        'nullable'  => false,
        'default'   => '1',
        ), 'Is Block Active')
    ->setComment('CMS Block Table');

// Add Table Behavior
$table->addBehavior(new TranslatableBehavior(array('title', 'description'));


$installer->getConnection()->createTable($table);

This code must generate the following SQL:

CREATE TABLE `news` (
 `id` smallint(6) NOT NULL AUTO_INCREMENT,
 `creation_time` datetime DEFAULT NULL,
 `update_time` datetime DEFAULT NULL,
 `is_active` tinyint(1) NOT NULL DEFAULT '1'
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 COMMENT='CMS Blocks'

CREATE TABLE `news_translation` (
 `id` smallint(6) NOT NULL,
 `title` varchar(255) not null,
 `description` text,
 `store_id` smallint(5) unsigned NOT NULL,
 PRIMARY KEY (`id`,`store_id`),
 KEY `FK_CMS_BLOCK_STORE_STORE` (`store_id`),
 CONSTRAINT `FK_CMS_BLOCK_STORE_BLOCK` FOREIGN KEY (`id`) REFERENCES `news` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
 CONSTRAINT `FK_CMS_BLOCK_STORE_STORE` FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='CMS Blocks to Stores';

To work with models withous changing api:

// collection
$collection = new TranslatableCollection(); 
$collection->setStoreId(Mage::app()->getStore()->getId())->load();

// item
$item = new TranslatableModel();
$item->setStoreId(Mage::app()->getStore()->getId())->load($itemId);

echo $item->getTitle();
echo $item->getDescription();

It would look like a Doctrine I18n Behavior - http://docs.doctrine-project.org/projects/doctrine1/en/latest/en/manual/behaviors.html#i18n .

Catalog product price rules should be moved to controller/model

The following template page contains too much code:

https://github.com/magento/magento2/blob/master/app/code/core/Mage/Catalog/view/frontend/product/price.phtml

Test Issue

testing issue tracking

Merged JS/CSS improvements

In Magento 1.x I made some improvements to Mage_Core_Model_Design_Package. Seems like now is a good time to suggest these for 2.0:

Cached latest mtime of all files to be merged (I see 2.0 does this, but in a .dat file.. why not the Magento cache?)
Added a cache type for said cache records (so that Cache Management can be used to clean just the mtime records without affecting the rest of the cache)
Added a separate base url for merged files vs media files. This is because CDNs are generally not reliable and if your merged CSS or JS doesn't load your page is broken. We serve merged files directly and all other media files from a CDN to prevent this.
The file names are hashed once for the mtime cache record, but the final merged file name is an MD5 hash which includes these pieces of information which ensures that merged files never need to be purged from an upstream cache or browser:
- Mage::getBaseUrl('skin') in case the skin url is updated
- The hash of the file names (re-use mtime cache key)
- The most recent mtime in case one of the files is updated
- IMPORTANT: The request protocol (http or https) to prevent browser security warnings on https pages
If the file exists ending with -min then this file name is returned instead. This allows use of an external script to minify the JS or CSS whithout overwriting the original file which may be cached upstream before it is minified.
Never delete the parent directory of the merged files, just the contents. This way an inotify script can watch the directory and minify files as they are created. Deleting the parent directory breaks the inotify watches.
For CSS image url replacement use the real skin base url rather than the web base so skin assets can be served from CDN.

You can see my extended Package.php with these features here: https://gist.github.com/2364485

Enable Magento_Profiler by SetEnv

As of Magento 1, you have to edit index.php to activate Magento_Profiler.
In my opinion, it should not be necessary to edit any core files.

My proposal is to introduce code to app/bootstrap.php similar to:

if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE'])) {
    Mage::setIsDeveloperMode(true);
}

One or more additional environment variables can allow to register the profile output classes.

Advantages:

No need to edit app/bootstrap.php
It's easy to set different settings for every environment (dev/stage/live etc.)

Mage_Core_Block_Abstract::__() use singleton for expr var

    public function __()
    {
        $args = func_get_args();
        $expr = new Mage_Core_Model_Translate_Expr(array_shift($args), $this->getModuleName());
        array_unshift($args, $expr);
        return Mage::app()->getTranslator()->translate($args);
    }

You can use singleton $expr var, because if we look at the Mage_Core_Model_Tranlate::translate

public function translate() {
.............
        if ($text instanceof Mage_Core_Model_Translate_Expr) {
            $code = $text->getCode(self::SCOPE_SEPARATOR);
            $module = $text->getModule();
            $text = $text->getText();
            $translated = $this->_getTranslatedString($text, $code);
        }
.................
}

we will see that expr object is used only once to fetch args for Mage_Core_Model_Tranlate::_getTranslatedString(). You have a lot calls of __() method in templates, models, etc. It can improve perfomance.

And why do you use array_shift/array_unsfhit to get and pass first element of arguments array? Just use array index:

    public function __()
    {
        $args = func_get_args();
        if (!empty($args[0]) {
            $args[0] = new Mage_Core_Model_Translate_Expr($args[0], $this->getModuleName());
            return Mage::app()->getTranslator()->translate($args);
        }
    }

Merge Persistent templates into Customer and Checkout

Since Mage_Persistent appeared, a bunch of templates from Mage_Customer and Mage_Checkout were never used again as they were overriden.

I think Magento 2 is a good time to clean this up and get rid of Mage_Persistent templates that override Mage_Customer's and Mage_Checkout's

Push single commits to github

Instead of batched huge commits it would be helpful to see the single commits of the project on github.

By this it is easier to understand why some changes were made and what changes belong together.

Ability to provide configuration for different environments in app/etc/local.xml

My proposed story for the backlog

Provide configuration for different environments in app/etc/local.xml
"As a Magento developer, I want to be able to define different configuration settings for different environments in app/etc/local.xml."

Acceptance criteria:

Defining important settings like database connection, cache backends and session handling for different environments in one XML file
Extending from other environment sections so only changes have to be specified
The environment to be used is defined by SetEnv

Reasoning behind this

In Magento 1, developers have to make sure that app/etc/local.xml doesn't get copied from test / staging servers to production servers because this would break the live system in most cases. app/etc/local.xml has to be excluded from versioning and/or deployment process which is error-prone.

In Magento 2, developers should be able to keep one configuration file and trigger which part of the configuration is used. I don't believe this has to be very fine-grained. In my experience the most common scenarios are different database, caching and session settings.

Nowadays, many frameworks provide the functionality to define setting for different environments in one or more configuration file(s) and load the settings corresponding to a variable set by SetEnv or similar.
The community and the Magento 2 team would have to decide on the concrete implementation but I think this is a good thing (tm).

References:

Move validation of Mage_Customer_Model_Address to another class

There is no ability to change validation rules for Mage_Customer_Model_Address (Mage_Customer_Model_Address_Abstract::validate). For example, I changed "is_required" field for attribute "lastname" to false and when i was trying to place order without lastname field i got an error: Please enter the last name.

I want to customize validate logic and there is only 2 bad ways (rewrite model, place the same file to app/code/local). I think the best solution is validator. Something like this should be (pseudo code):

 class AddressForm {
      public function __construct($model) {
           $this->_configure();
           $this->_fillByModel();
      }

      protected function _configure() {
           $this->addField('firstname')->addValidator(new ValidatorEmpty());
           ....................................(the same for each field that i want to see in form and validate)
      }

      public function isValid() {
           for each validator do {
                $validator->validate();
           }
           return $result;
      }
 }

Usage:
$form = new AddressForm($quote->getBillingAddress());
if ($form->isValid()) {
$quote->getBillingAddress()->save();
}

I think that it's better if validation process is in controller then it will easy to change validation logic. More easy solution for you make checking address attributes for required flag and another rules

Add @var $this comments to templates

Templates contain comments like this:

/**
* Product view template
*
* @see Mage_Catalog_Block_Product_View
* @see Mage_Review_Block_Product_View
*/

Adding @var $this comments enables code completion in our IDEs:

/**
* Product view template
*
* @var $this Mage_Catalog_Block_Product_View
* @see Mage_Review_Block_Product_View
*/

Remove var Translator = new Translate... from every page

You must remove this JS because it's bad for SEO it's bad for mobile and it's bad for users that use 3G modems. I undestand that this code need for translations in JavaScript, but you can get it using AJAX! During page loading just send AJAX request to some controller that will return translations in JSON format.
It will also decrease time of page loading.

And it's useful you may check this thread http://www.magentocommerce.com/boards/viewthread/9307/ .

Why use private for message ?

On this class:

https://github.com/magento/magento2/blob/master/app/code/core/Mage/Checkout/Model/Type/Onepage.php

Why $_customerEmailExistsMessage is defined as private, there is no setter and _customerEmailExistsMessage is setted from constructor statically.

The only one possibility we have to change this message is to play with i18n.

Is there a reason ? I think this property should be protected. No ?

Errors at reports > product > most viewed

Fatal error: Call to undefined method Mage_Reports_Model_Resource_Product_Viewed_Collection::setPeriod() in /Applications/MAMP/htdocs/magento2/app/code/core/Mage/Adminhtml/Block/Report/Grid/Abstract.php on line 213

Fatal error: Undefined class constant 'NS_SEPARATOR' in /Applications/MAMP/htdocs/magento2/lib/Magento/Autoload.php on line 129

Version updated at 9/13/2012 exists two problems

When install in development mode, the system.log has the following record ($magento is the installation directory):
2012-09-19T13:45:12+00:00 DEBUG (7): Failed resource setup: $magento\app\code\core\Mage\Core\data\core_setup\data-upgrade-1.6.0.3-1.6.0.4.php
2012-09-19T13:45:21+00:00 DEBUG (7): Failed resource setup: $magento\app\code\core\Mage\Cms\data\cms_setup\data-upgrade-1.6.0.0.2-1.6.0.0.3.php
2012-09-19T13:45:21+00:00 DEBUG (7): Failed resource setup: $magento\app\code\core\Mage\Eav\data\eav_setup\data-upgrade-1.6.0.0-1.6.0.1.php
2012-09-19T13:45:22+00:00 DEBUG (7): Failed resource setup: $magento\app\code\core\Mage\Customer\data\customer_setup\data-upgrade-1.6.2.0.1-1.6.2.0.2.php
2012-09-19T13:45:25+00:00 DEBUG (7): Failed resource setup: $magento\app\code\core\Mage\Catalog\data\catalog_setup\data-upgrade-1.6.0.0.16-1.6.0.0.17.php
2012-09-19T13:45:26+00:00 DEBUG (7): Failed resource setup: $magento\app\code\core\Mage\Widget\data\widget_setup\data-upgrade-1.6.0.0-1.6.0.1.php
2012-09-19T13:45:26+00:00 DEBUG (7): Failed resource setup: $magento\app\code\core\Mage\CatalogRule\data\catalogrule_setup\data-upgrade-1.6.0.3-1.6.0.4.php
2012-09-19T13:45:28+00:00 DEBUG (7): Failed resource setup: $magento\app\code\core\Mage\SalesRule\data\salesrule_setup\data-upgrade-1.6.0.3-1.6.0.4.php
2012-09-19T13:45:28+00:00 DEBUG (7): Failed resource setup: $magento\app\code\core\Mage\Newsletter\data\newsletter_setup\data-upgrade-1.6.0.1-1.6.0.2.php
When login the backend, the system.log has the following record:

2012-09-19T13:48:37+00:00 CRIT (2): Broken reference: the 'paypal.partner.top_cart.shortcut' element cannot be added as child to 'topCart.extra_actions, because the latter doesn't exist
2012-09-19T13:48:37+00:00 CRIT (2): Broken reference: the 'paypaluk.partner.top_cart.shortcut' element cannot be added as child to 'topCart.extra_actions, because the latter doesn't exist

New Frontend Package tries to find wrong assets

With the latest version (now) after I made a blank new Frontend Package:

/design/frontend/shop/default/skin/default

Mage_Core_Model_Design_Package tries to find pub/js/css/styles.css which does not exists...

Let me know if I do something wrong here...

I assume that a new package has the default package as fallback?

a:5:{i:0;s:140:"Unable to locate skin file '/var/www/magento.nl/public_html/pub/js/css/styles.css'.";i:1;s:5501:"#0 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Model/Design/Package.php(486): Mage_Core_Model_Design_Package->_publishSkinFile('css/styles.css', Array)
#1 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Model/Design/Package.php(578): Mage_Core_Model_Design_Package->getSkinUrl('css/styles.css')
#2 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Model/Design/Package.php(539): Mage_Core_Model_Design_Package->_getOptimalUrls(Array, 'css', false)
#3 /var/www/magento.nl/public_html/app/code/core/Mage/Page/Block/Html/Head.php(193): Mage_Core_Model_Design_Package->getOptimalCssUrls(Array)
#4 /var/www/magento.nl/public_html/app/code/core/Mage/Page/view/frontend/html/head.phtml(42): Mage_Page_Block_Html_Head->getCssJsHtml()
#5 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Block/Template.php(247): include('/var/www/magent...')
#6 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Block/Template.php(281): Mage_Core_Block_Template->fetchView('/var/www/magent...')
#7 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Block/Template.php(292): Mage_Core_Block_Template->renderView()
#8 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Block/Abstract.php(577): Mage_Core_Block_Template->_toHtml()
#9 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Model/Layout.php(878): Mage_Core_Block_Abstract->toHtml()
#10 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Model/Layout.php(853): Mage_Core_Model_Layout->_renderBlock('head')
#11 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Block/Abstract.php(382): Mage_Core_Model_Layout->renderElement('head', true)
#12 /var/www/magento.nl/public_html/app/code/core/Mage/Page/view/frontend/2columns-right.phtml(35): Mage_Core_Block_Abstract->getChildHtml('head')
#13 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Block/Template.php(247): include('/var/www/magent...')
#14 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Block/Template.php(281): Mage_Core_Block_Template->fetchView('/var/www/magent...')
#15 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Block/Template.php(292): Mage_Core_Block_Template->renderView()
#16 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Block/Abstract.php(577): Mage_Core_Block_Template->_toHtml()
#17 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Model/Layout.php(878): Mage_Core_Block_Abstract->toHtml()
#18 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Model/Layout.php(853): Mage_Core_Model_Layout->_renderBlock('root')
#19 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Model/Layout.php(1347): Mage_Core_Model_Layout->renderElement('root')
#20 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Controller/Varien/Action.php(439): Mage_Core_Model_Layout->getOutput()
#21 /var/www/magento.nl/public_html/app/code/core/Mage/Cms/Helper/Page.php(131): Mage_Core_Controller_Varien_Action->renderLayout()
#22 /var/www/magento.nl/public_html/app/code/core/Mage/Cms/Helper/Page.php(52): Mage_Cms_Helper_Page->_renderPage(Object(Mage_Cms_IndexController), 'no-route')
#23 /var/www/magento.nl/public_html/app/code/core/Mage/Cms/controllers/IndexController.php(75): Mage_Cms_Helper_Page->renderPage(Object(Mage_Cms_IndexController), 'no-route')
#24 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Controller/Varien/Action.php(472): Mage_Cms_IndexController->noRouteAction()
#25 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Controller/Varien/Front.php(192): Mage_Core_Controller_Varien_Action->dispatch('noRoute')
#26 /var/www/magento.nl/public_html/app/code/core/Mage/Core/Model/App.php(363): Mage_Core_Controller_Varien_Front->dispatch()
#27 /var/www/magento.nl/public_html/app/Mage.php(666): Mage_Core_Model_App->run(Array)
#28 /var/www/magento.nl/public_html/index.php(39): Mage::run('', 'store', Array)
#29 {main}";s:3:"url";s:44:"/errors/report.php?id=696988257&skin=default";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:7:"default";}

Performance Testing

According to the Magento 2 Wiki page (https://wiki.magento.com/display/MAGE2DOC/Performance+Testing) there should be some JMeter test scripts (*.jmx) in the dev/tests folder, but I don't see them in the master branch.

Clear separation for Controller and controllers required with Full Controller path

-I can't find difference between folder Controller and controllers folder under Catalog ( and some other ) modules its possible to merge both of them or any reason why its like that?
-more over is it possible to add full controller path as controllers class name? same like Model and Block class name?
i.e
Mage_Catalog_IndexController can be converted to Mage_Catalog_controllers_IndexController

Admin not reachable after installation

Installed Magento on Apache 2.4.2 / PHP 5.4.4

After installation frontend works okay.

When going to backend /backend i get login screen, but after i entered my credentials i go to 404 (whoops, our bad) with url (example)

http://localhost/magento2/index.php/backend/admin/dashboard/index/key/877719217bb8c880dc4e67538d998631/

core/template block should use a helper or a model

core/template block should use a helper or a model to render a template. If it will be so than anyone can rewrite this helper or model and implement, for example, HAML templates support. At the moment the only way to do so is to place Mage_Core_Block_Template in app/local folder.

Add layout handle for empty search results and empty categories

Please add a custom layout handle for empty search results and empty categories so that we can change the page layout easily.

Blocks no longer Fire "after render"events.

The core_block_abstract_to_html_after event was removed from

app/code/core/Mage/Core/Block/Abstract.php

It looks like this changed occurred between the 9de2223 and 3330e25 commits, but there was no specific mention of why this event was removed.

If possible, can this event be restored? I've got a few extensions (both commercial and open source) that rely on it.

Reorganize resources/setup files

Suggesting to get rid of declared "resources" like "cms_setup" in config.xml and instead use the module name as the resource name, e.g. "Mage_Cms". Then, simplify the directory structure like so:

Before:

Mage/Cms/sql/cms_setup/install-1.6.0.0.php
Mage/Cms/datal/cms_setup/install-1.6.0.0.php

After:

Mage/Cms/setup/schema/install-1.6.0.0.php
Mage/Cms/setup/data/install-1.6.0.0.php

I think the above is more intuitive and more consistent with the other changes in Magento 2 vs Magento 1. Also, setup doesn't necessarily have anything to do with sql in all cases (e.g. MongoDb, Lucene, etc..) so "schema" is a better general term. Placing both under a single "setup" directory makes their purpose more apparent and organizes them under one directory since they are closely related.

Change Mage::getModel(%Class_Name%) to %Class_Name%::new()

To decrease static dependencies of Mage class you can replace

Mage::getModel('Mage_Catalog_Model_Product')

Mage_Catalog_Model_Product::new()

Why don't getAllIds() of Mage_Core_Model_Resource_Db_Collection_Abstract bind params?

In the end of getAllIds() of Mage_Core_Model_Resource_Db_Collection_Abstract, it is:
(line 499)
return $this->getConnection()->fetchCol($idsSelect);

Why isn't it the following:

return $this->getConnection()->fetchCol($idsSelect, $this->_bindParams);

Decrease dependencies from Mage class

Why do you use Mage::helper instead Mage_Core_Block_Abstract::helper (e.g. the same file at line 191)? Using the last one choice you will get more flexibility.
Also it will be nice if you create a getConfigValue method instead of using Mage::getStoreConfig.

Then, in future, when you want to implement dependency injection pattern it will easier.

Unable to locate skin file pub/js/css/reset.css

Installed Magento2 and after completing the final step of installation wizard the following error occured:

a:5:{i:0;s:90:"Unable to locate skin file 'PATH/pub/js/css/reset.css'.";i:1;s:2538:"#0 PATH/app/code/core/Mage/Core/Model/Design/Package.php(572): Mage_Core_Model_Design_Package->_publishSkinFile('css/reset.css', Array)
#1 PATH/app/code/core/Mage/Core/Block/Abstract.php(682): Mage_Core_Model_Design_Package->getSkinUrl('css/reset.css', Array)
#2 PATH/app/code/core/Mage/Install/view/install/page.phtml(47): Mage_Core_Block_Abstract->getSkinUrl('css/reset.css')
#3 PATH/app/code/core/Mage/Core/Block/Template.php(247): include('/usr/local/zend...')
#4 PATH/app/code/core/Mage/Core/Block/Template.php(281): Mage_Core_Block_Template->fetchView('/usr/local/zend...')
#5 PATH/app/code/core/Mage/Core/Block/Template.php(292): Mage_Core_Block_Template->renderView()
#6 PATH/app/code/core/Mage/Core/Block/Abstract.php(577): Mage_Core_Block_Template->_toHtml()
#7 PATH/app/code/core/Mage/Core/Model/Layout.php(719): Mage_Core_Block_Abstract->toHtml()
#8 PATH/app/code/core/Mage/Core/Model/Layout.php(694): Mage_Core_Model_Layout->_renderBlock('root')
#9 PATH/app/code/core/Mage/Core/Model/Layout.php(1185): Mage_Core_Model_Layout->renderElement('root')
#10 PATH/app/code/core/Mage/Core/Controller/Varien/Action.php(426): Mage_Core_Model_Layout->getOutput()
#11 PATH/app/code/core/Mage/Install/controllers/WizardController.php(465): Mage_Core_Controller_Varien_Action->renderLayout()
#12 PATH/app/code/core/Mage/Core/Controller/Varien/Action.php(456): Mage_Install_WizardController->endAction()
#13 PATH/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(188): Mage_Core_Controller_Varien_Action->dispatch('end')
#14 PATH/app/code/core/Mage/Core/Controller/Varien/Front.php(189): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#15 PATH/app/code/core/Mage/Core/Model/App.php(363): Mage_Core_Controller_Varien_Front->dispatch()
#16 PATH/app/Mage.php(658): Mage_Core_Model_App->run(Array)
#17 PATH/index.php(34): Mage::run('', 'store')
#18 {main}";s:3:"url";s:39:"URL/index.php/install/wizard/end/";s:11:"script_name";s:19:"URL/index.php";s:4:"skin";s:7:"default";}

Remove "remove" tags from checkout

There are a bunch of unnecessary <remove> tags in checkout.xml (and now in the corresponding layout.xml file) which remove either the left or the right column.

By unnecessary I mean that they are usually redundant with the template being assigned to root. i.e. in <checkout_cart_index> root template is page/1column.phtml but there are also a <remove name="left" /> and <remove name="right" /> tags. Same thing happens for almost every other handler in that layout.

This is a problem because there is no <unremove> (I'm fine with that btw) so there is no way to change the root layout of checkout pages via local.xml

Require path dev/shell/indexer.php and log.php

require_once '../../app/bootstrap.php';

Should be written as (like dev/shell/install.php):

require_once __DIR__ . '/../../app/bootstrap.php';

dev/shell/indexer.php line 27
dev/shell/log.php line 27

This way you can run the script from anywhere.

Rewording of system configuration menu "Advanced" > "Advanced"

In my experience, the backend menu item "System" > "Configuration" > "Advanced" > "Advanced" can confuse both merchants and developers.

I suggest two improvements for this item:

Rename the item to something like "System" > "Configuration" > "Advanced" > "Modules". If you want to differentiate between (core) modules and (community/local) extensions, it could also be called "Modules & Extensions".
Add a warning which clearly states the difference between "disable module output" and "disable the module completly". Especially for merchants, only disabling the output can have undesired side effects which are not understood properly. I would go even further and question the sense of only disabling the output. Given that Magento 2 aims to be more modular, it may be possible to disable modules completly from the backend.

It makes it hard to read when debugging, or if viewing the raw email headers, or in some client that is not smart enough to decode the subject (yes, there are a few).
I've seen a spamassassin rule that dings an email if the subject is unnecessarily encoded.

So the solution would be to use a method to detect if the subject has non-ascii characters and not encode it if it doesn't.