Automation template listing [MAILPOET-4533] #4362
Conversation
[MAILPOET-4533]
[MAILPOET-4533]
[MAILPOET-4533]
[MAILPOET-4533]
[MAILPOET-4533]
[MAILPOET-4533]
[MAILPOET-4533]
[MAILPOET-4533]
mailpoet/lib/Automation/Engine/Endpoints/Workflows/WorkflowsCreateFromTemplateEndpoint.php
Outdated
Show resolved
Hide resolved
| 'mailpoet-automation-templates', | ||
| [$this, 'automationTemplates'] | ||
| ); | ||
|
|
There was a problem hiding this comment.
When I'm on page=mailpoet-automation-templates, I don't see MailPoet menu expanded and the "Automations" menu highlighted. We seem to have some solution for this that is used here, for instance.
There was a problem hiding this comment.
Good catch! Thank you! Addressed in ada0ed3
| setShowModal: Dispatch<SetStateAction<boolean>>; | ||
| }; | ||
|
|
||
| function FromScratchPremiumModal({ |
There was a problem hiding this comment.
For some reason, the modal renders differently than in other places.
Here:
Automation editor:
Is that some kind of an issue with how the modal handles styles, maybe? We need to be able to display this modal in the same way anywhere in the MailPoet admin.
There was a problem hiding this comment.
The automation listing as well as the templates page did enqueue wp-component styles. I removed this in d7140cf
There was a problem hiding this comment.
Ahh! And the removal is safe? Because we do use @wordpress/components so we need to load their styles somehow. In the editor, we bundle them now so I guess we need to bundle them also anywhere we use them and also within the modal?
It feels like removing these lines could break some existing styles, if @wordpress/components are used...
There was a problem hiding this comment.
In the editor, we bundle them now
We do so also in mailpoet-plugin.scss, which is loaded throughout the screens: https://github.com/mailpoet/mailpoet/blob/trunk/mailpoet/assets/css/src/mailpoet-plugin.scss#L24
I removed them now in 9fe003a from the mailpoet-automation-editor.scss as they are not needed there.
What we witness is an update of the styles (PR), This update affects Gutenberg version>13.7 while in WordPress core the current Gutenberg version is 13.0.
So, with our current way, we divert from core and "enqueue" the latest styles (or the styles of the components version, we require). Not entirely sure, if that's the best way (thinking of 3rd parties potentially enqueuing wp-components)
There was a problem hiding this comment.
Ahh, thanks for the explanation! Yeah, I guess at this point it's correct to "divert" in the styles because we're diverting also with the JS (bundling them instead of using @wordpress/dependency-extraction-webpack-plugin) which we may fix in the future. It would require supporting only few recent versions of WP, and testing the UI across them. For now, we picked the "easier" way and did what's done in the form editor.
mailpoet/assets/js/src/automation/templates/components/template-list-item.tsx
Show resolved
Hide resolved
| max-width: 982px; | ||
| } | ||
|
|
||
| ul.mailpoet-templates { |
There was a problem hiding this comment.
I guess we should include the automation in the prefix, and maybe the same below for mailpoet-from-scratch.
There was a problem hiding this comment.
Addressed in 2f42d2c
mailpoet/lib/Automation/Engine/Builder/CreateWorkflowFromTemplateController.php
Outdated
Show resolved
Hide resolved
[MAILPOET-4533]
[MAILPOET-4533]
[MAILPOET-4533]
| @@ -2,6 +2,7 @@ | |||
|
|
|||
| namespace MailPoet\Automation\Engine\Builder; | |||
|
|
|||
| use _PHPStan_ae8980142\Nette\InvalidStateException; | |||
There was a problem hiding this comment.
Ups 😄 Your IDE did this, I guess.
There was a problem hiding this comment.
🤦 Addressed in 17e2f97
| setShowModal: Dispatch<SetStateAction<boolean>>; | ||
| }; | ||
|
|
||
| function FromScratchPremiumModal({ |
There was a problem hiding this comment.
Ahh! And the removal is safe? Because we do use @wordpress/components so we need to load their styles somehow. In the editor, we bundle them now so I guess we need to bundle them also anywhere we use them and also within the modal?
It feels like removing these lines could break some existing styles, if @wordpress/components are used...
[MAILPOET-4533]
[MAILPOET-4533]
[MAILPOET-4533]
websupporter
force-pushed
the
MAILPOET-4533-automation-template-listing
branch
from
d7140cf
to
c3f152e
Compare
They are already imported in mailpoet-plugin.scss [MAILPOET-4355]
| @@ -1,4 +1,3 @@ | |||
| @import '../../../node_modules/@wordpress/components/build-style/style'; | |||
There was a problem hiding this comment.
| setShowModal: Dispatch<SetStateAction<boolean>>; | ||
| }; | ||
|
|
||
| function FromScratchPremiumModal({ |
There was a problem hiding this comment.
Ahh, thanks for the explanation! Yeah, I guess at this point it's correct to "divert" in the styles because we're diverting also with the JS (bundling them instead of using @wordpress/dependency-extraction-webpack-plugin) which we may fix in the future. It would require supporting only few recent versions of WP, and testing the UI across them. For now, we picked the "easier" way and did what's done in the form editor.
Description
This PR adds the template listing page. You can reach the page by clicking the "New automation" button.
Linked PRs
https://github.com/mailpoet/mailpoet-premium/pull/622
Linked tickets
MAILPOET-4533