Can verify, also experiencing this exact issue.
Indeed, can confirm as well on a clean 2.2.4 installation.
It only happens on storeview level, on website or global level, it works as expected.
I can not reproduce this on a clean 2.2.3 installation, so it looks like this is a new bug in 2.2.4, yay!
@sferreira-nicopu just adding myself to the conversation since we experienced the same issue yesterday after updating our Magento Commerce Cloud to this version
I am seeing this issue as well but trying to update logo and save.
+1
Class Magento\Email\Model\AbstractTemplate
:
$this->area
is already setted to adminhtml when $this->emailConfig->getTemplateArea($templateId)
return frontend.
note: $templateId
is equal to "design_email_header_template"
public function setForcedArea($templateId)
{
if ($this->area) {
throw new \LogicException(__('Area is already set'));
}
$this->area = $this->emailConfig->getTemplateArea($templateId);
return $this;
}
shouldn't we have this code instead ??
public function setForcedArea($templateId)
{
if (!isset($this->area)) {
$this->area = $this->emailConfig->getTemplateArea($templateId);
}
return $this;
}
here a stacktrace :
[2018-05-04 10:44:23] main.CRITICAL: Exception message: Area is already set
Trace: #0 /var/www/mysite/www.mysite/vendor/magento/module-theme/Model/Design/Config/Validator.php(117): Magento\Email\Model\AbstractTemplate->setForcedArea('design_email_he...')
#1 /var/www/mysite/www.mysite/vendor/magento/module-theme/Model/Design/Config/Validator.php(68): Magento\Theme\Model\Design\Config\Validator->getTemplateText('design_email_he...', Object(Magento\Theme\Model\Data\Design\Config))
#2 /var/www/mysite/www.mysite/vendor/magento/module-theme/Model/DesignConfigRepository.php(91): Magento\Theme\Model\Design\Config\Validator->validate(Object(Magento\Theme\Model\Data\Design\Config))
#3 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(58): Magento\Theme\Model\DesignConfigRepository->save(Object(Magento\Theme\Model\Data\Design\Config))
#4 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(138): Magento\Theme\Model\DesignConfigRepository\Interceptor->___callParent('save', Array)
#5 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(153): Magento\Theme\Model\DesignConfigRepository\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Theme\Model\Data\Design\Config))
#6 /var/www/mysite/www.mysite/generated/code/Magento/Theme/Model/DesignConfigRepository/Interceptor.php(39): Magento\Theme\Model\DesignConfigRepository\Interceptor->___callPlugins('save', Array, Array)
#7 /var/www/mysite/www.mysite/vendor/magento/module-theme/Controller/Adminhtml/Design/Config/Save.php(75): Magento\Theme\Model\DesignConfigRepository\Interceptor->save(Object(Magento\Theme\Model\Data\Design\Config))
#8 /var/www/mysite/www.mysite/generated/code/Magento/Theme/Controller/Adminhtml/Design/Config/Save/Interceptor.php(24): Magento\Theme\Controller\Adminhtml\Design\Config\Save->execute()
#9 /var/www/mysite/www.mysite/vendor/magento/framework/App/Action/Action.php(107): Magento\Theme\Controller\Adminhtml\Design\Config\Save\Interceptor->execute()
#10 /var/www/mysite/www.mysite/vendor/magento/module-backend/App/AbstractAction.php(229): Magento\Framework\App\Action\Action->dispatch(Object(Magento\Framework\App\Request\Http))
#11 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(58): Magento\Backend\App\AbstractAction->dispatch(Object(Magento\Framework\App\Request\Http))
#12 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(138): Magento\Theme\Controller\Adminhtml\Design\Config\Save\Interceptor->___callParent('dispatch', Array)
#13 /var/www/mysite/www.mysite/vendor/magento/module-backend/App/Action/Plugin/Authentication.php(143): Magento\Theme\Controller\Adminhtml\Design\Config\Save\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http))
#14 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(135): Magento\Backend\App\Action\Plugin\Authentication->aroundDispatch(Object(Magento\Theme\Controller\Adminhtml\Design\Config\Save\Interceptor), Object(Closure), Object(Magento\Framework\App\Request\Http))
#15 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(153): Magento\Theme\Controller\Adminhtml\Design\Config\Save\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http))
#16 /var/www/mysite/www.mysite/generated/code/Magento/Theme/Controller/Adminhtml/Design/Config/Save/Interceptor.php(39): Magento\Theme\Controller\Adminhtml\Design\Config\Save\Interceptor->___callPlugins('dispatch', Array, NULL)
#17 /var/www/mysite/www.mysite/vendor/magento/framework/App/FrontController.php(55): Magento\Theme\Controller\Adminhtml\Design\Config\Save\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))
#18 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(58): Magento\Framework\App\FrontController->dispatch(Object(Magento\Framework\App\Request\Http))
#19 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(138): Magento\Framework\App\FrontController\Interceptor->___callParent('dispatch', Array)
#20 /var/www/mysite/www.mysite/vendor/mymodule/m2-module-core/Plugin/App/FrontController.php(122): Magento\Framework\App\FrontController\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http))
#21 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(135): Module\Core\Plugin\App\FrontController->aroundDispatch(Object(Magento\Framework\App\FrontController\Interceptor), Object(Closure), Object(Magento\Framework\App\Request\Http))
#22 /var/www/mysite/www.mysite/vendor/magento/framework/Interception/Interceptor.php(153): Magento\Framework\App\FrontController\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http))
#23 /var/www/mysite/www.mysite/generated/code/Magento/Framework/App/FrontController/Interceptor.php(26): Magento\Framework\App\FrontController\Interceptor->___callPlugins('dispatch', Array, Array)
#24 /var/www/mysite/www.mysite/vendor/magento/framework/App/Http.php(135): Magento\Framework\App\FrontController\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))
#25 /var/www/mysite/www.mysite/generated/code/Magento/Framework/App/Http/Interceptor.php(24): Magento\Framework\App\Http->launch()
#26 /var/www/mysite/www.mysite/vendor/magento/framework/App/Bootstrap.php(256): Magento\Framework\App\Http\Interceptor->launch()
#27 /var/www/mysite/www.mysite/pub/index.php(37): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http\Interceptor))
#28 {main} [] []
getting the same fault.
Hi gtlt,
You are absolutely right in the world !!!
When we change in Magento\Email\Model\AbstractTemplate.php this:
public function setForcedArea($templateId)
{
if ($this->area) {
throw new \LogicException(__('Area is already set'));
}
$this->area = $this->emailConfig->getTemplateArea($templateId);
return $this;
}
For this:
public function setForcedArea($templateId)
{
if (!isset($this->area)) {
$this->area = $this->emailConfig->getTemplateArea($templateId);
}
return $this;
}
work!!! And they fill correctly core_config_data and design_config_grid_flat:
core_config_data: https://www.magentochile.cl/blog/wikis-images/bug/core_config_data.jpg
design_config_grid_flat: https://www.magentochile.cl/blog/wikis-images/bug/design_config_grid_flat.jpg
Would be good to have some regression testing for such things to potentially prevent such issues. How can we help here with tests?
@magentochile the class Magento\Email\Model\AbstractTemplate
didn't changed since last August, so I'm not sure changing the method setForcedArea
is the right solution, I didn't investigated to check if it has side effects (like on email generation, etc).
Hi, I also met the same problem
Same issue. Applied the code from above but I don't expect this is final solution. When it will be fixed?
Dear sirs, I think you have to look at:
$this->area = isset($data['area']) ? $data['area'] : null;
And trace it back as far as it goes ... now I'm setting up a Magento 2 store and I'm not letting go ... if I manage to finish the store, I'll follow up. Maybe see what he throws with a:
echo $data['area'];
var_dump($data['area']);
and look what it throws ... what's in $data['area'] that says it Area is already set!
Hm, if the class did not change did the interface or consumers change its usage?
Trying to change theme in fresh Magento 2.2.4 threw error "Something went wrong while saving this configuration: Area is already set". Any fix yet?
I'm too facing this issue on fresh install of magento 2.2.4
I experience the same issue on fresh install of 2.2.4
Not sure if this helps, but I CAN save the theme at the website level. The error only occurs for me at the store view level. Changing the theme and saving at the website level updates the store view's theme.
Right, global and website level work but not the store view level.
I am also having this issue. 2.2.4.
I was able to get around it by changing the theme_id value in core_config_data table manually. No known side effects yet.
Ive also start having this problem since I upgraded from 2.2.3 to 2.2.4 ...
I'll give it a try and try some bisecting tomorrow since this seems to affect many users and we do not yet have a solution or the cause of this.
Experiencing the same issue here Magento 2.2.4
Hey friends,
I stopped at my work, and I took another look at the error. And I did the essay to add echo $this->area, but in the "throw new" and it gave me the following result:
public function setForcedArea($templateId)
{
if ($this->area) {
// throw new \LogicException(__('Area is already set'));
throw new \LogicException(__($this->area));
}
$this->area = $this->emailConfig->getTemplateArea($templateId);
return $this;
}
And it gave me the result of:
Something went wrong while saving this configuration: adminhtml
The area "adminhtml" is that I think you should not assign the area to what corresponds to the frontend template. Here is documentation of that: https://devdocs.magento.com/guides/v2.0/architecture/archi_perspectives/components/modules/mod_and_areas.html
So what could be done a small fix, although it's not the right thing, could be like that (other than the "adminhtml" area):
public function setForcedArea($templateId)
{
// if ($this->area) {
if ($this->area !== 'adminhtml') {
throw new \LogicException(__('Area is already set'));
}
$this->area = $this->emailConfig->getTemplateArea($templateId);
return $this;
}
Look at the image below:
https://www.magentochile.cl/blog/wikis-images/bug/save-adminhtml-area.jpg
Regards,
Boris Dur谩n R.
This is the cause.
git bisect bad
d3aef7c3eef658baa00d3233d0352b5fed0f1cbe is the first bad commit
commit d3aef7c3eef658baa00d3233d0352b5fed0f1cbe
Author: Andrii Meysar <[email protected]>
Date: Wed Mar 21 18:16:42 2018 +0200
MAGETWO-89261: Template file 'header.html' is not found.
:040000 040000 7437b710bf3a7e2a357f9bfd71a6d488aa225812 9f8cf78d8757c7a8d1aa17ad0ec0b2ef6b433cf2 M app
Please all thoroughly test https://github.com/magento/magento2/pull/15137
https://github.com/magento/magento2/commit/3f6464da2c7cd4d7db8bf07cfbf51cc17ee1993a
Where can we get details about MAGETWO-89261: Template file 'header.html' is not found.
?
Which issue did it solve and should it be solved in another way?
@DanielRuf: it might be related to https://github.com/magento/magento2/issues/13530
Can you verify after your fix that this bug isn't triggered again (was only on global or website scope).
Thanks!
Can you verify after your fix that this bug isn't triggered again (was only on global or website scope).
Thanks!
I tested it in a fresh setup where I cloned magento/magento2 and did the bisecting directly and can reproduct it with the line and it is not happening without the line.
@DanielRuf: it might be related to #13530
Not reproducible with my change with a fresh 2.2-develop.
But I'll do some more tests now.
Hm, you are right Will provide another changeset for my PR.
@Krapulat I faced the same issue.
Open
Magento\Email\Model\AbstractTemplate.php file
and replace the function setForcedArea with this code
public function setForcedArea($templateId)
{
if (!isset($this->area)) {
$this->area = $this->emailConfig->getTemplateArea($templateId);
}
return $this;
}
This worked for me :100:
@DanielRuf: it might be related to #13530
Can you verify after your fix that this bug isn't triggered again (was only on global or website scope).
Thanks!
It is not directly related as the error with header.htl comes from the mail config as it seems. The forced area call is not the right solution here.
@fahadmunir158 thanks, will test it for my PR. But so far it feels like fixing one thing and another breaks it might be another issue.
In general I would do another bisecting to find the culprit of your issue @hostep, anything else is more like guessing and choosing any solution which might be the cause. When did it work and when was this introduced?
Also the setForcedArea docblock does not seem correct to me.
* @throws \Magento\Framework\Exception\MailException
...
throw new \LogicException(__('Area is already set'));
@fahadmunir158 your solution might be the correct one as the current code is 3 years old there and can be probably outdated.
@fahadmunir158 I pushed your proposed change to my PR. Please let me know if I should add you as Co-Author =)
@hostep I do not yet understand the connection between your issue number and the one which is referenced in the commit that caused this regression.
When did it work and when was this introduced?
I'm pretty sure the bug I reported didn't exist yet in 2.2.3, I ran into it while doing to some testing directly on the 2.2-develop
branch at that time, so I believe that particular bug was introduced somewhere between the 2.2.3 tag and the commit which turned out the be the cause of this new issue: https://github.com/magento/magento2/commit/d3aef7c3eef658baa00d3233d0352b5fed0f1cbe (or maybe even narrower, the commit I referenced in the report: f18377b9e598fd5316963f9e4deb7e54547a638c), but it's hard to say with all the branches which get merged all over the place in the Magento2 codebase.
Even though 2.2.3 was released after I reported the bug, I'm almost 100% sure the bug wasn't introduced yet in that version.
Hope this helps somehow :)
@hostep I do not yet understand the connection between your issue number and the one which is referenced in the commit that caused this regression.
It's related because the template file header.phtml
is being used by the email templating system. But you probably already knew this.
@hostep can you also do some bisecting here? If you do not know how bisecting works I can provide you with some hopefully information how this can be used to find regression and the causes of them.
magento2$ git bisect start
ssh-w00b8941@dd20014:/www/htdocs/websites/magento-bisect/magento2$ git bisect good f3f8975c3f48ad8d2a3221153bcce9f82a5b84b8
ssh-w00b8941@dd20014:/www/htdocs/magento-bisect/magento2$ git bisect bad 61c3ba691512d36001baedb22d58bab5cb16e05f
Bisecting: 1197 revisions left to test after this (roughly 10 steps)
[83a7c1cbad1ff0c01714296733f9ee80395469ca] MAGETWO-85904: Investigate fluctuations of PAT Nightly build
ssh-w00b8941@dd20014:/www/htdocs/websites/magento-bisect#/magento2$
This would be the first step.
I'll see if I can find some time in a couple of minutes. I'm familiar with bisecting, but it's a bit of a pain in Magento 2 because of the database migration system. Going forwards is doable, going backwards means you have to re-install the database again (sometimes). But it's doable.
I'll see what I can do.
I'm familiar with bisecting, but it's a bit of a pain in Magento 2 because of the database migration system
These changes should not be related to actual database changes.
Bisecting revealed this commit https://github.com/magento/magento2/commit/5e93220a56bd741d3ec27b8a0fffd2f539e4e473 (is a fix for https://github.com/magento/magento2/issues/8437). Yet I believe this commit does the correct thing and only revealed a deeper problem.
This is only guessing here: somehow by saving the design configuration, the email templating system tries to load an email template (otherwise it wouldn't try to load the header.phtml
file). Those email template files aren't available in the adminhtml area, they only exist in the frontend area (I think Update: this is not correct, email templates can exist both in the adminhtml & frontend area).
I think we need to figure out why when saving the design configuration the email templating system is trying to load an email template and we should try to disable that, that is probably the right fix.
This is all in theory, I'm not very familiar with all these systems, so I might be completely wrong :)
The email header and footer is a bit downwards at the design settings page of the global context.
It looks like the suggestion from @gtlt and the latest version of @DanielRuf's PR fixes both https://github.com/magento/magento2/issues/14968 & https://github.com/magento/magento2/issues/13530 and thinking about it, it is probably the best solution!
Personally I am still unsure if this is / would be the "right" fix (of the root cause) =)
Waiting for feedback from all other affected users who upvoted and replied.
Same Issue here "Something went wrong while saving this configuration: Area is already set" when try to change applied theme Magento CE 2.2.4.
I tried to write a plugin for this issue, but I couldn't get it to work: Since the $emailConfig property is protected I cannot access that property in my plugin. Is it even possible?
I tried to write a plugin for this issue
Why?
There is already an open PR which solves this. Please test it.
See https://github.com/magento/magento2/pull/15137
Hi @Krapulat. Thank you for your report.
The issue has been fixed in magento/magento2#15137 by @DanielRuf in 2.2-develop branch
Related commit(s):
The fix will be available with the upcoming 2.2.5 release.
I just want to confirm that this fix https://github.com/magento/magento2/commit/0dec988872e175e568c2bf4bb29548ab7a4698e5 did the job. I've tested it in clean Magento 2.2.4 and "Something went wrong while saving this configuration: Area is already set"
error doesn't show any more.
@magento/community-engineering-team ,
Can you please clarify
Can you please clarify
15137 is the Final PR for this issue?
Yes, this is the final PR which is already merged for 2.2.5.
@DanielRuf thanks
with that fix in place, you cannot save html head information at a store view level. It says it's saved correctly, but nothing changes.
@pixiemediaweb can you check if this happened before my changes?
Is there an issue for this bug?
hi, sorry that was a red herring, although it wasn't changing on the page, it was updating in the database. Flushed Magento cache and it's all working correctly again.
Hey @DanielRuf
I was going through the same issue. Thanks for the fix. Made changes in the file at this location
vendor/magento/module-email/Model/AbstractTemplate.php
The final function looks like below
public function setForcedArea($templateId)
{
if (!isset($this->area)) {
$this->area = $this->emailConfig->getTemplateArea($templateId);
}
return $this;
}
It now saves the theme on store view level and the other settings.
Thanks
@Vikram0811
it looks like this .
public function setForcedArea($templateId)
{
if (!isset($this->area)) {
$this->area = $this->emailConfig->getTemplateArea($templateId);
}
//$this->area = $this->emailConfig->getTemplateArea($templateId);
return $this;
}
It is already resolved in the current develop branches ;-)
@denda888, my bad. I have corrected the code.
@DanielRuf , yes it's been resolved in current develop branches, but as I have already started development in 2.2.4 I have fixed in my code setup.
Thanks.
Hi guys,
a small module to fix it without touching the core:
https://github.com/pfortin-expertime/MageFix-Misc
Enjoy :)
It is already fixed in current 2.2-develop.
composer-patches would be the right approach.
I am facing same issue. Seems like new bug in 2.2.4 version.
Let us know if it is solved.
I am facing same issue. Seems like new bug in 2.2.4 version.
Let us know if it is solved.
It will be resolved in 2.2.5
Thanks DanielRuf..
Silly issues like this one is what makes working with Magento2 really frustrating - 4 years into this project and these pesty bugs (that did not exist in M1) still come up 馃憥
@treestonemedia sorry but here we changed very old code to fix it in 2.2.5. So everything is fine.
In the meantime you can use composer patches.
@DanielRuf thanks for the help I didn't install through composer, how do i get the patch? (sorry for the Noob question)
@judaschwartz you can get apply a patch from pull request straightaway then: https://github.com/magento/magento2/pull/15137.patch
Note that normally you should install Magento via Composer.
@pfortin-expertime
How do I apply the Github Patch? Im installing from GoDaddy so Composer is no-no.
Do I put it in magento/app/design/frontend/Custom/theme-custom-less [my custom theme]
?
Also which files do I need to modify to change.. ?
public function setForcedArea($templateId)
{
if (!isset($this->area)) {
$this->area = $this->emailConfig->getTemplateArea($templateId);
}
return $this;
}
Hi @stephyswe,
How do you deploy to godaddy? You could still build a release on another machine via composer and then export the resulting build to godaddy. This way allowing you to use the preferred approach for Integrators of composer.
Hi, any reason why the fix is not in the new 2.2.5 release ?
It should be in 2.2.5. Where did you check the files?
I updated magento via composer from 2.2.4 -> 2.2.5 but my vendor/magento folder doesn't have the update. Maybe I made a mistake, I'll double check
Oh, seems so. The file was last changed in 2017
What happened here?
https://github.com/magento/magento2/blob/2.2.5/app/code/Magento/Email/Model/AbstractTemplate.php
That is what I had too. Weird
@magento-engcom-team https://github.com/magento/magento2/pull/15137#issuecomment-389654283
@orlangur
Was the wrong commit tagged for 2.2.5?
Hi @DanielRuf I will see what I can find out about this for you.
Has anyone else had issues with the visible setting caching after patching? We've patched a couple of sites and a client said today they cannot update a shipping method to 'off'. I tried it and confirmed it remained on 'yes' but the db value was updating. After flushing cache storage it is displaying correctly - but config settings in admin should not be cached.
Hi @DanielRuf it looks like there was a miss-configuration with our bot and it had the wrong cut of date for changes to make it into the 2.2.5 release. Sorry for any inconvenience this has caused but your changes will be in the next release.
Hi @DanielRuf it looks like there was a miss-configuration with our bot and it had the wrong cut of date for changes to make it into the 2.2.5 release. Sorry for any inconvenience this has caused but your changes will be in the next release.
Hm =(
When will be 2.2.6 released?
Is there a schedule where I can see the planned dates?
@DanielRuf I am not sure if we have a public date as yet but as part of the release notes for 2.2.5 there is a note about release cycles.
With Magento 2.2.5, we are moving to a quarterly release cycle for minor releases. Quarterly releases contain bug fixes, security enhancements, introduction of new bundled extensions, and community code contributions.
https://devdocs.magento.com/guides/v2.2/release-notes/bk-release-notes.html
@dmanners : Quarterly meaning only 4 times a year? Damn that's even worse then what we have currently :s
Luckily more and more people seem to know how to patch their installation ...
Hi @hostep I understand that this could be frustrating for a few people but if you compare this to other systems and frameworks this is still more frequent. For example, unless I am mistaken, Symfony still do minor releases twice a year and major releases every 2 years.
@dmanners : Quarterly meaning only 4 times a year? Damn that's even worse then what we have currently :s
I totally agree, this is worse than before.
Symfony still do minor releases twice a year and major releases every 2 years.
You can't really compare Symfony against Magento, because the versions numbering is different. In Magento a patch version is the same as a minor version in Symfony.
Any chance to introduce a fourth number in the versioning of Magento which is only for bugfixes (no new features, no performance improvements, no new bugs). And release those like every month or so?
@DanielRuf From my understanding Symfony follow Semver 2.0.0 which would mean that a version number would follow MAJOR.MINOR.PATCH so in this case they do a minor release in May and November of the year. Patches come out more often but minors will be around the May and November. For example: 4.0.0 came out on the 30th of Nov 2017 and the next minor version 4.1.0 came out on the 30th of May 2018. But yes they provide patch releases in between such as 4.0.1
Issue is still present in 2.2.5 clean instalation
@radub The issue will be fixed in 2.2.6. The bot posted the wrong fix version, please see https://github.com/magento/magento2/issues/14968#issuecomment-400960656 for a more detailed explanation.
I experienced same issue,
I have checked the following file and modify code accordingly as follow:
public function setForcedArea($templateId)
{
if (!isset($this->area)) {
// throw new \LogicException(('Area is already set'));
$this->area = $this->emailConfig->getTemplateArea($templateId);
}
return $this;
}
and Finally Its worked!
I guess you mean
if (!isset($this->area)) {
$this->area = $this->emailConfig->getTemplateArea($templateId);
}
return $this;
Nice to see that you guys fixed this issue 馃憤
However i would like to ask if anyone can explain how you can fix this with a composer install?
in my current env i don't see a Magento folder in app/
i also did a search in the vendor directory but could not find it so any help is welcome :).
@ghermans you can accomplish this 2 or 3 different ways.
update directly the deployed core code located here,
vendor/magento/module-email/Model/AbstractTemplate.php:535'ish
apply a git patch (I don't have the SHA for this option, but maybe someone @here could chime-in)
create a plugin yourself that will use dependency injection and setForcedArea like this
public function setForcedArea($templateId)
{
if (!isset($this->area)) {
$this->area = $this->emailConfig->getTemplateArea($templateId);
}
return $this;
}
https://github.com/pfortin-expertime/MageFix-Misc
Good luck
Thanks for the quick response and detailed feedback.
Additional: for number 2 of @EzzyEcom, use this method: https://support.magento.com/hc/en-us/articles/360005484154 to apply this commit using composer.
Hi Guys, Sorry, am a real newbie but have just spent a fair bit of money on having a Magento site designed for me in 2.2.5 and now I find I can't make any basic changes like logo for example which makes my site useless?? Does this happen often in Magento? I came over from Sellerdeck and now wishing I hadn't :-(
@rowneybury most logos and images are database/admin configurations.
along with CSS styling being some of the easiest changes that will definitely be vital to your site's up-keeping.
Word of advice, retain an agency or a Magento2 freelancer fullstack dev on like 10 hours a month basis to work thru all those bits and pieces you find yourself frustrated over.
Sorry @everyoneelse I know this topic is not related to this #15137 but I just had to help the next guy over.
@EzzyEcom Thanks for the prompt reply. Unfortunately I don't have the funds to have a developer on retainer. I'm surprised that this issue was known about in version 2.2.4 yet is still a problem in 2.2.5?? Odd way to work.
Thanks again for the reply
@rowneybury #15137 fix sounds like had a hiccup when it comes to being deployed on 2.2.5, but as mentioned previously in here, this will be automatically added by deploy bots on 2.2.6 in roughly about 2 months from now, if my math is right.
In the mean time, if your site was built leveraging Magento 2 modularity architecture by means of composer, then you can easily rollback version from 2.2.5 to 2.2.3 and go on for a while until 2.2.6 rolls out.
The other option is to patch your current version by following this simple GIT / composer instructions, Create a patch for a Magento 2 Composer to add commit SHA ...e9cb4ef2
Thanks again, I do appreciate the help. I think I need to speak to the company who installed my Magento and see if they can roll it back to 2.2.3, sounds like the easiest option. I will click the link you provided for creating a patch but fear it will mean nothing to me! :-)
Enjoy the rest of your weekend.
FYI I created patch that can be applied on Magento 2.2.5. Just use following URL:
https://github.com/ihor-sviziev/magento2/commit/e4ec8adef586c615cda168175ad8950c701b0874.patch
what a shame.... I am considering migrating to django / python
Nice to see that you created a patch for it @ihor-sviziev 馃憤
However this issue should be resolved with a "hotfix" release (at least that is my personal opinion).
@ghermans : Magento 2 doesn't do hotfix releases unfortunately.
However, they've released an official patch over here: https://magento.com/tech-resources/download (search for MAGETWO-93036)
As @EzzyEcom is saying, this problem is still in 2.2.5 ? on production server it's a hassle to modify core code and fix it nor using a hotfix.
As @EzzyEcom is saying, this problem is still in 2.2.5 ? on production server it's a hassle to modify core code and fix it nor using a hotfix.
Yes, it will be fixed in 2.2.6.
This happens even in 2.2.5. Some people have provided the solution but this is a patch to the core and it's not considered a permanent solution. Hope community fixed this in the new version and release it soon.
This happens even in 2.2.5. Some people have provided the solution but this is a patch to the core and it's not considered a permanent solution. Hope community fixed this in the new version and release it soon.
Please read the previous comments, this will be fixed in 2.2.6. The bot communicated a wrong date.
Having same problem,
Magento 2.2.5
can't save "default page title" in Content > Design > Configuration
Having same problem,
Magento 2.2.5can't save "default page title" in Content > Design > Configuration
Please just upvote at the top, do not comment I have this too
. We are aware that it is not yet fixed but will be in 2.2.6.
Hello Friends!
I was taking a look into this issue today and noticed that this error only seems prevalent when attempting to change the theme in the Global Configuration itself. If you change the theme in the Store View specifically it will be inherited by the Website and Global Configurations. I tested this with fresh installations of Magento 2.2.5 across multiple domains and was consistently able to change the theme by editing the Store Configuration specifically.
For example:
In this case you would want to change the theme in the Store Configuration (First Row) which would then be inherited by the Website Configuration (Second Row) and Global Configuration (Third Row). I only experience this error when attempting to edit the Global Configuration (Third Row) directly.
(Please note that rows are in reference to the provided screenshot only.)
Hello Friends!
I was taking a look into this issue today and noticed that this error only seems prevalent when attempting to change the theme in the Global Configuration itself. If you change the theme in the Store View specifically it will be inherited by the Website and Global Configurations. I tested this with fresh installations of Magento 2.2.5 across multiple domains and was consistently able to change the theme by editing the Store Configuration specifically.
For example:
In this case you would want to change the theme in the Store Configuration (First Row) which would then be inherited by the Website Configuration (Second Row) and Global Configuration (Third Row). I only experience this error when attempting to edit the Global Configuration (Third Row) directly.
(Please note that rows are in reference to the provided screenshot only.)
This is all already known, please see the previous comments and the linked PR.
For those wo need a fix and can not update the entry in the database, see https://github.com/magento/magento2/issues/14968#issuecomment-404536405
You need the patch from https://magento.com/tech-resources/download#download2224 as this is probably in your vendor directory (composer based installs).
You can use composer-patches, also see https://support.magento.com/hc/en-us/articles/360005484154
And use this diff / patch:
https://github.com/magento/magento2/commit/7019a0a1392095185505ff3ca7b97dd3e9cb4ef2.diff
https://github.com/magento/magento2/commit/7019a0a1392095185505ff3ca7b97dd3e9cb4ef2.patch
Hi @oroskodias why did you delete @hostep comment?
He deleted his own comment as well, don't worry, it wasn't adding anything new to the discussion :)
Most helpful comment
Can verify, also experiencing this exact issue.