openmage / magento-lts Goto Github PK

When we now start to tag our own releases, I would like to require at least the tags to be signed.
https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

Also bigger imports or patches would be great, if the commit itself was signed.

How is the opinion about this here?

The file
https://github.com/OpenMage/magento-lts/blob/1.9.1/app/locale/en_US/Mage_Catalog.csv#L482

contains label "Please specify the product's option(s)" which is wrong. It should be "Please specify the product's option(s)".
Also all other languages are affected. This bug prevents magento from translating this message and it always appear in english.

Probably sb just copied the label from
https://github.com/OpenMage/magento-lts/blob/1.9.1/app/code/core/Mage/Catalog/Model/Product/Type/Configurable.php#L689

where slash is added to escape single quote in php.

This message appear eg. when you try to add to cart configurable product from wishlist. But the product is not yet configured

Router does not redirect to 404 for certain frontend routes, example:
http://demo.icebergcommerce.com/contacts/index/index/index/this-should-redirect-to-404
For the contacts route for example if you add:
/index/index/index/this-should-redirect-to-404
this should result in 404 as the route does not exists, but still it serves the contacts route.

in opcheckout.js https://github.com/OpenMage/magento-lts/blob/1.9.2.1/skin/frontend/base/default/js/opcheckout.js#L93 the for loop iterates over all object properties, including functions.
If one of the properties is undefined, the script will break, and it will NOT be possible to proceed with checkout.

This happend to us once livechat vendor has error in their js (hosted by them) which added an undefined property to dom objects. And it broke the chekout.

How it should be solved:
we should not loop over all object properties, but only over DOM nodes.

http://magebase.com/magento-tutorials/quick-fix-coupon-codes-used-up-on-incomplete-transactions/comment-page-1/#comment-53337

and updated code here:
https://gist.github.com/peterjaap/bf9aa2086f06a1a41fa1

Another patch from Magento not included in future versions, for some reason...

In the past Magento didn't really follow a helpful versioning pattern (see readme). However, lately they are sticking to patch level version increases, so we should revisit how we do our branching and release tagging for this repo. Any thoughts/suggestions?

Hi. old bug still present. If store uses prices excluding tax on admin area, prices on frontend category are without tax showing "as low as PRICE with tax" instead of including tax. The same appears on product page and cart/checkout bundle product row shows associated product price without tax also
Issue presented in all 1.9 versions, 1.9.3 shows correct price as configured right know - so its a small fix for bundles

After upgrade Magento from 1.9.2.2 to 1.9.2.4 I have doubled tax amount in Quote.

I have found solution for this issue:
http://stackoverflow.com/questions/17590364/magento-applying-tax-vat-twice/35870460#35870460

The problem occurs when you have additional totals in project.
The problem can be solved by adding correct dependencies on tax subtotal, so Magento keep the correct order.

Built in Keyword using "KEY" as field name in oauth_consumer table. Please change it to api_key ASAP

Only source so far: https://twitter.com/DigitalPianism/status/785856489164509186

Magento is getting a version increase this/next week. In the past to deal with the extra changes we've introduced in this repository we'd follow this workflow:

1. Import the new core as-is to https://github.com/OpenMage/magento-mirror
2. Run diff on the latest version there to the previous version
3. Apply that diff to this repository, push into new branch (matching version #)
4. Update default branch to this new branch
5. Apply Magento provided patch manually to all applicable previous version branches here.

I can take care of this, but I wanted to highlight the process here for anyone that was interested, or in case I'm unable to do it in the future (assuming this isn't the last ever update to 1.*). Let me know if I'm missing something, or if you have any suggestions for this process.

Many of the indexers call Mage_Index_Model_Resource_Abstract::disableTableKeys(), which runs a statement like this: ALTER TABLE ... DISABLE KEYS. Then, after some rows are inserted into the index table, enableTableKeys() is called.

As far I can see DISABLE/ENABLE KEYS only works with MyISAM tables, so it isn't used by modern Magento installations. What's worse is in MySQL 5.5+ the ALTER TABLE statement requires a table metadata lock.

As the statement doesn't actually do anything it could be removed and the lock would be avoided (though its possible it might cause problems for older installations that might still have MyISAM tables)

It may seem like it wouldn't have that much impact as the lock should only be for a very short time, but in production I've seen large queues of queries 'Waiting for table metadata lock' on tables like cataloginventory_stock_status and catalog_product_index_price when the ALTER TABLE statement is blocked by some other very slow transaction.

Before i start a PR, i just want to know if you would accept it.

There are some models w/o $_eventPrefix set, e.g. Mage_Cms_Model_Block. Let's assume you want to observe CMS-Block save, you have to use one of these generic events model_save_before or core_abstract_save_before and check instance of the object. It works, but life could be easier :)

MySQL versions older than 5.5 are no longer supported by Oracle. Newer versions add features like fulltext index support on InnoDB tables, ALTER TABLE ALGORITHM=INPLACE, generated columns, etc. Too many new features to name. Also to support things like Galera cluster it is necessary to drop support for MyISAM tables. However, to drop MyISAM support we need to require at least MySQL 5.6 to support fulltext index for catalogsearch module. Before I start creating PRs I'd like to establish what the new minimum MySQL version should be. My suggestion would be 5.6.

Hi @OpenMage/lts-admins

I've created the new branch for the 1.9.3 release after importing the diff from OpenMage/magento-mirror@d48bebc

There were some patch conflicts - surprisingly most of them were related to patches we've already applied for PHP 7 support (although Magento does not claim compatibility with PHP 7 with this release). Regardless, I've listed the files I encountered patch conflicts with below:

.//app/code/core/Mage/Catalog/Model/Resource/Product/Type/Configurable/Attribute/Collection.php.rej
.//app/code/core/Mage/Core/Model/Layout.php.rej
.//app/code/core/Mage/ImportExport/Model/Export/Entity/Customer.php.rej
.//app/code/core/Mage/ImportExport/Model/Export/Entity/Product/Type/Abstract.php.rej
.//app/code/core/Mage/ImportExport/Model/Import/Uploader.php.rej
.//app/code/core/Mage/Sales/etc/config.xml.rej
.//app/code/core/Mage/Tax/etc/config.xml.rej
.//app/locale/en_US/Mage_Rss.csv.rej
.//lib/Varien/File/Uploader.php.rej

Please review what I ended up with and compare it both with the history of this repo and the official release. If you approve of the resolution I came up with add +1 to this issue. If you have any problems (with these files or any others), please outline them here and I'll work on resolving them in the new branch.

Once we have +3 or so I'll update the default branch on this repo to 1.9.3 (effectively releasing it). Sorry we can't do this in a PR - I don't think you can submit a PR for a new branch...

Hi,

I am using Magento 1.9.2.4.

When I add a new product and want to upload an productimage, this image doesn't appear. After clicking on the upload button, you see that upload is 100%, but then nothing happens. No image.

How can this bug fixed?

speed improvement for configurable products

how about adding a solution related to this?

https://astrio.net/blog/magento-performance-optimization-configurable-products-2/

and this link http://www.jg-dev.de/magento-configurable-product-performance-boost/#.WDwzxebhA2w

Improve all grid speeds (are largest problem to date)

improve product load speed

Hi, all

Steve from xpractical.com.au here

Here are two bugs fixes in our production site. The hidden discount one causes magento/paypal to mark the order as fraud as the totals from the two systems don't add up with certain discount and tax settings. The IPN one causes an attempted order cancel to fail and mark the order as processing which in our system means its ok to ship and is picked up by our ERP integration.

There is also a bug in paypal express that skips the inventory decrement after successful order processing. Have not found a fix for that yet.

We have also found a bug in the aurthorise.net payment gateway. It will return "payment-ok" status on magento payment-update even if the payment has been cancelled. This means you cant use payment-update button.

Hope these tips help. Our site php7/magento community 1.9.3.1 is "mid" size at 30-100 orders per day @ $500-1500 per order with store views for US, UK and AU.

Bugs still in 1.9.3.1

mcd_steven@stage2:/var/www/temp-magento$ diff app/code/core/Mage/Paypal/Model/Ipn.php /var/www/magento/app/code/core/Mage/Paypal/Model/Ipn.php
533a534,540
> // MOD SMCD paypal bug, must remove invoice before order cancel otherwise order cancel will fail and go to processing
> foreach ($this->_order->getInvoiceCollection() as $invoice){
> $invoice->cancel()->save();
> }

mcd_steven@stage2:/var/www/temp-magento$ diff /var/www/magento/app/code/core/Mage/Paypal/Model/Hostedpro/Request.php /var/www/temp-magento/app/code/core/Mage/Paypal/Model/Hostedpro/Request.php
160,161c160
< // MOD SMCD 2016 - added hidden tax, missing this causes fraud trigger
< 'tax' => $this->_formatPrice($order->getBaseTaxAmount() + $order->getHiddenTaxAmount() ),
---
> 'tax' => $this->_formatPrice($order->getBaseTaxAmount()),

because a improved password hashing by default is recommended
https://github.com/ikonoshirt/pbkdf2

It also supports Backwards Compatibility, so this module also works with longer existing shops

the .htaccess file should also include directives for mod_php7.c

<IfModule mod_php7.c>

This patch fix issue with Shopping Cart Rule as mentioned here: http://magento.stackexchange.com/questions/46428/magento-1-9-1-shopping-cart-price-rules-condition-subselection-issue

It's old but still actual
https://gist.github.com/piotrekkaminski/54529dadb0bc01a62a2d

Known bug for several years now ...

http://magento.stackexchange.com/questions/43939/allowed-countries-keeps-resetting-to-all/43961#43961

Magento 1.9.3.1 coming? 9.31.x in new naming conv

https://www.reddit.com/r/Magento/comments/592puw/magento_1931_is_coming_soon_reported_magento_in/

Inchoo/Inchoo_PHP7@47eff1b

In downloader/lib/Mage/HTTP/Client/Curl.php, try changing:

$this->curlOption(CURLOPT_SSL_CIPHER_LIST, 'TLSv1');
to
$this->curlOption(CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);

http://magento.stackexchange.com/questions/73748/magento-1-9-2-unknown-cipher-in-list-tlsv1

I'd just like to log this here: Login on safari sometimes broken

http://magento.stackexchange.com/questions/49134/customers-couldnt-login-from-safari-in-magento-1-9/63089#63089

We always kept the domain attribute empty - but suddenly had to fill this out. (which is not our preference) ... the link may contain a fix. But this is for the 'session expert' ;P

    /**
     * Change current working directory
     *
     * @param string $dir
     * @return boolean
     */
    public function cd($dir)
    {
        if( is_dir($dir) ) {
            @chdir($this->_iwd);
            $this->_cwd = realpath($dir);
            return true;
        } else {
            throw new Exception('Unable to list current working directory.');
            return false;
        }
    }

The thrown exception is superflous and breaks the interface.

I merged the openMage-mirror State/Tag/Commit into a new branch 1.9.3.1 here.
I would like to have someone review it, so we can make it to the new default branch.

Inchoo/Inchoo_PHP7@bba4bfd

Magento backend in product edit page, go to "upsells" and then put some value into fields for filtering "position" column.
Click "search"
you will get a fatal error:

Fatal error: Call to a member function getBackend() on a non-object in app/code/core/Mage/Eav/Model/Entity/Abstract.php on line 816

Call Stack:
    0.0003     136612   1. {main}() index.php:0
    0.0009     187188   2. Mage::run() index.php:88
    0.0027     342548   3. Mage_Core_Model_App->run() app/Mage.php:684
    0.0569    1786748   4. Mage_Core_Controller_Varien_Front->dispatch() app/code/core/Mage/Core/Model/App.php:354
    0.0607    1838772   5. Mage_Core_Controller_Varien_Router_Standard->match() app/code/Core/Mage/Core/Controller/Varien/Front.php:172
    0.0707    1930612   6. Mage_Core_Controller_Varien_Action->dispatch() app/code/core/Mage/Core/Controller/Varien/Router/Standard.php:254
    0.3573    6863216   7. Mage_Adminhtml_Catalog_ProductController->upsellGridAction() app/code/core/Mage/Core/Controller/Varien/Action.php:418
    0.6426   12500524   8. Mage_Core_Controller_Varien_Action->renderLayout() app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php:392
    0.6431   12501852   9. Mage_Core_Model_Layout->getOutput() app/code/core/Mage/Core/Controller/Varien/Action.php:390
    0.6431   12501912  10. Mage_Core_Block_Abstract->toHtml() app/code/core/Mage/Core/Model/Layout.php:555
    0.6447   12511452  11. Mage_Core_Block_Text_List->_toHtml() app/code/core/Mage/Core/Block/Abstract.php:920
    0.6447   12511764  12. Mage_Core_Block_Abstract->toHtml() app/code/core/Mage/Core/Block/Text/List.php:43
    0.6455   12512396  13. Mage_Adminhtml_Block_Widget_Grid->_beforeToHtml() app/code/core/Mage/Core/Block/Abstract.php:919
    0.6455   12512436  14. Mage_Adminhtml_Block_Widget_Grid->_prepareGrid() app/code/core/Mage/Adminhtml/Block/Widget/Grid.php:646
    0.7784   13525688  15. Mage_Adminhtml_Block_Catalog_Product_Edit_Tab_Upsell->_prepareCollection() app/code/core/Mage/Adminhtml/Block/Widget/Grid.php:639
    0.8102   13727904  16. Mage_Adminhtml_Block_Widget_Grid->_prepareCollection() app/code/core/Mage/Adminhtml/Block/Catalog/Product/Edit/Tab/Upsell.php:123
    0.8126   13755416  17. Mage_Adminhtml_Block_Widget_Grid->_setFilterValues() app/code/core/Mage/Adminhtml/Block/Widget/Grid.php:519
    0.8133   13756108  18. Mage_Adminhtml_Block_Catalog_Product_Edit_Tab_Upsell->_addColumnFilterToCollection() app/code/core/Mage/Adminhtml/Block/Widget/Grid.php:457
    0.8133   13756108  19. Mage_Adminhtml_Block_Widget_Grid->_addColumnFilterToCollection() app/code/core/Mage/Adminhtml/Block/Catalog/Product/Edit/Tab/Upsell.php:87
    0.8135   13756620  20. Mage_Eav_Model_Entity_Collection_Abstract->addFieldToFilter() app/code/core/Mage/Adminhtml/Block/Widget/Grid.php:472
    0.8135   13756620  21. Mage_Catalog_Model_Resource_Product_Collection->addAttributeToFilter() app/code/core/Mage/Eav/Model/Entity/Collection/Abstract.php:341
    0.8135   13756648  22. Mage_Eav_Model_Entity_Collection_Abstract->addAttributeToFilter() app/code/core/Mage/Catalog/Model/Resource/Product/Collection.php:1438
    0.8136   13756648  23. Mage_Eav_Model_Entity_Collection_Abstract->_getAttributeConditionSql() app/code/core/Mage/Eav/Model/Entity/Collection/Abstract.php:321
    0.8136   13756676  24. Mage_Eav_Model_Entity_Abstract->isAttributeStatic() app/code/core/Mage/Eav/Model/Entity/Collection/Abstract.php:1379

tested with Magento 1.9.2

Sorry if this is not the appropriate place for this discussion, just let me know if I should move it elsewhere. I just have some questions about the project:

Is there any collaboration with Magento, Inc to get these fixes merged in the official Magento? I assume the lifetime of M1 is nearing it's end but it seems like a good opportunity to improve the original product since you are essentially doing what they say they don't have time to do (manage issues and pull requests).

Where do you draw the line between an appropriate PR and an inappropriate one? Examples:

• I determined that storing the admin ACL inside each session is a terrible design and it is better to cache the ACL and just store the admin user_id in the session. This results in huge session storage reductions and fixes some issues with ACL not being reloaded when it should. I can implement it so that existing sessions are not broken and will be gracefully updated and the public/protected class interface is 100% compatible so there is 0 impact to users but it is a somewhat significant change otherwise.
• Similarly space in sessions can be saved by moving the validator data to it's own key and not duplicating it for every namespace.
• Vardoc fixes/improvements that make code completion work with PhpStorm much much better (e.g. using @return $this, fixing incorrect vardocs, adding @method annotations like @method Mage_Catalog_Model_Product[] getIterator(), etc).

Eh, I forgot all of the fixes and improvements I've made offhand but in general what are the rules for accepting/rejecting?

Thanks for your contributions!

This is a note to improve global search. If someone already has some working code then this is great.

Things to improve, maybe there is more

• replace search with %STRING%, orders numbers like %STRING (often we only get last couple of digits xxx not the leading 300000xxxx)
• search for lastname, firstname, email, order number
• if ordernumber found then show orders first
• if customer data used to localize then show customer data first
• improve 2nd line small font span element (giving extra information)
• add store name to order number in results
• sort by last created orders first (this is probably what the customer is calling about)
• add some index because the search can be really really slow (try using it with someone on the telephone)

Many people have problems after the patch because using php-fpm or similiar.
I think it would be a good idea to change lib/Varien/File/Uploader.php to work again on such systems.

Magento general speed improvements

Would it make sense to add some or all of the tips mentioned in slide 22+ onwards?

http://www.slideshare.net/ivanchepurnyi/making-magento-flying-like-a-rocket-a-set-of-valuable-tips-for-developers

Some seem a real quick win

Magento error: Front controller reached 100 router match iterations

I recall seeing an issue about this here but I could not find it

Apparently according to the link below this is a confirmed error and a fix exists

Can we apply this fix against the code? (sorry I dont know how to diff against github)

Please confirm and apply fix

https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-good-news-a-patch-from-magento

https://github.com/convenient/magento-ce-ee-config-corruption-bug/blob/master/PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh#L172

See http://firebearstudio.com/blog/catalog-price-rules-core-bug-in-magento-ce-1-9-1-and-ee-1-14-1-0-array-to-string-conversion-error-and-incorrect-price-rules-behavior.html for further information and a patch

So far the issue is still "In progress" on magento bug tracker: http://www.magentocommerce.com/bug-tracking/issue/index/id/278
Is this the kind of things that you'd like to include? What would be the process then?

Would you consider adopting composer and registering with the Firegento repository? You already have all versions properly tagged, along with Magento composer installer this could be very useful for a lot of people.

SUPEE-389: Every time the catalog URL is rendexed, a new custom rewrite is created
https://gist.github.com/piotrekkaminski/c348538ca91ba35773be

Magento calls cleanCache on before_save in product even if there is no product ID yet (product was just created).
This can lead to unnecessary cache clearing.

see
https://github.com/OpenMage/magento-lts/blob/1.9.2.1/app/code/core/Mage/Catalog/Model/Product.php#L618

the clean cache should be wrapped in
if ($this->getId()) {
}

I was just hit by this issue in promo rules.
In Magento >= 1.14.1.0 or 1.9.1.0 if you use "total quantity is 3 for a subselection of items in the cart..." rule, Magento will go out of memory because of the infinite recursion.

See great explanation and hotfix in the stackoverflow:
http://magento.stackexchange.com/questions/53777/magento-enterprise-1-14-1-0-shopping-cart-price-rules-promotion-fatal-erro

Hello guys,

I'm following this project closely and trying to understand if dropping the default 1.9.2.4 and move to magento-lts has benefits and if it also provides stability to run it on production. Thank you!

On a quick hop through the 1.9.2.4-branch tree I found some orphan files like connect package xmls from Magento 1.9.1.0.

https://github.com/OpenMage/magento-lts/tree/1.9.2.4/var/package

I have not investigated further (like doing a real diff on a vanilla 1.9.2.4), but things like this always made me suspiciously looking at "public magento mirrors".
Of course, nobody will ever do a mage upgrade-all when using this repo.
But what I wanted to pick up basically: is it the only "merge-fail"?

This is not a rant, I rather want to point out a serious problem.

including fix

http://magento.stackexchange.com/questions/43939/allowed-countries-keeps-resetting-to-all/43961#43961

Should we mv install.php?

Just saw some request being made on our server to install.php - after upgrading via LTS this file is recreated everytime.

Question: how logic is it that a newby user would use LTS as a first time Magento install? And can we move or rename install.php so it is not executed anymore

Anyone installing from here can anyways read the README and read something like rename file "xxx" to install.php before installing

Hello,

since upgrading our shop to Mag. 1.9 we have some problems with paypal orders caused by rounding problems.

Found a working solution at https://www.kreativundsoehne.de/blog/magento-rundungsfehler-in-version-1-9-x.html

Would you includes this here to keep it update-safe? If "yes" i could also add an admin option to turn this on/off if desired.

http://magento.stackexchange.com/questions/105068/mage-cookies-clear-not-working

Have not taken the time to validate this, but sounds like a valuable thing to patch

Session Garbage collector in Magento uses delete query without limit to remove old sessions.
See
https://github.com/OpenMage/magento-lts/blob/1.9.3.0/app/code/core/Mage/Core/Model/Resource/Session.php#L280

On instances with tons of sessions this causes long lasting lock on the session table blocking the whole website rendering.

Magento tries to cleanup old sessions every 50 sessions, so it's very often. So most of the time, Magento will scan the whole session table for nothing.

I think we should increase the _automaticCleaningFactor to at last 1000, or even disable automatic GC and provide a cron job instead. Another solution would be to add a check to GC to execute it maximum once a day ...

https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong

Mage_Core_Model_Encryption uses Varien_Crypt which implements mcrypt by default.
I propose the following:

• Add Varien_Crypt_Openssl to implement encryption via Openssl using whatever the best practices are for secure encryption.
• Read a config key global/crypt/method to get a specific method if specified. Default to mcrypt if not specified for backwards compatibility.
• Add global/crypt/method -> openssl to the local.xml.template so that for new installations the default is openssl. I don't really care to support platforms without openssl so I don't even know if one exists or if they are common but I think it is perfectly reasonable to require a supported encryption library for an ecommerce platform.. It can easily be added to list of modules required during install.
• Write a script to migrate encrypted data from old method/key to new method/key. (find all encrypted config values, decrypt, re-encrypt with new key/method and save over old local.xml)
  • Note, Magento CE had a major bug up until 1.8/1.9 whereby a VERY poor encryption key was generated at installation so without a migration script if you are using one of these keys you basically might as well not even be using any encryption it is so bad. I tried to raise this with Magento on a magento2 issue but my warnings were completely ignored since they already have such a migration script for EE apparently.

EDIT:
Oh yeah, mcrypt will be deprecated in PHP 7.1 and removed in the version after. More info: https://wiki.php.net/rfc/mcrypt-viking-funeral

is there a specific reason why the type is set to magento-source? Other projects choose magento-core which is supported by at least 2 composer installers

Installer error in with: magento-sample-data-1.9.2.4-2016-10-11-07-38-13

in:
\app\code\core\Mage\Customer\sql\customer_setup\upgrade-1.6.2.0.4-1.6.2.0.5.php

$table = $installer->getConnection()
    ->newTable($installer->getTable('customer/flowpassword'))
    ->addColumn('flowpassword_id', Varien_Db_Ddl_Table::TYPE_INTEGER, null, array(

fix:

$installer->startSetup();
if (!$installer->getConnection()->tableColumnExists($installer->getTable('customer/flowpassword'), 'flowpassword_id')) {
  $table = $installer->getConnection()