spackmat

Hi everyone, I implemented Zeka's snippet as a module and it works as expected. But the emojis are only shown within the pagetree, not in the listings of templates, which would be really appreciated for my project as there are tens of templates for several datatypes. I looked through the core code and didn't find hooks for those listings. What is the preferred way to find core system hooks? I saw that the icon system is deeply integrated into the core, so I am close to abandon the emoji-idea, since it looks not that easy to replace the icons everywhere. Any thoughts on that?

Great, thank you @Zeka, plain and simple!

Hi, I am implementing a page with many different templates and in many cases the FontAwesome icon set has no really good/distinctive icon. We use notion.so much for planning and there we set an emoji for every entity do recognize them easily. Question: is there any way to use unicode characters instead of FontAwesome icons for ProcessWire templates? I saw this topic, so there is a hook for the rendering of those icons in the page tree, but how can I replace the Icon-field of a template with a simple text-input? I am not that familiar with the PW internals yet. Any ideas on that?

I came to the same question as @adrian: The FieldtypeVerifiedURL is nice, but without any assist not quite comfy for our editors. How can a combination of FieldtypeVerifiedURL and FieldtypeAssistedURL achieved? Edit: I'll open a Thread on this in the Profields forum.

Again, thanks for your quick and valuable feedback! I think I understand the case. Which doesn't solve the missing input validation, so I'll have a look at those hooks. How do others solve this? My users, including me in an editor-role, aren't that good and input invalid data from time to time that must be handled well. P.S. we are replacing a really bad implemented Sharepoint-based website with a better one based on Processwire. One of the pain points of the Sharepoint system is that it has a lot of pitfalls where things can go really wrong and almost no valuable feedback for our editors on this. So our replacement has to be much better in that point, because we promised it. And it has to be as convenient for the editors as the old TYPO3/TemplaVoilà based site was, that we had before the Sharepoint site and that worked well for 10 years.

Thanks for your quick answers! @gmclelland the concept of hooks in the backend sounds interesting, I'll have a look into that later. @LostKobrakai I know about this view, but I strongly disagree with it. From my perspective, there are two layers of handling invalid data. The one at input time, where UX and software ergonomics say that systems should give valuable feedback to the users in case of invalid or problematic input (and try to fix minor problems automatically, but also with feedback). And the one at computation/output time, where the system should handle all data fault tolerant. If I had to choose only one, it would be handling invalid data at output time (at least for the case, where the validation rules fail or change). But there is no restriction on that, so my best case is to handle invalid input on both sides. So Ryan's point is completely valid: Nobody wants systems, where some invalid data breaks the whole page's output. But that doesn't invalidate arguments towards input-validation, which is another issue. And about silent fixing: A system cannot decide, what a user wanted. For the example of end date before start date: Did the user just mixed the fields up? Or is one of the dates simply mistaken? In the first case, a simple fix would be helpful, but in the second case in the end, the user did one mistake and the silent fix made it worse and now both fields store data, that the user didn't want to input. A system then has to ask the user what his/her intended input was and therefor input validation ist a must, since output fixing cannot ask questions. I was wondering, why there is an engine using expressions to decide, if a field is required or shown at all depending on other fields values, but not if its own value is valid. It would be a great addition to make this engine available for simple validation tasks.

It's an old thread, but I came along this with my first PW steps. I found a syntax of conditions, when a field is required or not and I'm wondering, why this neat stuff is not available for simple validation tasks. For example to ensure that some date is after one or several others. In my first case this is an optional "publicly available end" field that must be after "publicly available start" and after "shown publication date". The selectors used in the templates later depend on those constraints to find the correct pages. Basically I want to enforce my users to input consistent data. Another usecase is an image field, where I want to validate the images count (min 1, max 5 images). In that case I could write a notice to the users that more than five images are ignored, but a validation would be the better solution from my point of view. Am I missing something? In my other life I develop Symfony-based applications with a lot of (soft/noticing and hard/failing) constraints between input fields and Im clear about the point, that a CMS cannot provide such complex constraints on its own (without using custom field types). But some basic constraints should be usable out of the box and there is already a system, which is limited to decide, if a field is required. Greets, Gregor