Problem/Motivation
Sometimes a landing page wants to add a splash widget to force the user looking at it.
If you need the same splash screen across many pages, using a Paragraph is possibly a bad fit and a block could be better.
But if this is a content requirement, it makes sense to put the information into a content paragraph and trigger its splashiness.
If that block is in the library, we could reuse it and bind the effect to only show once in all usages or whatever is needed.
Proposed resolution
Create a splash plugin that triggers a splash screen with the content of a Paragraph.
As i'm out of ideas what tool to use, i would simply start with the Plugin, triggering a jQuery UI Dialog with that content.
Behavior settings are:
- Checkbox: Remove content from page. (So it's not cloned into the splash, but the original is removed.)
And more settings if the splash is always reopened or a cookie (with lifetime X) is used to save that the splash is closed.
Not sure if it's closed by cookie and the setting "remove" is chosen, if we should still remove it from the page. ;-)
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#32 | new_plugin_splash_screen-2851461-32.patch | 18.65 KB | CTaPByK |
| |||
#30 | new_plugin_splash_screen-2851461-30.patch | 17.51 KB | CTaPByK |
| |||
#30 | interdiff-27-30.txt | 7.91 KB | CTaPByK |
#27 | new_plugin_splash_screen-2851461-27.patch | 17.32 KB | CTaPByK |
| |||
#22 | new_plugin_splash_screen-2851461-22.patch | 17.18 KB | CTaPByK |
|
Comments
Comment #2
Primsi CreditAttribution: Primsi at MD Systems GmbH for MD Systems GmbH commentedComment #3
miro_dietikerComment #4
CTaPByK CreditAttribution: CTaPByK commentedComment #5
CTaPByK CreditAttribution: CTaPByK commentedInitial patch.
Comment #7
CTaPByK CreditAttribution: CTaPByK commentedSchema update.
Comment #8
CTaPByK CreditAttribution: CTaPByK commentedUpdated with behavior settings and with basic test coverage.
Comment #9
miro_dietikerMind that it's a single cookie now. Users might want to use multiple independent splash screens on different pages. Just because one splash screen was clicked away doesn't mean other splashes should no more show up. But the code means exactly that.
So a user either needs to configure the cookie postfix in use, or we use the same cookie with multiple values. Value / postfix could be a hash from entity type + id -- or the user can configure it. We first need to define this...
Let's create follow-ups for the things we wanto postpone, and then define the MVP here.
Comment #10
CTaPByK CreditAttribution: CTaPByK commentedSome follow-ups created until we define the MVP here.
Comment #11
CTaPByK CreditAttribution: CTaPByK commentedUse modal behavior for dialog.
Comment #12
CTaPByK CreditAttribution: CTaPByK commentedRebased and test is updated a bit.
Comment #14
CTaPByK CreditAttribution: CTaPByK commentedComment #15
Primsi CreditAttribution: Primsi at MD Systems GmbH for MD Systems GmbH commentedNot sure if we need another field for this. Could we use container?
Additional new line.
Maybe we could have more splas-screen oriented class name? Ie paragraphs-splashscreen-enabled or something along those lines?
Similarly to the other issue, we probably don't want to have this directly in drupalSettings.
We need to implement validateConfigurationForm, otherwise we can enable the plugin without proper configuration: see other plugins.
I think we could use $this->getFieldNameOptions() here
only 'Splash screen'
Url::fromRoute('entity.paragraph.field_ui_fields', [
$paragraphs_type->getEntityTypeId() => $paragraphs_type->id()
]);
Maybe splash_screen_disable?
We went for the american english variant, so it's behavior.
and it's content will be displayed
This could be a bit less technical.
I would move this under the configuration form method
Doesn't this make the summary always appear as disabled?
Maybe I missed something, but to we need link here?
Comment #16
CTaPByK CreditAttribution: CTaPByK commentedFixed. For 15. i think link is needed, see https://www.drupal.org/node/2852384
Comment #18
CTaPByK CreditAttribution: CTaPByK commentedFixes and updates.
Comment #20
CTaPByK CreditAttribution: CTaPByK commentedComment #21
miro_dietikerWhere is this drupalSettings.use_cookie defined?
This still creates ONE global cookie. 5 content items can have 5 completely different splash elements.
If you store that i closed one of those 5, i still need to see the other 4 splash screens!
Also just because one splash screen has cookie usage disabled doesn't mean you should delete the state cookie for other splash screens that are cookie based.
It seems we need a test with multiple splash screens to get this right.
I would be even fine with getting this in without any cookie at all and always opening the splash screen. It's cumbersome, but clear in behavior. But if we introduce cookies, it needs to treat each splash screen as a separate instance.
Comment #22
CTaPByK CreditAttribution: CTaPByK commentedUpdated to use separate cookie for each splash screen.
Comment #23
miro_dietikervalue is a bad variable name here. I think "setting" would be much better.
We put cookie_key if there is no intended cookie use (line before)?
You would need to first check value.use_cookie though.
Is this similarly done in other core areas?
I guess you don't want to expose paragraph ids? The resulting cookie key is very long and this could cause trouble with header limitations.
Is this worth it?
Comment #24
CTaPByK CreditAttribution: CTaPByK commentedComment #25
CTaPByK CreditAttribution: CTaPByK commentedRebased.
Comment #26
Primsi CreditAttribution: Primsi at MD Systems GmbH for MD Systems GmbH commentedJust this one thing more, apart from that looks ok to me.
7 days might be a bit low. I am ok if we hardcode this for now, but let's increase it to 30 days or something similar.
Comment #27
CTaPByK CreditAttribution: CTaPByK commentedIncreased from 7 to 30 days.
Comment #28
miro_dietikerIMHO we should also enable cookie usage by default.
I don't understand the label tor the "disable" setting. It should control if the the paragraph is still present in the DOM when the overlay is closed.
Comment #29
Primsi CreditAttribution: Primsi at MD Systems GmbH for MD Systems GmbH commentedMaybe we should rename this to something like "splash_screen_content"
Yes, let's enable this by default
About the label: this actually disables the pop-up behavior. Do we want the setting to control if the content from the modal is also rendered on the page or not?
Let's also add Drupal.announce when opening the modal. See [#2014521]
Comment #30
CTaPByK CreditAttribution: CTaPByK commentedComment #31
Primsi CreditAttribution: Primsi at MD Systems GmbH for MD Systems GmbH commentedThis needs to be moved to the demo module as per #2864303: Move experimental types and plugins to demo
Comment #32
CTaPByK CreditAttribution: CTaPByK commentedMoved to the demo module.
Comment #34
CTaPByK CreditAttribution: CTaPByK commentedComment #35
Primsi CreditAttribution: Primsi at MD Systems GmbH for MD Systems GmbH commentedHm, this doesn't seem to work any more for me.
About the "If checked splash screen will be disabled and it's content will be removed from the page content." option: having both disabled splash and content removed doesn't make much sense. IMHO a sensible option would be to offer the possibility to show content on the page even if we have splash screen, so effectively hiding it by default.
Another option which would make sense probably is to have an option where the splash screen is disabled which would result in content showing in the page. If this option would be check the above option should be disabled (this could be a follow up maybe).
Comment #36
Primsi CreditAttribution: Primsi at MD Systems GmbH for MD Systems GmbH commented@miro_dietiker reminded me that we will have tristate, so we can scratch the last paragraph from #35
Comment #37
CTaPByK CreditAttribution: CTaPByK commentedComment #38
miro_dietikerIMHO we should not need to choose a field, but promote the container as a whole to the modal.
Since there's no way to enable the plugin per instance, it will always splash. Thus you need tristate to add it conditionally or you need to create an own splash screen Paragraph type.
Missing tests is enable cookie and check persistence of closing the splash screen.
Also testing that the content is still present in DOM after closing (with its setting).
Should be tested with a JS test.
We don't want to have a disabled message.
Comment #39
miro_dietikerThis needs an identifier for custom theming.
Comment #40
miro_dietikerKnown limitation: Maximum one splash Paragraph per page. Should be validated.
There's modal by Boostrap:
https://getbootstrap.com/docs/4.0/components/modal/
And Bootstrap Paragraphs has it implemented:
https://bp.jimbir.ch/paragraph-types/modal
We could simply support bootstrap modal if present and otherwise fallback to jQuery modal.
The modals seem to support a title. We need to support a separate title field.
We need to pass in the modal title here.
And consider title here.