'm new to Magento, after installation of Magento 2 community edition.I am not able to access the admin panel. I am getting below error.
This web page has a redirect loop
Error ERR_TOO_MANY_REDIRECTS
Please help me to resolve the issue. Advance thanks to all.
Solution
php bin/magento config:set web/unsecure/base_url http://example.local/
php bin/magento config:set web/secure/base_url https://example.local/
php bin/magento config:set web/secure/use_in_adminhtml 1php bin/magento cache:flush
I am getting error while using plugin before have any one idea why it is happening?
Fatal error: Uncaught ArgumentCountError: Too few arguments to function Puneet\Test\Model\Plugin\Name::beforegetName(), 1 passed in /var/www/html/m2/vendor/magento/framework/Interception/Interceptor.php on line 121 and exactly 2 expected in /var/www/html/m2/app/code/Puneet/Test/Model/Plugin/Name.php:15 Stack trace: #0 /var/www/html/m2/vendor/magento/framework/Interception/Interceptor.php(121): Puneet\Test\Model\Plugin\Name->beforegetName(Object(Magento\Catalog\Model\Product\Interceptor)) #1 /var/www/html/m2/vendor/magento/framework/Interception/Interceptor.php(153): Magento\Catalog\Model\Product\Interceptor->Magento\Framework\Interception\{closure}() #2 /var/www/html/m2/generated/code/Magento/Catalog/Model/Product/Interceptor.php(26): Magento\Catalog\Model\Product\Interceptor->___callPlugins('getName', Array, Array) #3 /var/www/html/m2/vendor/magento/module-catalog/Helper/Product/View.php(119): Magento\Catalog\Model\Product\Interceptor->getName() #4 /var/www/html/m2/vendor/magento/module-catalog/Helper/Product/View.php(28 in /var/www/html/m2/app/code/Puneet/Test/Model/Plugin/Name.php on line 15
My class and before method is.
<?php
/*
* Puneet_Test
* Name change
*/
namespace Puneet\Test\Model\Plugin;
class Name {
// public function aftergetName(\Magento\Catalog\Model\Product $subject, $result){
// return "SS: " . $result;
// }
public function beforegetName(\Magento\Catalog\Model\Product $subject, $name){
return $result . "SS";
}
}
Click here for real example video
What is Factory
class in Magento 2
Overview
Factory classes are service class that instantiate
non-injectable classes, that is, models that represent a database entity.
They create a layer of abstraction between the ObjectManager and
business code.
Relationship to ObjectManager
The Magento\Framework\ObjectManager is the class responsible for instantiating objects in
the Magento application. Magento prohibits depending on and directly using
the ObjectManager in
your code.
Factories are an exception to this rule because
they require the ObjectManager to instantiate specific models.
The following example illustrates the relationship between a
simple factory and the ObjectManager:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
namespace Magento\Framework\App\Config; class BaseFactory { /** * @var
\Magento\Framework\ObjectManagerInterface */ protected $_objectManager; /** * @param
\Magento\Framework\ObjectManagerInterface $objectManager */ public function __construct(\Magento\Framework\ObjectManagerInterface $objectManager) { $this->_objectManager = $objectManager; } /** * Create config model * @param
string|\Magento\Framework\Simplexml\Element $sourceData * @return
\Magento\Framework\App\Config\Base */ public function create($sourceData = null) { return $this->_objectManager->create(\Magento\Framework\App\Config\Base::class, ['sourceData' => $sourceData]); } } |
Writing factories
Unless you require specific behavior for your factory
classes, you do not need to explicitly define them because they are an automatically generated class type. When you
reference a factory in a class constructor, Magento’s object manager generates the factory class
if it does not exist.
Factories follow the naming convention <class-type>Factory where <class-type> is
the name of the class the factory instantiates.
For example the automatically generated Magento\Cms\Model\BlockFactory class
is a factory that instantiates the class Magento\Cms\Model\Block.
Using factories
You can get the singleton instance of a factory for a
specific model using dependency injection.
The following example shows a class getting the BlockFactory instance
through the constructor:
|
1 2 3 |
function __construct ( \Magento\Cms\Model\BlockFactory $blockFactory)
{ $this->blockFactory = $blockFactory; } |
Calling the create() method on a factory gives you
an instance of its specific class:
|
1 |
$block
= $this->blockFactory->create(); |
For classes that
require parameters, the automatically generated create() function accepts an array of
parameters that it passes on to the ObjectManager to create the target class.
The example below shows the construction of a \Magento\Framework\FlagFactory object
by passing in an array of parameters to a factory:
|
1 2 |
$flag
= $this->flagFactory->create([
'data' => ['flag_code' =>
'something'] |
The Flag class has a $data constructor parameter which
corresponds to the data key in the create array above.
Interfaces
Factories are smart enough to resolve dependencies and allow
you to get the correct instance of an interface as defined in your
module’s di.xml.
For example, in the CatalogInventory module,
the di.xml file
contains the following entry:
|
1 |
<preference for="Magento\CatalogInventory\Api\Data\StockItemInterface" type="Magento\CatalogInventory\Model\Stock\Item" /> |
It instructs Magento to
use the specific Item class wherever
the StockItemInterface is
used. When a class in that module includes the factory StockItemInterfaceFactory as
a dependency, Magento generates a factory that is capable of creating the
specific Item objects.
As the manual says in Copying Databases you can pipe the dump directly into the mysql client:
mysqldump db_name | mysql new_db_name
If you're using MyISAM you could copy the files, but I wouldn't recommend it. It's a bit dodgy.
Integrated from various good other answers
Both mysqldump and mysql commands accept options for setting connection details (and much more), like:
mysqldump -u <user name> --password=<pwd> <original db> | mysql -u <user name> -p <new db> Example : mysqldump -u root -pmypassword old_database | mysql -u root -pmypassowrd new_database
Proxies Design
Pattern
Proxies is a powerful and
easy technique to help you overcome a huge problem of Magento 2. Basically, we
can say it is design pattern, which is remove cycle of dependency injection.
However, its role and importance are still underestimated. Therefore, in this
post, I am going to help you to understand what is Magento 2 proxies and
its need in Magento 2.
Just similar to design patterns which are created to solve a
cycle of dependency problems in the project, proxy design pattern solves a
particular problem. Proxies work as a surrogate which means it acts on behalf
of others, in programming, they are classes which could be used instead of any
other class. More specifically, in Magento 2, proxies are used to replace
resource hungry classes.
However, when replacing like that, an issue happens in Magento 2
In Magento 2 your able use constructor injection pattern to
flexibly manage your class dependencies. However, constructor injection also
means that a chain reaction of object instantiation is often the result when
you create an object. (The original object has dependencies that have
dependencies, and those objects have dependencies, and so on.)
If a
class’s constructor is particularly resource-intensive, this can lead to
unnecessary performance impact when another class depends on it, if the
expensive object does not end up being needed during a particular request. (You
can display a dependency graph of such objects
by enabling profiling.)
As an
example, consider the following two classes:
123456789101112131415161718192021222324252627282930313233 |
class SlowLoading { public function __construct() { // ... Do something resource intensive } public function getValue() { return 'SlowLoading value'; } } class FastLoading { protected $slowLoading; public function __construct( SlowLoading $slowLoading ){ $this->slowLoading = $slowLoading; } public function getFastValue() { return 'FastLoading value'; } public function getSlowValue() { return $this->slowLoading->getValue(); } } |
Assume that class SlowLoading has a
non-trivial performance impact when instantiated (perhaps due to a complex
database query or a call to a third-party web API). Because of the dependency
injection in the constructor of FastLoading, this impact is
incurred if FastLoading is instantiated. Note, however, that the SlowLoading instance is used only in the method getSlowValue, meaning that the resource cost is unnecessary if this method
is never called on the FastLoading object.
Magento
has a solution for this situation: proxies. Proxies extend
other classes to become lazy-loaded versions of them. That is, a real instance
of the class a proxy extends is created only after one of the class’s methods
is actually called. A proxy implements the same interface as the original class
and so can be used as a dependency anywhere the original class can. Unlike its
parent, a proxy has only one dependency: the object manager.
Proxies
are generated code and therefore do not need to be manually written. (See Code
generation for more information.) Simply reference a class in the form \Original\Class\Name\Proxy, and the class is generated if it
does not exist.
Using
the preceding example, a proxy can be passed into the constructor arguments
instead of the original class, using DI configuration as follows:
12345 |
<type name="FastLoading"> <arguments> <argument name="slowLoading" xsi:type="object">SlowLoading\Proxy</argument> </arguments> </type> |
With
the proxy used in place of SlowLoading, the SlowLoading class will not be instantiated—and therefore, the resource
intensive constructor operations not performed—until the SlowLoading object is used (that is, if the getSlowValue method is called).
Because
DI configuration is used to inject a proxy, proxies can be dropped in to
replace their corresponding classes - or proxy replacements removed -
without touching application code.
As a
practical example of a proxy, you can see the StoreManager class and
then see the generated StoreManager proxy
class.
The
following excerpt from the Magento code passes the storeManager argument as a proxy to the Magento\Store\Model\Resolver\Store class. The StoreManagerInterface model is defined as a proxy
class by the added Proxy at the end of the original class in the di.xml file.
12345 |
<type name="Magento\Store\Model\Resolver\Store"> <arguments> <argument name="storeManager" xsi:type="object">Magento\Store\Model\StoreManagerInterface\Proxy</argument> </arguments> </type> |
If you want to know. your Magento 2 website is running on which environment you can run below command on terminal and very easily you can kn...
