Leaderboard

@ryan What I love about PW is that you can do the craziest projects with it. The flexibility of PW allows you to implement anything from a payment terminal to an e-book with maps. And even the older versions remain reliable and work as designed. I have PW version 2.3 running somewhere - no complaints from customers. This is a genius invention. Thanks. I hope to post a new project on PW here soon that implements a remote medical equipment management system.

Sorry, deleted the Code. I am not using it in production, just on localhost. to test the Android-App.

@@byte the code you posted is vulnerable to SQL injections, because you're concatenating raw strings from the request into your SQL query (as @zoeck said). Even if it's just an example you're not using in production, I'd prefer if you didn't post it like that, because people might copy it.

Ok, give me a minute, I will add an if condition. In the meantime you can take a look at the example of uploading a file to page. https://github.com/juergenweb/FrontendForms/blob/main/Examples/fileuploadtopage.php This is the way to go - I have tried it and it works in my case.

Hi @pmichaelis, it is indeed a little bit hidden, but you will find an example of a single and a multiple file upload field inside the example of the contact form at https://github.com/juergenweb/FrontendForms/blob/main/Examples/contactform.php Best regards

I'd not call it more professional. It's just different how you usually do such things in ProcessWire. In common PHP frameworks you'll mostly have the same setup: Database tables and PHP + mysql queries. In ProcessWire this is totally different: You have Pages + the PW API. The PW way has a lot of benefits, for example: You don't have to build a GUI - you get the PW Backend for free You don't need to write plain SQL - you have the PW API for reading/writing data which is usually a lot easier and also more secure In your example instead of having a DB table "rundgang" with columns "person, wasser, start, ende" you'd add a PW template called "rundgang" and add fields "person, wasser, start, ende" to that template. To add records to your system instead of doing "INSERT INTO ..." you do this: <?php namespace ProcessWire; $p = new Page(); $p->template = 'rundgang'; $p->parent = 1234; // your parent page id $p->person = $pages->get("template=person,name=bernhard"); $p->start = "2023-01-05 20:00"; $p->ende = "2023-01-05 21:30"; $p->save(); And to output entries on the frontend instead of doing "SELECT ... FROM ..." you'd do something like this: <?php namespace ProcessWire; $start = strtotime("2023-01-01 00:00"); $end = strtotime("2023-02-01 00:00"); foreach($pages->find("template=rundgang, person=123, start>=$start, ende<$end") as $p) { echo "Rundgang: {$p->person->title} von {$p->start} bis {$p->ende}<br>"; } To create a custom endpoint for your App have a read about URL Hooks and Bootstrapping PW.

That's exactly what I was looking to do. That's a good tutorial for it. I'll report back with my findings hopefully soon.

Do you want to simply access existing Processwire pages or create new ones? Or do you have your own table ("kontrundgang") where the data should go? You can have a look at the Database API: https://processwire.com/api/ref/wire-database-p-d-o/ By the way: you should never execute unsanitized values in a sql statement!

This might be helpful: https://korepov.pro/infobase/vs-code/23 Haven't tried it myself but looks promising.

@BrendonKoz, when I started this thread I was not sure if PHP had anything to do with it, but looking into it further it became clear that it had. So I started another thread - sorry... - where I found the solution: PHP upgrade via EasyApache doesn't include the Apache mod_suexec module by default. Without that module 'the system executes PHP applications as the nobody system user' instead of your myusername. 'If you install the suEXEC module, the system executes PHP applications as the user that owns the VirtualHost that served the request.' I guess these modules were introduced somewhere between recent PHP versions? Enabling the mod_suexec module, included in EasyApache4, should fix most problems. There is also another Apache module mod_suphp that may be required to fix issues with some scripts.

I have to stop a day early to leave town for one of my daughter's gymnastics meets, so I'm going to save the core version bump for next week, after a few more updates. The most interesting core update this week is one suggested by Netcarver and Pete. It is to make the "HTML Entity Encoder" Textformatter option (for text fields) more foolproof, by making it harder to ignore. That's because this option is rather important for the quality assurance and security of your site's output. If you forget to enable it for one text field or another, then you allow for the potential of HTML in the output for that field, by anyone that can edit pages using that field. Most of the time when you aren't entity-encoding output, HTML is exactly what you want, such as with TinyMCE or CKEditor fields. HTML entity encoding is necessary when the field value isn't itself HTML, but will eventually be used in HTML output and needs to be valid for HTML output. Think of a "title" field, for example. For these cases, you want to be sure that characters like greater than, less than, ampersand and single/double quotes are properly encoded. Greater-than and less-than characters form HTML tags like <script>alert("gotcha!")</script>, ampersands begin entity sequences, and quotes are used to open and close HTML attribute values. By entity encoding all of these characters, we ensure they can't be used for malfeasance, scripts, XSS, defacement, etc. The worst case scenario would be that you neglect to enable the entity encoding on a text field where you are allowing non-trusted user input, as that could open the door to such shenanigans. To make things more foolproof, ProcessWire now gets in your face a bit more about using the HTML Entity Encoder. Maybe it's a bit more annoying for more experienced users, but if you happen to be in a rush, it'll make sure you at least don't forget about it. Or maybe some less experienced developers might not know the importance of entity encoding in HTML, and this update helps them too. Here's what it does: It now enables the HTML Entity Encoder (Textformatter) for all newly created text fields (and derived field types). Previously it just suggested that you enable it, but let you decide whether or not it was appropriate. Now, it errs more on the side of caution. Since the entity encoder is now automatically enabled for newly created text fields (in the admin), it seemed necessary to detect cases where the field configuration clearly indicates it's intended to allow HTML (by input type or content-type). Examples include textarea fields configured to use TinyMCE or CKEditor, or any text field with a content-type set to HTML. When these cases are detected, it advises the user to remove the HTML Entity Encoder from the selected Textformatters. If editing an existing text field (in Setup > Fields) that doesn't appear intended to use HTML (i.e. not TinyMCE or CKEditor and doesn't have its Content-Type set to HTML), it will now test all the selected Textformatters you have selected (if any) and see how they handle HTML. If they leave HTML in place, or you have no Textformatters selected, It will provide a warning to you, letting you know that HTML is allowed, and leave it up you to decide whether that's what you want. Note that these additions are only for fields created in the admin. Fields created from the API make no such assumptions and work the same as before. That's it for this week. More updates and hopefully a version bump next week. Have a great weekend!

Cool tip, thanks! As an aside, are you using findRaw() to get your data for the options? My experience lately is that when I make use of findRaw() I rarely need to cache this sort of thing because it's so much faster than loading whole Page objects.

There's tradeoffs between maintainability and controllable surface area vs. flexibility. The more options available the more permutations of options there are. More permutations of options make downstream concerns more tricky like caching, authentication, internal querying, …. Just need to look at the issues with deploying a graphql API at scale, where graphql sits rather close to the flexibilit end of the mentioned scale.

try $hassidebar = array('home','project','projects','posts','partners'); if (in_array($page->template->name, $hassidebar) { //... } EDIT: adrian was quicker. Either of it should work.