Leaderboard
Popular Content
Showing content with the highest reputation on 11/12/2021 in all areas
-
Work has continued on the Page Autosave module this week and several more improvements have been made, compiled into version 2 of the module (now posted in ProDrafts and ProDevTools). The PageAutosave portion has been improved in several ways. For instance, when the page changes elsewhere, autosave disables and displays a message letting the user know about the change. An issue with CKEditor inline fields was also fixed. But the biggest addition to the Page Autosave module was Live Preview. We've got a good discussion going on in last week's post and it helped move things forward with building the live preview feature. It's functional and working well, though it's a start and there's still more to do with it. It's far enough along to begin testing so I've posted it in the ProDevTools and ProDrafts boards. If you don't have access to either of those boards but do to one of the other VIP boards and want to test it out, let me know and I'll add it there too. Since I'm not yet certain whether this module will end up in the core, as a module, or as part of an existing Pro module package, I'm keeping it in the VIP boards at least until it's more production ready. If I find that it adds a lot of value to the core and I can fully support it there, then it'll end up in the core. Here's how the live preview feature works: When live preview is enabled (it is by default), the “View” tab in the top of the page editor supports a live preview option. To see it, hover the “View” tab and it should appear. When you click the live preview link it will open a new window. Drag and size the live preview window so that you can see it at the same time as your page editor, whether side-by-side, above or below, or on another screen. As you make changes in the page editor and they are automatically saved, the live preview window will also update automatically. No development required There is no development required to use live preview, you don't have to insert anything into your template files to start using it. The live preview window updates by re-rendering the page and replacing the entire <body> markup of the page. I found this works well in several places where I tested it and it has the benefit of looking pretty seamless and keeping your scroll position, etc. But it's not going to work everywhere, and it can also lose JS events (though I'm looking into how we can improve that). This might be okay since you are just previewing content and layout, but it's something to keep in mind. If you find the default <body> replacement doesn't work well for your instance, there's a setting in the module configuration where you can tell it to reload/refresh the window for live preview instead. This will pretty much always be reliable, but it also looks like a page refresh, which somewhat reduces the live preview effect. To control and improve performance of live preview There's another option that enables you to have more control over how live preview works while also significantly improving the performance of it. The tradeoff is that you need to add class names in your markup for live preview to recognize and update. When you want live preview to just render and replace the value for the field being edited, you can edit your template file(s) and surround the field value output with a tag having the class name "pw-value-name" where "name" is the name of the field that has its value contained within. This can significantly increase performance as live preview can render and dynamically update just the changed field rather than the entire page. For example, let’s say you had the following markup: <h1><?= $page->title ?></h1> To mark it up for fast live preview, you would add a new class: <h1 class='pw-value-title'><?= $page->title ?></h1> When an update is made to the “title” field in the page editor, live preview will notice the h1.pw-value-title in your markup and it can skip rendering the entire page and instead just render the value of the “title” field for the page, and replace it directly. A few things to note about this: 1. Live preview replaces the “inner HTML” of the element directly with the formatted field value. You should not have any other markup within there, unless it’s part of the field’s formatted value already. 2. The surrounding element (<h1> in the example above) can have any other class names or attributes that you want it to have. Live preview does not replace the tag, only the contents within it. So if you add the pw-value-* class to an existing element that already has other classes or attributes, that’s fine, it's flexible. 3. When you use this option, consider also using it in other places you output the same field value (if there is more than one), otherwise live preview won’t update the ones that aren't identified with the pw-value-* class. So if your $page->title appears elsewhere, like in breadcrumbs (for example) then that breadcrumb instance of the title won’t update, unless it is also marked up with the pw-value-title class. Maybe that is fine for breadcrumbs for it not to update, but it’s just something to be aware of. 4. This pw-value-* option is just for basic text, textarea (including CKEditor) and number fields. Don't use this stuff in repeater, file/image and other more complex fields, as those will always involve generated markup beyond just the field value. For something like a blog post or other article type of page, if you want a 2 minute solution that'll give you the most return, just wrap your $page->body output and call it a day: <div class="pw-value-body"><?= $page->body ?></div> ...that way any changes to your "body" field will update more quickly and without having to re-render the page. What's remaining Like discussed in last week's thread, I'd still like to add support for "pw-field-*" classes. This will be similar to the "pw-value-*" classes, except that it'll enable replacing blocks of generated markup within the element having that class name, rather than just the field value. This'll be useful for people really getting into live preview. But I also kind of think that most people will want to use live preview without having to add anything in their markup, and it works quite well that way too. This is all I worked on this week so no core updates to report (though this may count as core updates if it ends up in the core). Thanks for reading and have a great weekend!
8 points -
Hey @DrQuincy in site/templates/admin.php you could do somthing like this: <?php $wire->addHookAfter('AdminTheme::getExtraMarkup', function(HookEvent $event) { $parts = $event->return; $markup = ''; if((wire('config')->debug) == true) $markup = ' <div class="pw-container uk-container uk-container-expand"> <div class="uk-alert uk-alert-danger">Your in Debug Mode!</> </div>'; $parts['masthead'] .= $markup; $event->return = $parts; });?> Perhaps you could even check the $config->httpHosts if you want to. I hope this'll help you ? Many greets!4 points
-
@wbmnfktr Sounds good, those are the boards you are able to view? I've added it to the first one you mentioned (ProFields board). Thanks.2 points
-
I'd really love to play around with this option to be honest. Therefore if possible... maybe you could add it to ProFields, ProCache, FormBuilder, LoginRegister Pro, Lister Pro, or ProMailer (in my case). Or... maybe add a ProLivePreview Beta for 5 USD to the modules. I'd buy it!2 points
-
Some fieldtypes have 'subfields' (not sure if that's the right term exactly). For example, the "Address" field within the Map Marker fieldtype. Is it possible to use setAndSave() to set some subfield of a field? Seems like it should be possible but I can't work out what the right syntax is.1 point
-
Just a thought, but it would probably be quite easy to make a copy of the Import Batch Users action and amend it to handle duplicate names in whatever way you want. It might be as straightforward as replacing the code that issues the failure message with code to loop through the array of new users and deal with duplicates.1 point
-
Thank you BillH, I was trying it in this moment and it seems to work. The only drawback for me is that I need to provide unique name in the CSV file and it doesn't change automatically for me. Apart from this it works quite well. I am still trying to make ImportCsv module work to see if it is quicker for my use case. Thank you again!1 point
-
You could use the redirects plugin: https://processwire.com/modules/process-redirects/ It also allows to import the redirects as comma separated list, where each line contains one redirect.1 point
-
Forgot to add. I'll leave the form up for about 10 days, just to give everyone a chance to register.1 point
-
Hi all, Added link to the Google Form in the first post. Please let me know if there are any glaring mistakes/ambiguities, thanks ?.1 point
-
I really enjoy those data-driven sites. Nice work!1 point
-
FieldtypeConcat causes the same error, so that will add to the argument for a core fix.
1 point
-
Wow its funny you added this... I created something just a few months ago using CSS to achieve this... wish I'd waited! Mine...
1 point
-
Manged to resolve this by deleting the tag field within the database, May have been something to do with a "Image Extra" field.1 point
-
I've also been struggling with this: Thats because the $page you want to check is the first argument of the HookEvent, so you need to apply it there, not at the first part, which is the class (or object). You can also do this:1 point
-
You could use the API, or the AdminActions module's Page Maniplulator action. Maybe with settings like this:
1 point
