Leaderboard

You're right. The problem is on my side. I have another hook Errormessage::render to add the font awesome icon on the errors. Problem solved.

No, this could not be a reason, because you are also using these lines of code to manipulate the classes: $checkbox->getFieldWrapper()->setAttributes(['data-uk-grid', 'class' => 'uk-grid-small']); $checkbox->getLabel()->wrap()->setAttribute('class', 'uk-width-expand'); This methods are working in the same way as the getErrorMessage() method. I cannot tell you, why getFieldWrapper() and getLabel() works, but getErrorMessage() not. As written before, in my case everything works as expected. If you cannot find the cause, please use the hook method to get your desired result.

Take a look at the form field class file (https://github.com/juergenweb/FrontendForms/blob/main/Formelements/Inputelements/Inputfields.php). There you can see that an inputfield consists of various parts (wrappers, label, error message, success message, description, notes,..) Every element can be grabed an manipulated via a get....() function getLabel() getErrorMessage() getSuccessMessage() getDescription() getNotes() getInputWrapper() getFieldWrapper() Maybe this is not well documented inside the docs, but now you know it 😉

Hello @PWaddict Instead of using a Hook for adding the grid class to the error message, you can also use the following: $checkbox->getErrorMessage()->setAttribute('class', 'uk-width-1-1'); Best regards

Thank you @Juergen Here is the final code in case anyone wants to use the grid (UIkit) on a checkbox: $checkbox = new \FrontendForms\InputCheckbox('checkbox'); $checkbox->setLabel('My Checkbox Label'); $checkbox->setRule('required')->setCustomMessage('My custom required text'); $checkbox->getErrorMessage()->setAttribute('class','uk-width-1-1'); // Add uk-width-1-1 to prevent the text displayed as part of the grid $checkbox->getFieldWrapper()->setAttributes(['data-uk-grid', 'class' => 'uk-grid-small']); $checkbox->prepend('<div class="uk-width-auto">'); $checkbox->append('</div>'); $checkbox->getLabel()->wrap()->setAttribute('class', 'uk-width-expand'); $form->add($checkbox);

Laws and business cases aside, my points were more along the lines of: hey, with a smidgen of awareness we can make nice things that more people can enjoy using. Sure, at the extreme end it can be an enormous task that requires awareness, commitment, funding, expertise, focus groups etc. etc., but let's not make perfection the enemy of progress. On colour contrasts, I have good eyes (fading as I'm middle-aged, but 20:20 vision with glasses) and am not colourblind. I'm part of the 80% majority in the UK who does not have a long term disability. I can afford and have chosen to spend cash on high quality screens. I love photography and art and attention to subtleties in colour. I still struggle with small, low contrast texts but at a squint I can read them, it's just not pleasant. I make websites for a living, so sometimes I just hit F12 and change the CSS, and for some sites I use a browser plugin to always add my own CSS. So even with all my privilege, this isn't a great experience. Many people don't have great eyes or expensive monitors or tech skills to edit CSS and will literally not be able to read such texts and there's just no need for this. The WCAG standards provide guidance on colour contrasts and this is a big easy win. Meeting the AA standard on colour is such a low level requirement that most browsers have dev tool support for this built in and have had for years. Screenshot of Firefox's dev tools showing a node from this site; I've clicked on the CSS "color" rule and it shows a colour picker that includes a contrast ratio calculation: 4.02 with a red exclamation mark and a tooltip reading: "Does not meet WCAG standards for accessible text." Chromium-based browser screenshot of devtools: again, the CSS panel is shown and I clicked a colour and the colour picker has the contrast ratio calculated, 4.01, and text: AA: 4.5 with a red symbol meaning No-pass (this is telling you that 4.01 < 4.5), and AAA: 7.0, not passing. Lines on the chart show the colours that would be accessible against the two standards. Re: keyboard accessibility: For a while I developed RSI which meant I could not use a mouse without significant pain. This was obviously very frightening for me given how I make my living. At this time I really learnt the value of keyboard accessible interfaces - they literally made it much less painful for me to operate a site (admin or front end). And disability aside, being a [neo]Vim user too means I know that it's often just a lot more efficient to use the keyboard instead of having to reach for a mouse, so these are my reasons for suggesting this. Thanks for being open and interested in these accessibility suggestions @ryan I think upping contrast to 4.5 (AA) would be a great first step to making ProcessWire something a lot more people could enjoy using and as others have pointed out, making an admin system that also supports 3rd party modules to make it more accessible, e.g. through use of CSS variables, also makes ProcessWire a good framework for people wanting or needing[1] to make sites more widely accessible. [1]: 86% of people implementing accessibility standards do it because they feel it's the right thing to do. 8% do it for compliance reasons, 4.5% do it for business advantage, 1.1% do it for legal reasons: https://webaim.org/projects/practitionersurvey3/

Hello @PWaddict You are absolutely right - the position change will not taken into account. I have fixed this now. Please replace the following file: https://github.com/juergenweb/FrontendForms/blob/main/Formelements/Inputelements/Inputfields.php After that the position change should work, but please give me a feedback if everything works now as expected. After that I will bump up the version of FrontendForms. To get the desired markup, you have to do something like this: $form = new \FrontendForms\Form('inputfieldtest'); $form->setMinTime(0); $form->setMaxTime(0); $form->setMaxAttempts(0); $form->setErrorMsg('Ouups! There are some errors.'); $form->setSuccessMsg('Congratulation! There are no errors.'); $form->appendLabelOnCheckboxes(true); // set it here to true or in the backend config // add checkbox $checkbox = new \FrontendForms\InputCheckbox("checkbox"); $checkbox->setLabel("Checkbox Label"); $checkbox->getFieldWrapper()->setAttribute('class', 'uk-grid-small'); $checkbox->prepend('<div class="uk-width-auto">'); // add div before the input $checkbox->append('</div>'); // add closing div after the input $checkbox->getLabel()->removeAttribute('class')->wrap()->setAttribute('class', 'uk-width-expand'); // wrap the label element $form->add($checkbox); $button = new \FrontendForms\Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if($form->isValid()){ print_r($form->getValues()); // do what you want } // render the form echo $form->render(); Take a look at the checkbox element. I have done some manipulations to add some classes and extra divs. I guess you are using the UIKit markup and if so, I think you also have to add the data-uk-grid attribute to the form if you are using grids (but not sure). I think you can image how it could be done to get the desired markup at all. If you have problems, please post the complete code for the form . Best regards

I'm a bit short in time right now so I might have to write a follow-up to give you a real and more complete answer here. But in the meantime - a short summary: each and every client/side project of mine get's a click-dummy of the final product to see how it could work out, what's needed and so on. I use Astro JS for that as it's super flexible to work with, I can deploy it somewhere at Netlify, Vercel, or Cloudflare. Each commit is a new build. I can share it with everyone - frontend and backend-wise. It's more or less just HTML, CSS, JS - some parts of it might have a TailwindCSS or AlpineJS flavor but still super basic. And the big plus: ALL build steps (TailwindCSS, AlpineJS, ...) are already in place. If needed I can connect it to an API to fetch articles, news, or whatever kind of data to make it look more real or to go super fast - especially when migrating from WordPress where there is a RestAPI or GraphQL almost always in place already. For sideprojects I connect to api.domain.tld, grab JSON and render out either pages or just parts of the project on-build. for side projects in very early stages that would be the state for the next 3 to 6 months to see if the project get's some kind of traffic - for client projects this is the base to start the real work. from there I take all the component and move them from .astro to .twig - the difference is so minimal I could use Regex to make the changes most of the time. feeding all layouts, components, partials, blocks, however we want to call those code snippets into ProcessWire is pretty easy, when you know where things have to go and most of the time you only change the parts that define the source - so from a JS fetch() to a $pages->find('...') - and of course you have to build out the ProcessWire backend stuff, hooks, automation, and whatever you need or want. Some would say there are a lot of unnecessary steps in this process and they could be right, but I prefer to test projects early on and hate to look at Figma files or Illustrator screenshots. So there is that. I always worked that way and that will probably never change. On the technical site you have think about 2 systems running side by side. Astro JS on Netlify, Vercel, Cloudflare or a VPS with NodeJS and ... lots of other stuff ProcessWire with database and everything it needs on a sub-domain. You could fit everything onto one server but it can be quite painful to get this up and running so I use a regular hosting provider for ProcessWire and one of those mentioned above for Astro JS. The output is, most of the time, 100% static and build on-demand with data and content available at that moment. You could make it more dynamic with AlpineJS or HTMX but only for small parts, and not for articles and news - as those wouldn't exist within the static build. As this turned out to be broader as expected please feel free to ask about more details where needed.

@elabx There are several methods to use Vite or Alternatives with ProcessWire. @wbmnfktr's suggestion is one of them. You can make certain checks in your vite.config.js file and implement this within your config file as well. You can send extra parameters and check these parameters in your config file to perform operations accordingly, for example: npm run build --my-parameter=tinymce. You can also use Dotenv and create multiple environment files like .env-tinymce, .env-frontend, .env-another-style, and then pass a parameter to your build script: npm run build --env=tinymce. After that, you can do what you want inside your vite.config.js file. When you install this module you will have simple vite setup under site/templates directory. There is an .env file, we use this file for live reloading.example .env file also you can use it for your needs.

"Low contrast, but not too low contrast" is one solution, while sometimes it may make sense to try to figure out an alternative approach entirely; e.g. instead of making something hard to see / low contrast you might consider hiding it behind a toggle, etc. (Perhaps not the best example, but that's the first thing that came to mind.) Overall this is an interesting point because I definitely get what you're saying, but at the same time being able to read text is a pretty big deal in terms of accessibility. And it's also one that can be considered a low hanging fruit: identifying contrast issues is easy, and it's usually an easy fix. As a general rule of thumb if a piece of text is worth being there, it should probably be visible to all users, and that means it should have enough contrast 🙂 If you'd like to get a better grasp of these things, I would recommend checking out browser extensions such as WAVE Evaluation Tool, or Accessibility Insights from Microsoft. Both have automatic tests that are super easy to use; while they may raise some false positives and may not catch all issues, they will point you to the right direction.

Like last week, I’m still working on all the same things: PW site, client stuff here and there, and even the HVAC stuff. They replaced our heating/air systems on Wednesday, but not everything is working quite as it should, but that’s another story that's still ongoing. A couple weeks ago folks were asking about CSS variables/properties for the new AdminThemeUikit look. I’m not that familiar with that part of CSS yet, but luckily the people coming up with this design are. And it turns out they are indeed using CSS variables/properties for this. I think this means you’ll be able to override them with your own colors, perhaps in the AdminThemeUikit module settings, or with a CSS file, I’m not yet sure, but will find out more in the next week. I’ve seen a few different color schemes specified using it, and they are really nice. Thanks for reading and enjoy the weekend!

Thanks for posting this, I was about to as something similar. I'm not sure the “Unique” status is a good fix to what I'm after doing. It looks like a hook per @Robin S‘s code would do the job nicely. I love PW. One thing I do think would be nice though for a future version would be for the core to offer some of the data integrity features of a rational database but managed through template and page settings: Something to mimic CASCADE and RESTRICT so that in a page reference, for example, you can restrict it being deleted if another page references it Make a field (of fields) unique as above

@FrancisChung Thanks for writing this tutorial, but I'd suggest changing the title. You're describing functional or integration tests and not unit tests. Unit tests try to test the smallest units of software with as few external dependencies as possible (e.g. a method or a class). Testing browser output is possibly the largest testable unit of a website. I know that these names are almost never used 100% correctly, but I think in this case it would really make sense to correct the terminology.

Another thing you can do is hook Pages::added (only called for new pages, not when re-saving existing ones) and in your hooked function set the page name to the page id, which is already part of the page at that point.

This is the nature of how the ajax uploading works, as it triggers a page save (though saving only the field you upload to). One way we could solve it is to add a status field to the file/image fieldtypes, giving them a way to identify a file as unpublished. Not sure how simple it will be to implement, but this is one of the things I've had on my list for awhile. If it comes up more often, I'll definitely bump it higher up the priority list.