if magento reads from the catalog_product_flat_* table means that the flat products flag is set to yes and it's up to date and it's not locked.
If it reads from the catalog_product_entity table it means that the flat products flag is set to no or it's not up to date or is locked.
As simple as that.
If you say that you cloned the db from live to staging it ...
took the change to dive into this.
Installed a clean Magento Enterprise 22.214.171.124
Your rule still breaks without the first >15 rule...
It's origin is in the product subselection.
These two functions who are calling itself repeatedly.
The line in question returning the exception in CRedis:
NOTE the timeout causing because of the read meta data of the redis process stream. More than likely you've hit timeout & or memory limits possibly.
More details on stream_get_meta_data:
I'm running into this issue while upgrading from EE 126.96.36.199 to 188.8.131.52 right now. We experience this when bulk updating product attributes and stock in cronjobs. In 1.13, the jobs take ~3 seconds and ~90 seconds respectively. In 1.14, it's more like ~10 minutes and I-don't-want-to-know-how-long.
There is an EE patch PATCH_SUPEE-4945_EE_184.108.40.206_v2.sh ...
Don't do this, and just search for one of the many tools that can assist such as
Find non-whitelisted vars/blocks to be compatible with SUPEE-6788 and Magento >220.127.116.11
Thanks to @timvroom for the bulk of the code.
dev:template-vars [--addblocks[="true|false"]] [--addvariables[="true|false"]]
Well, I do not know whether the error is 100 % resolved or not. But based on what you told me here, and in this post :
https://dba.stackexchange.com/questions/40899/mysql-error-reading-communication-packets, I make this changes in the MySQL Config File:
max-allowed-packet = 1024M
wait-timeout = 7200
This is mostly due to any of the below two reasons
Server timed out and closed the connection.
fix: try increasing the wait_timeout variable in your mysqld’s my.cnf/my.ini configuration file.
Server dropped an incorrect or too large packet.
fix : increase the maximal packet size limit by increasing the value of max_allowed_packet in my.cnf/my.ini file.
the method getAllowProducts calls Mage_Catalog_Model_Product_Type_Configurable::getUsedProducts() that contains this code:
$collection = $this->getUsedProductCollection($product)
// Provides a mechanism for attaching additional attributes to the children of configurable products
// Will primarily have affect on the ...
In my case it was due because the configurable attribute used in the configurable product didn't have a backend_type equal to int but was a varchar. So the attribute was not found in the catalog_product_entity_int table which is needed in the class Mage_Catalog_Model_Resource_Product_Indexer_Price_Configurable to generate the price index.
The product - category relation s global. It does not depend on the store view or website. What you can do is to have a different category tree on the second website. But this will result in duplicate categories.
I can confirm this behavior on 18.104.22.168, and it seems like it's a bug.
If you look at how the report aggregation works, you'll find that in Mage_Reports_Model_Resource_Report_Abstract::_getTableDateRangeSelect() the group by date is done like this:
$select = $adapter->select()
array($alias => $table),
IMHO if your client already have an Enterprise 1.14.X you should evaluate:
How Many Customs / Modules your store have and how many time(money) you need to migrate such functionalities to M2
How much time you need to Re-Implement the store Theme (Believe me it's not trivial at all)
How important would be RabbitMQ Support or Database Split for your store ...
Going from EE 1.x to CE 1.x to CE 2.x will be more straightforward than direct from EE 1.x to CE 2.x. Going direct would involve modifying the data migration tool configuration to ignore enterprise table/columns, and removing EE references (attribute models, etc.) in the process.
Follow this post or the linked guide to go from EE 1.x to CC 1.x: https://...
You may use following code
This is no bad practice :)
The problem is this piece of code $product->save();.
The observer method is correct, but with this line catalog_product_save_after is triggered again, and again ... resulting in an infinite loop :)
Just as a note ... if you want to set data to the product catalog_product_save_before could fit better.
Edit: if you want to set ...
I think it might be the issue with your nginx configuration. Please add the below in nginx configuration. Basically, it may be the problem with the header and it is unable to pass too big data. It might solve your problem.
proxy_buffers 8 16k;
If it doesn't workout, please check by disabling the full page cache and try again. If it ...
You pretty much came to the correct conclusion. If you've got different values you need separate rules.
However if you've got same amounts you can generate codes which share rules.
The way I explain it is having rules for 10 off and 20 off. Each customer you want to give 10 off you generate a 10 off code. 20 a 20 off code.
So, if you are using attributes for configurable products and you want those attributes to be shown in the flat tables, you need to have the attributes configured so that they have the used_in_product_listing set to TRUE
This will then add the columns to the flat table assuming that you have the flat catalog product options set to Yes in the system config.
First, you need to customize the adminhtml equivalent of the template mentioned above, which would be: app/design/adminhtml/default/default/template/catalog/product/composite/fieldset/configurable.phtml.
The best way to accomplish this is to add a custom theme to your adminhtml so that you can override the template by copying it to app/design/adminhtml/...
Can/should cache tags in Magento be dynamic?...Is this the right way to use the cache tags?
Yes! This is exactly what cache tags are for - to group a number of cache entries together.
Here are some quotes from various blogs:
Cache tags exist so that we can selectively clear cache instances.
Source: Erfan Emani
The $data stored in the cache can also ...
Looking at that line (66) in /data/html/app/code/core/Mage/Adminhtml/Block/Widget/Grid/Container.php, we find the following code:
$this->getLayout()->createBlock( $this->_blockGroup.'/' . $this->_controller . '_grid',
$this->_controller . '.grid')->setSaveParametersInSession(true) );
It is ...
system > configuration > developer -> log settings -> Enabled set to YES
This settings are only for logs and it will allow system to create log in var/log folder with system.log and exception.log files.
In var/report folder system will generate fatal error reports. And above settings not used for var/report.