Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/02/2025 in Posts

  1. AgeWire is a powerful, fully customizable age verification module for ProcessWire, built with modern web standards and powered by Tailwind CSS. Perfect for sites requiring age gates (alcohol, tobacco, adult content, etc.). Key Features Two Verification Modes: Simple Yes/No buttons Date Picker with separate MM/DD/YYYY inputs (bot-resistant) 13 Stunning Themes: Modern, Dark, Classic, Minimal, Gradient, Neon, Elegant, Corporate, Vibrant, Nature, Sunset, Ocean, Purple 4 Smooth Animations: Fade In, Slide Up, Zoom In, Bounce In International Date Formats: MM/DD/YYYY (US) DD/MM/YYYY (EU) YYYY/MM/DD (ISO) Advanced Security: Secure, HttpOnly, SameSite cookies Configurable lifetime (1 day to 6 months) Bot protection via manual date entry Smart Exclusions: Skip verification on specific templates or pages Admin pages auto-excluded Privacy & Compliance: Optional Terms & Privacy Policy checkbox Custom links to your legal pages Fully Responsive – Mobile-first design Custom CSS support Tailwind CDN integration (no build required) Installation Download from GitHub Place AgeWire folder in /site/modules/ Go to Modules > Refresh Install AgeWire GitHub: https://github.com/mxmsmnv/AgeWire Download: https://github.com/mxmsmnv/AgeWire/archive/refs/tags/v1.0.9.zip Perfect for: Wineries & breweries Vape & tobacco shops Adult content sites Age-restricted events Feedback, bug reports, and pull requests are welcome! If you like AgeWire, please ⭐ star it on GitHub! Made with ❤️ for the ProcessWire community.
    6 points
  2. This week on the core dev branch there are several new hookable methods added to the Page class. While many of them may be redundant with hooks already available on the Pages class, those on the Page class are more convenient to use in some cases, especially when it comes to using custom Page classes. It's helpful because you can hook CustomPageClass::method rather than Page::method to more easily target specific types of pages. Or you can override the methods in a custom page class, without having to hook them at all. I'll get into this with more details and examples in a future blog post that goes in-depth on using custom page classes. Here's a summary of the methods that were added with links to their API reference documentation pages: Page::addReady() Page::added() Page::addStatusReady() Page::addedStatus() Page::removeStatusReady() Page::removedStatus() Page::cloneReady() Page::cloned() Page::deleteReady() Page::deleted() Page::editReady() Page::moveReady() Page::moved() Page::renameReady() Page::renamed() Page::saveReady() Page::saved() Page::renderPage() The above is just for this week, but there's quite a bit more in 3.0.253 relative to 3.0.252, so be sure to check the last issues from ProcessWire Weekly for more details.
    5 points
  3. Hello again! The new AppApi release v1.4.0 is live now! Changes in 1.4.0 (2025-11-01) Add compatibility for ProcessWire instances installed in a subdirectory (Thank you @saerus for mentioning this issue) Add helper functions that can manipulate subdirectory links. -> Can be very handy for using ProcessWire as a headless CMS for your JavaScript applications (See FAQ for more information) Add config param to disable automatic adding access control headers (Thank you @gerritvanaaken for the ticket) Fix an issue where adding trailing slashes automatically lead to problems with route parameters (Thank you @gingebaker for the ticket) Thank you all for using AppApi, leaving feedback and for posting Github Issues and PRs. Thanks to you, the module keeps getting better and better.
    3 points
  4. Always wanted those on Page. Even before custom classes existed. Great addition! I think that custom classes truly need more introduction and use cases. So eagerly waiting for Ryan's upcoming blog post.
    2 points
  5. That will definitely be welcome, for sure! Thanks in advance.
    2 points
  6. Although I never thought of this use-case, it should be possible as the module uses (IIRC) the MySQL Time type which does have fractional second support.
    1 point
  7. Thank you very much for your detailed answers @jploch, I really appreciate it. In fact, it concerns more PW topics, such as how these are seen and used for page grid. I thought that site profiles and page grid interact with each other, but I wasn't sure, hence my question, including the one about pro cache. When you come from other CMS systems, it's always a matter of ruling out multiple interferences. Thank you for your explanation on the homepage about how I can configure this.
    1 point
  8. Hi ausblick, I'm happy to answer your questions. Basically, these are topics that for the most part don't specifically concern PAGEGRID, but rather ProcessWire in general. In ProcessWire, site profiles are essentially preconfigured starting points for a new site. They define the structure, templates, fields, and sometimes demo content that get installed when you first set up ProcessWire. Unlike themes in WordPress, which can be changed later, site profiles are installed together with ProcessWire when you first setup the site and can't be changed later. PAGEGRID supports the creation of site profiles, and there are currently two smaller PAGEGRID profiles that can be installed (click the thumbnail to see the frontend). However, these are currently only available in PAGEGRID Cloud. If you want to try them quickly, you can create a free cloud account. Cloud sites can then also be exported as a site profile (with a self-hosting license). But I can also upload them here as ZIP archives if you prefere. For my projects I usually don't use site profiles. Since PAGEGRID allows you to install pre-built blocks (which create all the templates and fields for you), it's already a good starting point for a new website. All you have to do is add the blocks you want to your page and design them using the style panel (visually) or with CSS code. Since my websites usually look very different from each other, I prefer blocks that are largely unstyled by default. Yes. Procache works with PAGEGRID. But it is not really needed since PAGEGRID is already using markup cache for all it's output. If you build a site that is mostly rendered through PAGEGRID it will be very fast out of the box, without any additional customisation. E.g. page-grid.com which is build with PAGEGRID has a performance score of 100 (best score) in Google lighthouse speed test and is not using any additional caching. First you have to add a PAGEGRID field to your home template inside the admin. Then open the file home.php inside your site/templates folder and add the following lines: <div id="content"> <?= $pagegrid->styles($page); ?> <?= $pagegrid->renderGrid($page); ?> <?= $pagegrid->scripts($page); ?> </div> Note in this example I am using the blank site profile and markup regions are enabled. The #content div in this file will replace the #content div in _main.php See the Markup Regions documentation for more information.
    1 point
  9. @ryan, You'd mentioned at some point that existing installs could retain the old theme and perhaps users prompted to update to the new one. At the moment if I upgrade an existing site to the dev branch, the new theme is enabled by default. This breaks any custom TinyMCE styling as the new theme overrides it. Are you planning to implement this prior to the next master version? Ideally for us, given we have several hundred sites which we update to the latest master when it is available, nothing would change for the users. We could then turn on recommending a theme upgrade on a per site basis, or if we choose to, force the upgrade on the users. Cheers, Chris
    1 point
  10. Hi, I am working for a small-to-medium business and we have hundreds of websites out there and with a considerable percentage of those, we have a service contract set up. We're coming from WordPress and we did the switch to PW in 2021. So, still today, the majority of our long-running service contracts are about WordPress sites, trending down fast though. We're offering our clients a few things in our service contracts: Basic guarantee that their website will run and continue to run in an ever-changing environment of servers and technologies. A predefined amount of free hours to work on the website, which even includes minor design changes, adjustments and even small new features. Bigger undertakings require a new project contract though. Reduced hourly rates for work on the website if the hours go over the amount predefined in 2, using the same conditions as in 2. I have to say though that we have a LOT of clients who simply DO NOT WANT to edit their own site but have us do it for them. That's why for them, especially the second and third point above is a big plus and is also the main reason we're designing our service contracts like this. For WordPress sites, point 1 consists of updates, backups and health checks which we do in regular intervals spread out across the whole year. For ProcessWire, it's just backups and health checks and thus on average lower predefined hours in 2.
    1 point
  11. The new ProcessWire theme seems have lost the darkened backgorund of the fieldsets? Is this intentional? vs:
    1 point
  12. Hey @ryan @diogo @jploch thx for your work on this! I have some questions: 1) UIkit notifications seem to not use the theme's styling: 1.b) Is there a reason why primary buttons are black and not in the primary color? 2) Could you please add an option to make the button's border radius customisable? 3) Could you please add an option to make all input's border radius customisable? Ideally both would use the same setting by default but could be also set differently. This was one of the changes proposed by @Chris-PW when we were working on a new admin style and I think it makes sense to have everything that can take user input (<input> <textarea> <button> etc) have some rounded borders. We already have lots of lots of lines in the admin to help with grouping content, wrapping inputfields etc. and all those lines add up. Having all clickable elements look slightly different from everything else (but identical on their own) helps a lot in my opinion. 4) Is there a reason why <select>s have white background and regular inputs have a light grey? 5) Is there an option to disable the new toggles and get back to good old checkboxes? See https://axesslab.com/toggles-suck/ Even if one prefered toggles over checkboxes in general, I think there are some situations where they are absolutely counterproductive, for example here: 6) I tried do add the file site/templates/admin.css with the following content: :root { --border-color: var(--main-background); /* --inputs-background: var(--blocks-background); */ } I then put both "site/templates/admin.css" and "/site/templates/admin.css" in the AdminThemeUikit config for "Custom CSS File", but it had no effect. Strangely when I put "wire/modules/AdminTheme/AdminThemeUikit/themes/default/examples/borderless.css" it worked! I also tried with this content: div { border: 1px solid red; } Still no luck. 7) Would it be possible to have the admin theme load one CSS file by default. Similar to what we know from /site/ready.php it is often so much nicer to just place a file in a predefined location than to have to update a module's config somewhere. This might not sound like a lot to do, but when working with migrations and automated deployment workflows these things get more tedious, because you can't simply change the module config, you have to migrate these changes and then commit them. Also a predefined location reduces the risk of typos, of missing leading slashes, etc. 8 ) Where to report bugs/issues/requests? In the PW issues repo? Here in this thread? Somewhere else? 9) When editing a page in a modal (just add &modal=1 to any page edit form) there is a lot of unused space at the top: 10) On the page tree I think it is ok to have the action items text-only in this case (though I'd probably prefer the old style here): But on the trash we have some text followed by the action buttons and there this text-only style is really not good imho: 11) +1 for this: I'm using #0a2b99 for the primary color and links are near to not readable in dark mode: 12) @ryan As you can see in the screenshot above when using dark mode I'd probably want to change the logo to a white version. If that image were an <svg> this would be quite easy to do with CSS, but at the moment it is using <img src='...'> Could you probably update the theme to make it inject SVG markup for the logo directly? 13) Regular UIkit <div class='uk-alert'> are not styled properly (they use the default uikit blueish), which is even worse in dark mode: Thx!
    1 point
×
×
  • Create New...