Leaderboard

This would be the cleanest imho: $photo = $item->get("image_" . $categorie); You could also do this: $property = "image_" . $categorie; $photo = $item->$property; Or this $photo = $item->{"image_" . $categorie}

Using the HTMLPurifier demo page, if you change the defined Doctype to either of the standard HTML Doctypes, the BR tag will not use the XHTML formatted version. That said, there may be other unforeseen consequences in making this change. If this is simply an aesthetic preference, I would personally recommend leaving it alone. If there's another reason for it, I'm thinking that a call to str_replace on your data would be far simpler. If you do decide to customize HTMLPurifier, a good place to start for examples would be here and here. Here's an example set call that would change the Doctype to HTML Transitional, adjusted from the PW API Documentation example: $wireData = $markupHTMLPurifier->set('HTML.Doctype', 'HTML 4.01 Transitional');

@Pete Oops, looks like I neglected to push the final "bump version" commit. Just pushed it and the version number should update within a day. Thanks.

All of this seems pretty doable. ProcessWire has a built-in access control system that is REALLY powerful. For example, you could have "content editor" roles doing the articles only, and "financial editors" roles for people that can edit loan information or view potential client loan requests. (Just throwing ideas here) Each loan type could be a page with the required template/fields to define the loans. Again, a page with a template with the required fields should be enough. Save forms to pages, and show them on a ListerPro! Doable with some Process modules (basically a way to make custom dashboards in processwire, it's a bliss and almost the same as doing any frontend work), could be as simple or complex as you want. What would probably require more though on how you show/process data is with the loans themselves, what I would do is, have a page that holds the loan information, and pages that are child of it as "transactions" that affect the loan statuses, every time a transaction is saved, calculations could be done on the loan page holding the main data. For example, to update a field that shows how much is in debt or already paid.

After a previous request for Webp support (6 years ago, times flies…) that Horst and Ryan kindly introduced in PW 3.0.132, I'm back with another request for a new image file format, AVIF, which has landed in almost all browsers. I'm actually surprised no one here in the PW community has been asking for AVIF support in ProcessWire as it seems to be provide much more consistent gains in compression and greater relative quality over Webp, and of course over good old JPEG. My experience using it definitely confirms this. I've been using Cloudinary to serve AVIF images to the browsers that support it, but of course I'd rather not use a third-party service, and use it natively in ProcessWire. Imagemagick supports AVIF if I'm not mistaken. Anyone else is interested?

I would pretty much agree with all the above comments. Having built a number of web apps, I would say that PW is by far my favourite tool to turn a conceptual design into a working application, quickly and in a fairly ‘natural’ way. Obviously you need some reasonable php knowledge. Also don’t underestimate the work in getting the look and feel that you want for the front end - it’s not like Wordpress in that regard (but I hate WP for apps). You will need to give some careful thought as to whether you do one or two sites. If there is a lot of interaction between the front end and the admin functions then one site is probably best. Otherwise two interacting sites gives you a ‘cleaner’ CMS for the public site but is slightly more complex to implement. Last, but not least, the PW forum members are really helpful if you get stuck ? Ps. Not sure if the op is still interested but that’s my twopennorth anyway.

Hi Vincent, very honoured that my little translations may have any interest ? actually, i don't really know how to do what you're talking about but i'll have a look at it just a little detail, you may have seen that i keep a different repo for each pw master release because i've conviced a few french friend to use pw and depending of the version updating the files may lose some older texts actually as i keep translating release by release i've even considered making a different repo by dev release or creating a new repo with all the translations in zips named after the release this explains why the zips with the fact it's also the easiest way to update a language translation, uploading a zip that pw will unzip server side and boum everything is up to date ? just tell me what would be the best way for you to use my repos (one called last master release with the json files? and keeping the others for my friends using older releases for example) have a nice day chris

In the context of CKEditor the <br /> tag is probably caused by the CKEditor settings rather than HTML Purifier. Using this answer as a reference, you could put the following in /site/modules/InputfieldCKEditor/config.js: // When CKEditor instance ready CKEDITOR.on('instanceReady', function(event) { // Output self-closing tags the HTML5 way, like <br> event.editor.dataProcessor.writer.selfClosingEnd = '>'; });

The issue is a bit more complex than that, maybe because of the way my menus work. I tend to have (viewable) pages which have (viewable) children, so the top-level menu items can also be pages, in which case they also appear in the dropdown and can be selected either by clicking the top-level item or the one on the dropdown. If you just fix the home page highlighting then, in my case, the parent will be highighted in the dropdown as well as on the top level. See pics below: What I want (& my code above gives): What isActive() gives me (currently): Aagh! Of course you are right. I changed it to find() so that the home page was also included. Your menu assumed that home was not a menu item (hence also the issue with isActive() ). So now I have changed it to $home->children($selector) and the order is correct and all my complications go away (but I do then need to prepend $first to $items). Never mind it was an interesting exercise and may come in useful one day.

Well, that's a totally different story then. Your explanation was a little short, so I did not realise we are talking about a field of an image rather than a field of a page... I've at least posted an update that forces the first alfred argument to be a Page. And if you provide something else you'll at least get a better error message: I don't know of any good way to render the editor interface just for one single image (or even a field of that image) so I don't think what you are trying to do is easy to achieve.

Thx I've added PHP>=8.0 to the module requirements array ?

Hi @uiui, I've added in this option and released v1.0.4. From the README: Use for all dimensions? If enabled, a set rule will be used regardless of whether it is wider or higher than the dimensions of the original image. To use this on a srcset call, enable the allSets option: $srcset = $image->srcset('4096, 2048, 1024, 512, 256', [ 'allSets' => true, ]); // If passing an image 2000px in width, the above would return a srcset with set rules for each given width // Without 'allSets' enabled, the srcset generation would terminate at 4096w I hope that is useful! Cheers, Chris

Pros of PW: You already have a solid and flexible backend (access control, fieldtypes and inputfields, ...) Great fit of frontend + backend (you might be able to build everything as one app) It's really easy to create custom admin pages as @elabx said (see link) All the great things we love about PW Cons: Backend Design/UI/UX/tec (it's not the most modern one, you are limited in styling (or at least it's not that easy, see https://processwire.com/talk/topic/20659-rockskinuikit-easily-and-quickly-skin-your-adminthemeuikit-backend/ as possible workaround)) Many logged in users at the same time? The PW backend might not be resource friendly - no experience with that! Bad Continuous Integration support (see https://processwire.com/talk/topic/21212-alpha-rockmigrations-easy-migrations-from-devstaging-to-live-server/ ) Very limited data listing tools (ListerPro is great for some Listings, but really not great for more complex and more visual ones...) Need a good mobile experience for your backend? You might not be that happy with PW... This list is neither complete nor the only truth ? I don't really have any experience with other frameworks - that was just some experiences I had over the last few years building more complex apps on PW. I'm happy to learn from different opinions ?