Leaderboard

This site launched earlier this year (2021) and was the product of about 9 months work between myself and the site owners. It was a ground-up build replacing a Wordpress site. Trinnov are based in France and design and manufacturer perhaps the finest cinema processors and room correction hardware in the world. The project features multi-language, product library, a dealer & distributor locator integrated pulling data from the company's BMS, a full featured blog, a site-wide file library for manuals etc. plus a host of other features and customisations including a contact form that emails to different destinations depending on a combination of product application and enquiry type. I hope you like it! https://www.trinnov.com/

welcome to processwire - structure your site is essential for the fun of setup a site best blogpost ever is this one: This one made my first steps a lot faster thanks to @kongondofor this very very helpfull post for beginners...;) kind regards mr-fan

Wouldn't this be the concept of a template, that has the 15+ fields you need. So on your page tree you could end up with something looking like this: - Cards (a page with a template called cards-display-page, without any other field aside from title) -- Card 1 ( a page with a template called card, with the 10+,15+ fields you need) -- Card 2 (another page of type card, ready to be filled) Since you seem to be new to ProcessWire (at least from what I perceive on your posts!), maybe you are not familiar with the idea that a Page can also be just a sort of "data bucket", it doesn't really have to render the page itself. I see that you have solved this issue of your cards with a Repeater, though just wanted to let you know you could potentially do this, and actually behind the curtains, Repeater items are actually regular Page objects! I have used Perch in the past to build a couple sites and I do remember it was very practical to define fields inside the templates.

When working with ProcessWire always think "pages first", there are loads of creative ways to utilize them, they form the bases of the ecosystem. @Robin S and @adrian and others have lots of useful free modules to make it even easier to work with them. Just a few examples, randomly selected: https://processwire.com/talk/topic/25340-dynamic-options/ https://processwire.com/modules/process-page-field-select-creator/ https://processwire.com/modules/admin-page-field-edit-links/ https://processwire.com/talk/topic/24136-lister-selector https://github.com/ryancramerdesign/FieldtypeTextUnique https://processwire.com/modules/fieldtype-events/ https://github.com/kixe/FieldtypeSelectExtOption https://processwire.com/modules/process-admin-actions/ https://github.com/Toutouwai/AdminActionsUnorderedListToPages and more to discover: https://processwire.com/modules/ BTW, welcome to ProcessWire ?

They are, you need to configure that inside the repeater field, on the Details tab where you add the actual fields for the repeater, click on the field's label/name and it will popup a configuration screen that will be set the configuration in the context of the repeater field. (in case you use the fields in other places, for example)

The email notifications for subscribed topics now seem to be truncated when they used to include the full post. @Pete, is it possible to change a setting so that emails are not truncated?

I never used PerchCMS and from what I know and looked up over on their site reminds be a bit of something Functional Fields do in ProcessWire. Yet kind of different but still similar. AND another Pro module. Back to your concerns regarding 400 fields+. 400 fields for just a few cards and donations goals/amounts and such seems not only quite hight it's probably unnecessary as well. I'd bet if you could outline your needs more detailed and maybe even a screenshot of what it would look like in PerchCMS and it's behaviour that the forum might already have a solution for you or at least an idea.

Look at repeaters and Mystique first. And ProFields if you need more.

The UserActivity Pro module in ProDevTools was upgraded this week so that it now uses the Javascript Beacon API, enabling quick and reliable identification of when a user has finished a particular activity. It also now keeps track of when an activity is visible to the user or the window is hidden (like minimized or in a different tab), and it is able to report how many unsaved changes a user has made. All of this is visible from the Access > Activity menu in the admin. On the core side, there have been minor updates, so no version bump this week. But there are still a couple new PRs and useful things to look at in the commit log. The plan for next week: Bernhard Baumrock has been working on a PR that makes it very simple to modify and recompile the CSS of our AdminThemeUikit module... like as simple as placing an admin.less file in /site/templates/ directory. I'll save the details for next week, but after using it a bit here I have to say it's very cool. It also makes it really simple to upgrade the Uikit version. Previously I'd been following the build process as outlined in the Uikit instructions and often found myself in a state of confusion with npm errors and strange dependencies, needing upgrades for unidentifiable tools and producing incoherent warnings that never went away and left me with little confidence in the process. Perhaps it was because I started all this back when Uikit 3 was still beta, but the result was that I didn't much like upgrading Uikit or recompiling our AdminThemeUikit CSS, and I don't think anyone else did either. It made it a little difficult for our AdminThemeUikit module to achieve its original mission of being a simple module that many would extend and build from. Well, Bernhard has found a way to skip over all that nonsense and made it much simpler for all of us, so that AdminThemeUikit can finally be what it set out to be. I look forward to integrating this PR hopefully this coming week and think it means a lot of good things for our admin. Also, huge thanks to Pete for upgrading our forums this week! It's a great upgrade.

I would question why you are going down the road of a Process module rather than the standard way of entering and storing data in PW, which is via pages and the Page Edit interface. I expect you will want to store the data that your users are entering, and the simplest way to do that is in pages. And when it comes to providing edit forms for that data Page Edit is going to have a lot of advantages: You probably already understand how fields are added to templates and how fields are presented in Page Edit, so there's less to learn. You can add/sort/arrange fields via the admin GUI rather than in code. You get access control for editing out-of-the-box. You can use the full range of PW fieldtypes and inputfields, many of which wouldn't be usable within a Process module (Repeater, ProFields Table, etc). Is there something in particular you are wanting to do that you don't think would be possible via pages and Page Edit?

I ran across a reference to IftRunner module. The post was 6 years ago. I cant find it in available modules. Has it been pulled?

Thanks for the additional links! I bookmarked them all and will review them when I have a chance.

You can use a hook to AccessByQueryString::replacementMarkup (see the readme for more info) and do a redirect inside your hook, e.g. $event->wire()->session->redirect('/your-login-page/'); I imagine that these pages are subject to view restrictions by role, i.e. you have to be logged in with a particular role to view those pages. The AccessByQueryString module isn't going to override any existing view restrictions you already have in place - it's only going to add additional restrictions. So if you have existing restrictions like that then you'll have to log your users in somehow ($session->forceLogin ?) but then if you're doing that you don't need AccessByQueryString to restrict/grant view access. So probably this module isn't going to suit your use case.

Info: https://processwire.com/blog/posts/introducing-iftrunner-and-the-story-behind-it/ GitHub repo: https://github.com/ryancramerdesign/IftRunner I don't know if it was ever available via the PW modules directory.

Wbmnfktr, I no longer use Perch so screenshots aren't possible. It's a paid CMS, and I'm currently doing work for organizations that can't afford it (NPOs). Plus their support was horrible so I decided to find a better option, which is when I found ProcessWire. I briefly looked at the Functional Fields page you linked to and it is very similar to how Perch works. I haven't used Perch for several years though so I'm not sure if I could do the same things in Processwire or not. The suggestion elabx made, to use whole pages as the cards and then just bring that info into the page I need, is an great option as well. I never even considered using pages like that (as "data buckets") but will try that method soon and see if I can configure it to meet my needs. It would definitely be more user-friendly to do it that way as I could configure the field widths to be less than 100% (which they're not configurable in the Repeater module). Thanks to both of you for the excellent extra ideas!

Another like for the CKEditor plugin custom folder change! Regarding the download page of the website: I suspect this may have been mentioned before, but the displayed version still appears to be stuck on 3.0.174, when we are actually on version 3.0.178.

Cool! This thing that you and @bernhard are working on is something many of us are waiting. And it is in line with the plans we've been discussing in the beginning of the year. Great to see them become reality. Another nice thing I spotted looking through the commit log is the ability to define a custom folder for Creditor plugins. In fact there are a lot of things worth mentioning in this log recently, that does not make it to the blog posts or these announcements. In some of his weekly issues @teppo goes through the github commits in detail. I personally really enjoy it.

I used PDFLayer (https://pdflayer.com/) recently in a project, and it did a good job of rendering some quite complex CSS. It's free to sign up for an api and you get 100 api calls/month with the free version. It could get expensive though if you have a lot of API calls to make (e.g. $9.99/month for 1000 api calls, $39.99 for 10,000). It was quite straightforward to use though, and you can set it to "test" mode for development, where it will overlay "Sample" on the PDF output, but not use any of your API requests.

I agree with your problem assessment and know the repeater.field construction from several front end searches/selectors. It’s probably a limit of dragging and dropping fields instead of setting up selectors manually. As fields inside a repeater stay ordinary fields with sort of a virtual framework around them, the field select lists only the basic fields without any knowledge of their repeater context. (If I remember it correctly, there is a similar limitation at FormBuilder’s drag & drop field mapping.) Your first solution proposal sounds very interesting, though I’ve never even recognized the existence of the field type Cache before. So I did what you suggested and got pretty excited, but only until I tried to include my astonishing new Cache field to the search list: it’s not offered as an option. Obviously the select is restricted to text and textarea fields with no exception. As long as I don’t find anything better, I will solve it with your proposal #2. It might not be the most elegant thing on earth, but definitely a sturdy workaround and therefore a very good idea. Thanks a lot for it!

Just in addition... this is what I use for similar tasks. <?php // Page sub-select - find pages based on previous selected pages // example: find all brand based on products // https://processwire.com/talk/topic/3553-handling-categories-on-a-product-catalogue/?do=findComment&comment=37833 // https://github.com/webmanufaktur/processwire-snippets/blob/master/api/api-page-subselect.php // define array for brands $brands = new PageArray(); foreach($pages->find("template=productTemplate") as $product) { // add brand from product page to brands array $brands->add($product->brandField); };

Hi John W., hoping not to misunderstand your data structure: I'm sure that the Drs. are not in the Gifts businesss, and Mary's Flower shop ist not involved in physicians' tasks. So the hierarchy of your categories should be just like your wanted output (see the attached image). Then the individuals (Dr. Adams, Dr. Smith, Mary's Flower Shop) need only to have a reference field to the Secondary Categories - not to the Primary Categories. (Since Mental Health is a subcategory of Physicians, Dr. Smith automatically is categorized as Physician...)

Very interesting thread! I've had a couple people pretty amazed too by the volume PW can handle but this case is really interesting!

I've just recoded a brief video where I've tried to explain how to install tailwind inside Processwire ( really badly spoken ? , so be kind...) Moreover I've updated the gist here to reflect the changes I've made since the last time I've written the guide above. There you have it:

@fruid I agree with you that at first it looks complicated, mainly because it need a compilation step which has to be handled in some way. Nowadays is quite common to rely on tools like webpack, rollup, parcel, vite, etc.. to handle some activities like compilation, minification, bundling, etc. Postcss is mainly just one of them, but specifically intended to work with with css. Once you grasp the few key steps to install it and how to purge your css efficiently I guarantee you will see the benefits at your disposal (mainly speed of layout blocking and very low css file sizes). If someone it's interested I can make a video where I can explain all the install steps in further details.

My journey with CSS frameworks has been: Bootstrap v2 → Zurb Foundation → Bootstrap 3 → UIkit 2 → Uikit 3. This is over the course of 9 years, with plain CSS for several years before that. All of the frameworks I mentioned come with pre-define components along with the JavaScript to do the usual things like accordions, tabs, modals, etc. I really fell in love with UIkit 3 because it goes very deep with JS components, giving you things like filters, lazy loading and slideshow. With Bootstrap, you have to use 3rd party libraries to get the same level of functionality, which in the past has lead to breaking packages for whatever reason, compatibility issues and a lack of cohesiveness. Maybe my workflow these days would alleviate some of those issues, but the fact remains UIkit solves like 95% of my use cases. I completely see the appeal of Tailwind having done CSS for a long time, but the lack of an official set of JS components is holding me back from giving it a try. I'm still waiting to see how UIkit 4 turns out and see how much further they go with utilities. Or I just may sit down and write a set of UIkit classes using Tailwind @apply that uikit.js expects so components looks correct (has anyone done this?). But, that feels a little hacky.

Memorizing classes will always be needed. If you take a pre-build framework or your own classes. The big productivity improvement is not in writing CSS using @apply and tailwind classes, but in writing just html and adding tailwind classes directly to the markup. So you need the backing css to already exist. Once you have to switch to a css file you're already loosing on the productivity gains. If you're using properly separated templates there might even be no need to later move the utilities to custom classes and `@apply` as everything's already in one place - the template of a component. Having the utilities out of the box is exactly the selling point of tailwind. Sass/less don't give you classes you can put in your markup - they're pre-processors. It also doesn't want to be a contender to e.g. uikit or bootstrap because they require so much work to be bent to custom design. Building your own components is expected, as custom design most often does require that anyways. There's however some work on a component library being done, which is build on top of tailwinds utility classes; and which will probably be easier to customize than e.g. bootstrap. If you have your own custom utilities library tailwind probably won't be of much benefit. If not however it' a great way to get started quickly on a existing, well documented, well adopted framework. Tailwind by default comes with 9 shades of each color, where afaik 4 are accessable colors on black and 5 are accessable on white background. And you can still edit them, those are just defaults. The message is not "you should not use more than (those) x colors/shades". The message is that a well managed design system must use a fixed set of colors, which is different to each person on the team just adding a new shade each and every time they add something to their codebase. The latter most often being the reason for the exploding number in color or text-size variations. It's about consistency and less about absolute numbers. Imho the need for all those customization variables of frameworks like uikit/bootstrap and the lock-in to a certain preprocessor already show how "inflexible" those solutions really are. I've not yet used any of those frameworks, where I didn't hit a brick wall at some point trying to skin a component to a custom design, because some aspect of a component wasn't customizable (either markup expectations or missing a "configuration variable"). To me tailwind css is neither an alternative to writing css, as the building blocks are way more cohesive and well rounded as well as "higher level" than css 1 – but also not for frameworks, which often impose quite an amount of markup constraints and understandably a certain kind of style, which can be problematic when implementing a custom design. [1] Take for example .truncate. There's no single css rule for truncating text properly. It's overflow: hidden; text-overflow: ellipsis; white-space: nowrap Same for e.g. .rounded-t. It applied rounded borders to both top edges, instead of css, which requires you to set it for each edge explicitly. This is more in line in how a designer would think about a design than how css needs it to be implemented. Nobody will say "make the top left and top right edge rounded". People say "make the top edges round" or "truncate that line".

Tailwind is utility-first framework. The key difference between something like Uikit and Tailwind is that latter has none of the typical CSS framework components built-in. For an example, here's an example from the docs for creating a "button component": <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"> Button </button> Colors and sizes (such as the "2" in "py-2" etc.) are configurable, so you can have as many or as few of them as you want, and the names can pretty much be whatever you want them to be (py-thon). Either way you're always building your UI using really simple (the word "atomic" comes to mind) rules. While Uikit has some similar utility classes (and so does Bootstrap), Tailwind has a massive number of them, even without counting the pseudo states (bg-blue hover:bg-blue-dark), responsive classes (p-6 md:p-8 lg:p-10), etc. You can still create your own "custom" components, so that when you add some class – such as "btn" – to an element, you actually get the same thing you would with the rules in the example above. Typically this is done by defining the class in SCSS: .btn { @apply font-bold py-2 px-4 rounded bg-blue-500 text-white; } .btn:hover { @apply bg-blue-700; } Technically that this is something you should only do if you really have to repeat the same string of classes multiple times, though ? Personally one thing I've always struggled with "traditional" CSS frameworks are the components they come with. While they often look quite nice, I've almost never had the chance to actually use them as-is (either there's a predefined PSD layout or something like that, or the client demands changes, or the component is just plain bad) and thus I've basically ended up designing my own component library on top of the one provided by the framework. In most of my projects I've only used a framework like Foundation for the grid implementation. That's where Tailwind comes in: you can build exactly the components you need, BUT you still get certain benefits of a framework, such as globally defined fonts, colours, spacings, etc. I've struggled with this a bit, and I have to agree that to me personally the utility class approach often looks really ugly, and the shortcut class names etc. are hard to decipher. I'm not yet at the point where I can just glance over an element and instantly see what it is or how it's styled. That being said, I don't really think that this is a major issue for most projects: the size of your HTML is unlikely to become a real bottleneck. ... and if it does, you can always use the extracting components approach mentioned above. Use Tailwind for prototyping, and then convert the combinations you use often to custom components (or custom utility classes) ?

Just to add to this a bit: I've found it a bit problematic if you're, for an example, working with nested structures where the nesting level should affect things. That's one example where, to my best knowledge so far, it's usually easier to rely on custom classes. You can still make use of @apply and similar features behind the scenes to make use of Tailwind's features as much as possible, but the point is that you can't always rely on directly applied Tailwind classes alone – at least not without creating solutions that are either inflexible, or unnecessarily complex ? As a disclaimer I'm currently building my first site with Tailwind. It's been a bit of an emotional rollercoaster: at times I find Tailwind utterly awesome, while the very next moment I can be really frustrated with it as I'm once again struggling to figure out what's the Tailwind version of some CSS rule I already have in mind. (For the record, https://nerdcave.com/tailwind-cheat-sheet has been a big help in this regard.) I've been constantly tweaking my approach, going back and forth with things like components and custom utility classes, trying to figure out how to best combine those with native Tailwind features, when to add a new "spacing" or color (or something similar) to Tailwind's config vs. just applying a one-off custom value instead, etc. That being said, I've already got a list of do's and don'ts for my next Tailwind project, so it should go a lot smoother. For the past year or so I've been deeply invested in a BEM type approach, and in some ways Tailwind is the opposite of that. That shift in mental models has definitely been holding me back a bit. After my next project with Tailwind I hope to have a more informed opinion, but currently if someone asked me if they should use Tailwind for their next project, I'd have to reply with "it's complicated" ?

Recently I've met the same issue at 2.6.4. Looks like a super-critical bug as it compromises PW consistency... If anybody knows - please share how to fix this. Finding&moving pages to/from is not a solution for db with over 100000 pages... I guess, some kind of repair script should be available. Thanks.

Well said Ryan. I think that simplicity is also the main reason why I felt home right away when I tried pw for the first time. I think that there is few "simplifications" which really makes pw joy to work with: a) Urls come from pages: and you cannot break that (but you can easily fetch data from other pages) b) All markup comes from template: no system generated content (try removing jQuery from drupal site...) c) Everything are just pages. Of course there is lot's of other stuff that makes pw so good: it has great API, it's polished, well documented, easy-to-use, modular, oo, easy to extend... but probably most of these aspects come from the fact, that there are these simplifications behind, so there is not so much to polish, document and create UI:s. About terminology: only thing to consider, is that it is easy to mix template (as a content type, managed through admin) and template file (php file that generates the site markup). I always stumble when I am telling people who are new to pw how this stuff works: "you first create the template and define the fields. Then you edit that template file and add the markup you want." (That is confusing, template is file, or template is content type?)