Leaderboard

Merry Christmas/Happy Holidays and Happy New Year! This week we take a look at two new modules released this week: LoginRegisterPro and FileValidatorImage. Plus discussion of upcoming plans for new FileValidator modules and how they are useful in PW. Then a brief highlight of two great new ProcessWire-powered websites— https://processwire.com/blog/posts/new-modules-and-great-websites/

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 ?

I can only repeat what @bernhard said. For me the admin area is outdated and does not feel fast enough. However you are free to create an own custom admin area (not only theme, but you could do it as a vuejs application). One bottleneck is the PageFinder which is very slow compared to Laravel or RockFinder, as it fetches many relations for each page. RockTabulator in conjunction with RockFinder is better for some sort of listings than ListerPro but requires more initial work, and has not all the filter possibilities that ListerPro has. I think ListerPro would be a good match for you. I built some applications where I use both RockTabulator AND ListerPro, for different tasks/views. One disadvantage of ListerPro is, that you can't use it on custom module pages, but you can do it with RockTabulator. One superior feature of the PW admin is the conditional dependency of fields (show field only if value x is in another field), which I haven't seen in other tools yet, or not yet to that extend. Regarding your original question: It is possible with PW, and it might be the perfect fit for this type of application, but only if you use the right tools/modules. Else I would look into Laravel in conjunction with AdminLTE or Laravel Nova, but thats just my preference.

Hello, I am planning a project and need your expert opinion if I can use ProcessWire for it. A micro-financial management application needs to be built. Objectives: 1. On the front-end: Website CMS with article pages, Client Control Panel, loan calculator and form submit page. We have a micro-financial organization that offers micro credits to people. The front-end needs to host some article pages about provided services, a page with the loan calculator and a form submitter, so the client can input requested data (Name, phone, and few scanned images of documents, type of the loan, period of time and needed amount). If the request for the loan is approved by administrator, the client should have a Client Control Panel, where he will log in using an ID and password, generated by admin after approval. In the Control Panel, he may get updated info about the loan he got, next payment dates and total of the debt to be paid. 2. On the back-end: Control Panel with 2 user groups: for administrator with access to all the CP and operator for specified sections access only. From the Control Panel, all the front-end articles should be added, modified, deleted. A dedicated page for setting up the loan calculator for the front-end (min/max loan amount, % to be paid and intervals). A dedicated page for creating different types of loans, with their own loan % settings and periods of time (these loan types should be able to be listed on the front-end, when users apply for a loan). A dedicated page for listing all the loan requests from visitors, awaiting for approval. A dedicated page listing all open loans, closed, late, etc based on approval and closing deadline date. A dedicated page holding informations about when the debts were payed and what was the amount (some kind of the history of the loan payment activity for every approved loan). A page listing all the clients with debts, filtered by input periods. I know ProcessWire is very capable, but I don't have experience using it, so I need your opinion if such a project can be done with PW. I can buy any Pro modules needed for the project. Thank you

I'm definitely interested in "modularizing" this part, or alternatively adding support in some other easy-to-enable way. Modules would be a logical solution, but on the other hand it could be even nicer if there was a way (perhaps via Composer) to skip the module part, install the engine, and be done with it. Might be too much to ask, but who knows, maybe I could still make it work out of the box for a couple of popular engines or something ? I had a quick read about Smarty before posting here, and my initial impression was that it was somewhat obsolete – though now that I've actually checked out their site, it seems that it's at least receiving regular updates, so perhaps that text was a bit opinionated (what a shocker – someone on the Internet might not have been objective ?‍♂️) They mentioned Smarty being slower these days (apparently it used to be categorically faster than Twig or something), and also talked about it "not being secure by default" (which, I assume, was referring to not automatically escaping content). Not sure how much of those is really true either. I must admit that right now I'm inclined to favour Twig, though, even if for the reason that – in my opinion – a templating language that allows PHP kind of misses the point. I get why one might want to do that, but the way I see it, that eliminates a couple of major reasons to use a templating language in the first place... and suggests that perhaps PHP might've been a better choice in the first place ? Back in the days I wrote a blog post comparing PHP and Twig, but let's not go there now – opinions and all that ? I'll definitely take a closer look at your tutorials, thanks for reminding me of these! And yes, I do think that Twig support would make sense. Honestly the main reason I've included Blade at the top of my list is the Laravel connection: if Blade support could make it easier for someone to move from Laravel to ProcessWire, that'd be a nice little bonus ? I can definitely see your point. Wireframe itself currently requires PHP 7.1, and officially I've recommended going with one of the supported PHP versions, which at the moment means at least 7.2. PHP 7.1 was EOL'd at the beginning of December, so technically using it is no longer recommended (although if it came with a supported Linux distro, it might still be receiving security updates.) As such, I don't think that any of these frameworks is really going too fast – but I do appreciate your point of view and the info you've dug out (I had no idea which versions were supported) ? You're also right in that it's problematic if the engine isn't well supported. The problem with Blade is that I'd like to support it (due to the Laravel connection), but the official releases are not standalone. As such, it would have to be one of the "unofficial" spin-offs, which I'll admit is not an ideal situation. I've experienced this first hand in the past (with Dust). Twig and Latte definitely have the upper hand here. Markup Regions is on my todo list, but I can honestly say that I haven't given it much thought yet. I can see how that would make certain things easier, but I'm also afraid that it'll make it very, very hard to figure out what's going on – mixing Wireframe concepts (layouts, placeholders, partials, and components in particular) with markup regions seems like it could be powerful, but there's a truckload of confusion ahead if one dares to dive too deep into that particular rabbits hole ? Thanks everyone for your comments so far! At the moment I'm leaning towards Twig as the first experiment, then Latte (if all goes well), and finally Blade. Unless some new information shows up, that is. Apparently there haven't been that many major changes in this field lately – I used Twig with some Zend Framework projects back in the days, and by the looks of it it's still going strong ?

I'm not so sure about that.

I would go with Smarty or Twig. Used both. Smarty allows to use PHP functions in it's template strings, Twig does not (only with custom extensions), and Twig throws errors if something is not programmed 100% clean. That nagged me about it, also disliked the double delimiters. In terms of speed Twig and Smarty are almost even, sometimes Smarty is quicker, sometimes Twig.

Hi Ryan, thx for the great news and happy holidays and a new year to you as well ? That sounds great. I've no idea how you plan to implement this, but I wonder if it could make sense to also have the backend in your mind for this Inputfield ? I've had several occasions where the admin file upload field was not ideal (mostly in ProcessModules and ModuleConfigs). And others had issues as well (eg @Robin S https://github.com/processwire/processwire-issues/issues/964 ). I think also @Gadgetto had problems with some kind of invoice upload field?! I have no specific example right now where and how this would make sense, but maybe others have one?

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.

? Will be great if you can mix Markup Regions with the concept of the "Tags File Compiler" module https://processwire.com/blog/posts/processwire-3.0-alpha-2-and-2.6.22-rc1/#new-module-file-compiler-tags

Twig would definitely be number one on my list, I've been using it for every project for a while and it feels waaaay cleaner than native PHP or Blades. See my tutorials (part one - part two) regarding the Twig integration ? Part two has some examples of connecting Twig to the ProcessWire API, it's a natural fit.

I've checked the above config on my DataSet test site and it is valid. (Don't forget to save the page to run the validator again.)

@theqbap Then add the string "JSON" before the config : JSON{ "name": "Testing the import", "input": { "type": "csv", "delimiter": ",", "header": 1, "limit": 10 }, "fieldmappings": { "title": 1 }, "pages": { "template": "Data", "selector": "title=@title" } }

Thanks a lot for your suggestions @szabesz @bernhard I really like ImageSorcerer and ImageReference. The former for its creativity, the latter for its clarity and reference to the page reference field. The more I think about it the more I tend towards ImageReference. It says it all clear what this fieldtype and inputfield are doing: allowing you to store a reference to an image that lives elsewhere in the system. I had that thought, too. But I decided to leave them as separate options mainly because the 'select image from page' allows to setup a dedicated page with a set of images to choose from and to categorize them by using child pages. If I made this a flexible option it might not be obvious for developers and editors what is really happening here. What I'm currently working on is having the PageListSelect remember the page that the image was selected from. Will release this feature before end of this year.

sure, here is the page table; the fields on any given section are just like title, headline, body, images, page select, section options etc, plus "section type". Some sections have no configuration. The slider section allows the user to select which slides to show; the slides themselves are stored in a central media library, and the settings for any slide are stored with the media item. Sections with images have a field to select the media item to use for the image, or upload an image. For a site like this, every image needs to be cleared and licensed, so the media library provides that functionality, with fields for license type, photopgrapher, sources etc. I'm not using the MicroContexts on this site; that module is now called "Page Field Contexts", and it enables template contexts based on Page Field values. It's a super simple, yet effective module and I'm using it on several sites. https://github.com/outflux3/PageFieldContexts

Most fancy out-of-the-box austosuggest widgets have accessibility problems, Typeahead is one of them. It's a known issue, and there seems to be a fork with optimizations. The UK government has built their own version.

I love the Christmas card. It's a good reminder that Processwire isn't just an incredibly useful collection of code for geeks, but is also a tool that allows people to provide for themselves and their families. I'm not sure how much my daughter understands what I do on the computer, but she does understand it helps pay for holidays and Lego amongst other things. ?