Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/28/2024 in all areas

  1. This week we have a new core version on the dev branch. Relative to the previous dev branch version, the new 3.0.237 version has 33 commits containing 20 issue fixes, 6 feature requests, and more. See the core updates section of ProcessWire Weekly 511, 512, 514 and 515 for more details. It's been about a month and a half since 3.0.236, which is a little longer than usual between version numbers, but that's largely because if the new Invoices site profile (see blog post). I'm off work tomorrow (Friday), so writing the usual weekly post a day early. As always, thanks for reading and I hope you have a great weekend!
    6 points
  2. Yeah that might be more elegant in some situations. Actually you don't even need to put it in a hidden div, you can put it in your markup in a latte comment for example. So those classes will not end up being rendered in your sites markup, but still tailwind will catch them for the final css. I prefer to place markup related things in markup files (*.latte) as for example when working on a "text" block for RockPageBuilder then I want it to contain all necessary markup for that block. So when moving that block into a new project it will still work and I will not have to mess with the tailwind config... But workflows and preferences are different ๐Ÿ™‚
    2 points
  3. Tailwind only adds those classes to the final CSS that it finds in your content files. If you add classes in ckeditor tailwind doesn't know about them and likely will not add them to the final CSS. An easy fix is to add those classes somewhere in your markup (eg on a hidden div) so that tailwind adds it to the CSS and whenever an editor applies the class it will properly render
    2 points
  4. Hello all- FieldtypeFormSelect does what the post title says it does. Lets you create a field to select a form created by the FormBuilder pro module. This type of field (or some variation of it) has probably been done elsewhere but I put this together with a few extra considerations for flexibility and utility. When creating a form select field you can choose what forms will be present and how their names will be shown. Let's go to the pictures: A form select field: Creating fields to choose from specific forms? You have options. You can also create a field that will only include forms that begin, include, or end with a specific string. This allows you to create a field once, then use form names to help group them together and add/remove them from form select elements without editing the field. This is also a pretty simple way to allow end users to create forms that will be selectable without having to ever edit a field configuration. For example, this field will only allow you to choose forms having names enting with "request", so "customer-support-request" and "consultation-request" will be included, but "newsletter-signup" and "call-to-action" won't. You can also choose how the form names will be presented in the select element. They can be shown as they are originally named, as spaced words, or as capitalized/spaced words. So, how does this field work? Form select fields store the ID of the form you select, but it also has a nice trick for working with forms in your markup too. FieldtypeFormSelect makes use of ProcessWire's built-in field rendering to keep things simple. Let's go to the code. <?php $page->select_a_form; // => Outputs the form ID, or null if no form has been selected // You could do this to output your form markup echo $forms->render($page->select_a_form); // Or you can do it this way. If a form has been selected the markup will be output to the page, if no form is selected, the output will be null. echo $page->render('select_a_form'); The fields you create will always be up-to-date with the forms that have been created in FormBuilder. This module also keeps things tidy- if a form is deleted that has been selected in one or more fields, on one or more pages, the values for those fields will be set to null so you won't experience any reference errors to form IDs that no longer exist. My primary use is to have a form select field available for blocks created in the RockPageBuilder module by @bernhard. I wanted each section on the page to contain an option to include a call to action button that can be a link to a page, a link to another URL, or that can open a modal with a call to action form to capture leads and visitor contact information. It's a great way to easily add flexibility and give some extra power to the end user when considering what they want visitors to do when browsing their website. RockPageBuilder is not required, but makes for a useful example! Protip for website designers- in my experience and empirical study of conversion analytics for sites that I've built, buttons located within sections of content on the page captured more leads and outperformed a call-to-action button in the page header, the call-to-action form at the bottom of the page, and forms located on a "Contact Us" page- by far. The true purpose of this field is to get the right forms in the right places quickly and easily without any need to work around markup output strategies or short codes. Contributions on Github are welcome if there's some extra functionality anyone wants to add that makes sense. Please let me know if you run into any bugs as well, when there's some extra usage and testing I'll submit it to the modules directory. Hope you find it useful! https://github.com/SkyLundy/FieldtypeFormSelect
    2 points
  5. New docs about the RockPageBuilder API that makes it easy to import content from old websites and convert it to RockPageBuilder blocks ๐Ÿ˜Ž https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/api/
    2 points
  6. This week there is a new version of the Site Profile Exporter module released (ProcessExportProfile). This is the module that was used to export last week's Invoices Application Site Profile. While this module has been around for a decade now, this latest version makes some nice improvements, which I'll cover below. @bernhard pointed out to me that he's using the module to make a new site profile, but he found it cumbersome to enter all the profile information every time he wanted to export the profile. So this new version now lets you update an existing profile with 1-click, making it much easier to re-export a profile. This version also adds a preview of what your profile will look like in the ProcessWire installer (the part where the user would select it for installation). Lastly, this version has several other small improvements and fixes as well. If you've ever thought of building a site profile, this module now makes it that much easier. This week I've also been starting to focus on the next long term client project, which is kind of a different and unique one that I look forward to. That's in part because I expect it will also involve a lot of improvements to the ProcessWire core and ProFields modules as part of it. Some of my favorite ProcessWire improvements have accompanied projects like this. There just isn't any substitute for real-life, large-scale projects when it comes to improving and optimizing the core and modules. Next week will be a shortened week here, so I'll likely post the usual weekly update Thursday rather than Friday. Thanks for reading and have a great weekend!
    2 points
  7. Have a great weekend and Happy Easter, @ryan.
    1 point
  8. I need the post-url and will update content of this post asap ๐Ÿ™‚ You can signup for Rock Monthly if you don't want to miss the release ๐Ÿ™‚
    1 point
  9. +1 for uptime-kuma. Setup as a docker container is really straightforward. I have it running on a Synology NAS and use Pushover for push notifications to my iPhone. The only downside is getting data out of uptime-kuma. It stores everything in a sqlite db and you have to get that out of your docker container and use some other tool to generate CSVs for example. Possible, of course, but not as easy as the UI of the frontend might suggest. ๐Ÿ˜‰
    1 point
  10. "if ($article->gallery_images)" just works if the field is set to one image only. You have to use "if (count($article->gallery_images))" if you want to check whether one or more images are available. https://processwire.com/docs/fields/images/ -> "How to tell if a page has images present"
    1 point
  11. That sucks, but I'm guessing they might make exceptions for some projects, so I'll have to ask them. Still, not nearly as much of an issue as what CKEditor did. But if it stays GPL and they don't make an exception for any projects, then most likely we couldn't include TinyMCE 7 with the core. In that case, we'd develop it was a non-core module, and folks would have to install it as a 3rd party module (in /site/modules/). ProcessWire's core is completely separate from what people develop or what they might add-on their site, so they don't have to share the same license. PW is built so that modules are independent of ProcessWire in the same way WP and PW are separate applications that can run on the same webserver, or a website is independent of the webserver that's delivering it, or a browser is independent of the HTML it renders or JS it executes. https://processwire.com/about/license/3rd-party-files/
    1 point
  12. Thanks for this โ€“ I've been using FieldtypeForms for years, which was just a gist https://gist.github.com/craigrodway/7515600 there may be another one here: but much appreciated that you have made an official module for this, I use the form select module to allow site editors to select a form to show in a configurable page builder section.
    1 point
ร—
ร—
  • Create New...