Leaderboard

This week we give extensive coverage on how to optimize 404 requests in ProcessWire. In this post you’ll learn about why 404s are significant issue, and then we’ll look at what you can do to optimize and ensure your site doesn’t waste valuable time and resources serving irrelevant crawlers and bots. This post also briefly covers this week’s core version 3.0.52. https://processwire.com/blog/posts/optimizing-404s-in-processwire/

Hi all! Major overhaul / refactor just committed. To quote Github: Showing 54 changed files with 1,705 additions and 1,295 deletions. Yes, I haven't slept much lately I have tried to test everything very thoroughly, but with so many changes, there might be new bugs introduced. Please let me know if you find any issues. You'll also noticed that I have bumped the version number to 4.0.0 and am using a string now so that I can start being more semantic with the version numbers. Here's a rough highlight of the changes. New skin - a huge thanks to @tpr for all his efforts on this, not to mention lots of other feedback / bug reports while developing this new version! Captain Hook Improvements - it now shows dynamically added hooks, like Page::viewable in both the core and your site module. Also some general cleanup. More SessionHandlerDB fixes - there were still some outstanding issues with some of the lesser used panels. Hopefully we're closer to this being a non-issue. Improved CSS loading - in particular when opening panels in a popup window. General code updates - various things, including updating wire() and $this calls to $this->wire() where appropriate. Lots of bug fixes - mostly issues with the lesser used panels that had gone unnoticed, but still it's amazing what you find when you do a major refactor. Better code documentation - not my strong point in the past - hopefully this is now on the way to being much better. File / folder restructuring - not really of concern to you guys, but will make life a little easier for me going forward with future enhancements. Captain Hook panel showing new dynamic hookable methods and @tpr's fantastic new skin!

Hi @DZuz14 - welcome to the wonderful world of PW, the anti WP CkEditor is built in to PW - you just need to choose CkEditor here from the Inputfield Type on the Details tab of your textarea field. Hope that helps!

$input->whitelist does not store values. It does just mark $input variables of the current request, so they can be appended to (pagination) links as ?my_data=xyz variables, which on the next request can be read again. If non of those links is clicked the values are gone. The most prominent use case is preserving any user filter values while going through pages of results. Having the values in the url also makes sure you can send that url to your peer and he or she can open it as well. Anything you don't want the user to see/modify you'd use the session.

you could also put everything in one file to have all translations aggregated in one page in the admin custom code: return wireRenderFile('fieldmarkup', array('field' => 'calendarbox')); fieldmarkup.php <?php switch ($field) { case 'calendarbox': $out = '<div>...</div>'; $out .= '<p>...</p>'; echo $out; break; } i guess for easy fields that would be better than having a file for each field...

Very nice and very useful. Thanks

How exactly did you solve it? I'd like to know why those other lines were there in the first place.

This was extremely helpful. Thanks for taking the time to explain. Up and running now.

This https://www.mail-tester.com helped me with my e-mail. I got it from someone here on the forum i think.

A little debugging is in order then. You have two variables, $input->whitelist('cb_sectors') and $cb_sectors->name, and you want to know what is in them. You can use basic PHP functions such as var_dump() or print_r(), or you can use the much nicer dumping options in Tracy Debugger.

Solved. I checked using your php above, and it turned out that the issue was with my browser cache and not the code. Thanks @flydev !

As I have just finished implementing the FTP transfer protocol, I hope it will be available for beta testing this week-end . I have to implement Amazon before. I am going to buy an Amazon account tonight and implement this feature tomorrow.

That's right. That's the way it will work when module is done. Currently there is a support for template permissions. Support for Field permissions are on the way, I am working on it but it will take some time. For now you can limit the fields via module settings, I pushed support for legal fields two hours ago. Thumbs up from @horst ! Yeeeey I am a big fan of your modules!

NOTE: This thread originally started in the Pub section of the forum. Since we moved it into the Plugin/Modules section I edited this post to meet the guidelines but also left the original content so that the replies can make sense. ProcessGraphQL ProcessGraphQL seamlessly integrates to your ProcessWire web app and allows you to serve the GraphQL api of your existing content. You don't need to apply changes to your content or it's structure. Just choose what you want to serve via GraphQL and your API is ready. Warning: The module supports PHP version >= 5.5 and ProcessWire version >= 3. Links: Zip Download Github Repo ScreenCast PW modules Page Please refer to the Readme to learn more about how to use the module. Original post starts here... Hi Everyone! I became very interested in this GraphQL thing lately and decided to learn a bit about it. And what is the better way of learning a new thing than making a ProcessWire module out of it! For those who are wondering what GraphQL is, in short, it is an alternative to REST. I couldn't find the thread but I remember that Ryan was not very happy with the REST and did not see much value in it. He offered his own AJAX API instead, but it doesn't seem to be supported much by him, and was never published to official modules directory. While ProcessWire's API is already amazing and allows you to quickly serve your content in any format with less than ten lines of code, I think it might be convenient to install a module and have JSON access to all of your content instantly. Especially this could be useful for developers that use ProcessWire as a framework instead of CMS. GraphQL is much more flexible than REST. In fact you can build queries in GraphQL with the same patterns you do with ProcessWire API. Ok, Ok. Enough talk. Here is what the module does after just installing it into skyscrapers profile. It supports filtering via ProcessWire selectors and complex fields like FieldtypeImage or FieldtypePage. See more demo here The module is ready to be used, but there are lots of things could be added to it. Like supporting any type of fields via third party modules, authentication, permissions on field level, optimization and so on. I would love to continue to develop it further if I would only know that there is an interest in it. It would be great to hear some feedback from you. I did not open a thread in modules section of the forum because I wanted to be sure there is interest in it first. You can install and learn about it more from it's repository. It should work with PHP >=5.5 and ProcessWire 3.x.x. The support for 2.x.x version is not planned yet. Please open an issue if you find bugs or you want some features added in issue tracker. Or you can share your experience with the module here in this thread.

FieldtypeFileS3 https://github.com/f-b-g-m/FieldtypeFileS3 The module extends the default FieldtypeFile and InputfieldFile modules and adds few extra methods. For the most part it behaves just like the default files modules, the biggest difference is how you get the file's url. Instead of using $page->fieldname->eq(0)->url you use $page->fieldname->eq(0)->s3url(). Files are not stored locally, they are deleted when the page is saved, if page saving is ommited the file remains on the local server until the page is saved. Another difference is the file size, the default module get the file size directly from the local file, while here it's stored in the database. There is an option to store the files locally, its intented in case one wants to stop using S3 and change back to local storage. What it does is it changes the s3url() method to serve files from local server instead of S3, disables uploading to S3 and disables local file deletion on page save. It does not tranfer files from S3 to local server, that can be done with the aws-cli's through the sync function. Files stored on S3 have the same structure as they would have on the local server. -------------------------------------------------------- -------------------------------------------------------- Been struggling with this for quite a while, but i think i finally managed to make it work/behave the way i wanted. All feedback is welcome!

Consistent with the plans of introducing new site profiles this year, we’ve started work on the new site profile, and have the first version ready this week. This profile contains a blog component and uses the new Uikit 3 front-end framework: https://processwire.com/blog/posts/introducing-a-new-processwire-site-profile/

Great job @adrian and @tpr! Just tried it and it looks and works very nicely.

@LimeWub Regarding the processing of the form pages. You can save the forms in one or more pages under a page representing the user. For example you create a page named "Users" and whenever an user registers you create a page under users with the user's name. Users --username1 --username2 Then when he submits a form you create a page under the corresponding user. Users --username1 ----form1 ----form2 ----form3 --username2 ----form1 ----form2 Or create just one page and you save just the fields from the current form and on the next forms you update the page with the new fields. Then you can get the forms for a user with $currentUserForm1 = $pages->get("parent=/Users/username1/, name=form1"); $currentUserForm2 = $pages->get("parent=/Users/username1/, name=form2"); create pages through api upload files

Nice post and I love coffee!

Green just tells you that the request itself completed, but not if the returned content is valid. You have to click on the last entry there (the request for /processwire/page/list/) and look at the returned content. You'll likely find some kind of error output in there that can give you a better clue at what's going wrong on the server side.

Just to clarify: background-attachment is not working well on iOS Safary: http://caniuse.com/#feat=background-attachment Here the CSS that can work for the container (did not tried it out, but should work): .background { background-size: 100%; background-image: url('your_background.jpg'); background-attachment: fixed; background-repeat: no-repeat; position: fixed; top: 0; left: 0; height: 100%; width: 100%; z-index: -1; } Additional you can add "bottom: 0;" and "right: 0;" if something is not working. At the end it would look like this in your HTML structure: <body> <div class="background"></div> ... </body> I don't really get why it is not possible with media queries, because you can get the device really easy by some width and height (and other parameter) values that are mostly used for iPad or other devices. Here a link for possibilities: https://css-tricks.com/snippets/css/media-queries-for-standard-devices/ Here is a script from codePen to check the Version of the iOS version (I don't know if you already have this for your iosVersion): and use it in your JS code for variable iosVersion. Then do some JS+CSS ~magic~. Try CSS only (keep it simple), if it is not working (or get too complex for you) combine it with JS if it makes sense. BUT: Please, do not run the scroll position on every scroll to change the position in your inline CSS code. On not so powerful hardware it can hurt the experience of your site. The CSS code should do better. Hope this helps.

Modules will all be refreshed as soon as they're used for the first time. That's why you get those notifications again and again.

Mod Note: Moved your topic here as it is not a ProcessWire question but a general dev one.

I am not sure I follow either but I'll have a go . Is $page->alias a string or an integer? I am curious since you do this: author.id=$page->alias. Did you create your own field called id or is that the inbuilt page ID? I don't understand the foreach question. If what you are after is matching multiple values or multiple fields, then what we use are pipes |. See this docs. You say you would like to match publications by either name or their alias. However, the examples you give are not using or selectors; they are using AND selectors (i.e. comma separated selectors). See those docs for the differences.

What is the $c - is that your pageArray? also, this is not much to go in, can you explain more?

@tpr - I have struck an access problem with Repeaters that seems to be caused by AOS. I opened a GitHub issue for it rather than clutter up this thread.

Hmm...I don't think it's possible. But you never know!

Just a quick by the way, I recently updated the first post in this thread to state that the wireRenderFile() approach is the recommended way to use this module. I'll update the README too when I get the time.

i guess you could use wireRenderFile, then it should show up in the backend.

Security doesn't magically get better just because files are outside the webroot. The .htaccess file does already block all access to critical files inside the processwire installation and all those files must be accessable by the webserver/php anyways, which makes things equally vulnerable in terms of those security holes which let an attacker execute his own code. And as you said for lots of hosting services it's not even an option to put library files outside the webroot. Obfuscation of the system also doesn't really improve anything considerably. Ask all those people here tracking how many attacks on wp-login.php they get even though their sites are obviously not wordpress sites. As soon as security issues are known they'll be tested no matter of how hard you try to mask your underlying system. It's already possible to share the wire folder for multiple sites, but it's to be considered that all pages also need to be updated at once, which at least for me is rather a downside than an important feature. But still this is already doable. Regarding the assets folder. ProcessWire does have a config to protect the whole assets folder essentially piping all requests to files through php to ensure access is granted for each one. If you only need to saveguard some files and prevent the php overhead for the others you can install the 3rd party "SecureFiles" module, which let's you put files out of the webroot when using this fieldtype. In regards to your point about static site generators. ProcessWire is different to Laravel in that it does depend on a database. And not only an empty one, but there need to be things installed to run ProcessWire. That's not really useful if you want some static site. If you only want html output to be generated from db data you can already use ProCache to serve static html to users with the full power of processwire to generate that html.

When can we get our hands on this? Where do I throw my money?!

For a complete documentations of $mail take a look here: https://processwire.com/api/ref/wire-mail/ $mail does also use mail() internally if you don't use any 3rd party WireMail module. I'd suggest you to install one of them to not send your emails from php directly. If you still get spam flags then you should look into email domain verifications like SPF or DKIM and maybe use one of those email testing services to analyse your sent mails for other spam triggers.

But all you said is already can be achieved. No need to do anything on my side. Maybe add documentation on module's properties though. You can modify the module settings via api by overwriting them. So here how you can set different templates for different endpoints. // /site/templates/graphql-endpoint1.php <?php $ProcessGraphQL = $modules->get('ProcessGraphQL'); $ProcessGraphQL->legalTemplates = array('skyscraper', 'city'); echo $ProcessGraphQL->executeGraphQL(); ?> // /site/templates/graphql-endpoint2.php <?php $ProcessGraphQL = $modules->get('ProcessGraphQL'); $ProcessGraphQL->legalTemplates = array('architect', 'basic-page'); echo $ProcessGraphQL->executeGraphQL(); // /site/templates/graphql-endpoint3.php $ProcessGraphQL = $modules->get('ProcessGraphQL'); echo $ProcessGraphQL->executeGraphQL(); // here it will use default settings that you set via admin interface For the ability to distinguish the versions of your GraphQL endpoints. That's also doable without much effort. We are talking about ProcessWire after all. Here how it might look like. $config->GraphqlEndpointID = 123; echo $modules->get('ProcessGraphQL')->executeGraphQL(); $config->GraphqlEndpointID = false; And same thing in other template files with different endpoint id. Now anywhere you attach a hook, you can know which endpoint of your api is being executed, or if it is being executed at all. You just need to add a conditional block in your hook. Something like if (wire('config')->GraphqlEndpointID === 123) { // some bussiness here } I am a bit confused though. One of selling points of GraphQL is that there is only one url that you need to deal with. It's just `example.com/graphql/` and nothing more. No more this GET example.com/graphql/skyscrapers/ GET example.com/graphql/skyscrapers/{id} POST example.com/graphql/skyscrapers/ PUT example.com/graphql/skyscrapers/{id} PATCH example.com/graphql/skyscrapers/{id} GET example.com/graphql/architects/ ... It's only one endpoint for everything you need. That's actually is the way it is encouraged to build GraphQL api. Also it is only one HTTP verb you need to use, which is POST. You can stop thinking about dealing with PUT, PATCH, HEAD, OPTION and more. You only need this with GraphQL. POST example.com/your-endpoint-url/ And that's it. One HTTP verb and one url to rule them all .

Look like I cant reproduce it. Could you make a screenshot ? Did you added some CSS style for the languages bar ? I just tested in chrome and the languages are still displayed above the meanmenu: Just in case, there is the full _main.php :

This sounds good, and that's basically everything that a "generic", publicly accessible API can do. I've got no complaints here What I've found out while playing with the WP REST API a while ago is that even though permissions are sensible, it may end up showing more than the public site. Part of it is about things like (not just page but) field level permissions, and part is about pages that exist and are publicly viewable for technical reason, but are not *intended* for public consumption, if you get what I mean. Surely it would be best to always use native permission rules to limit the visibility, but sometimes a site may have content that is viewable only if you know the direct URL, and a public API like this may make it "more public" than the developer intended. Another thing is that there may be a code-level permission check in place, and a module like this would have hard time figuring that out. That being said, have you already implemented or are you considering implementing custom selector support for such limits? I.e. allow the developer to manually define a selector that returned pages must match, or alternatively should never match? I think that could make a lot of sense from a security point of view, particularly for public API endpoints, where it might actually work best as a per-endpoint setting

Hello Kass, and welcome to the group. Can you also post the section that includes your mean menu. It is difficult to tell where any issue is with this code segment, as the only class designation is when the viewport is x-small.

Thank you very much for this module, @Nurguly Ashyrov! I missed this graphql thing completely, though was messing around json api a bit. Had some great time reading about it. Seems like ProcessWire fits graphql like a glove. Your module should answer a lot of recent questions about integrating PW with vue.js and alike. Dries Buytaert, the Drupal "godfather", has a nice article in his blog about the necessity for a contemporary CMS to have support for web-services built in. And his choice seems to be graphql and json api. I am sure that improving and promoting PW as a "headless CMS" kind of thing is something that could bring a lot of frontend developers to use PW. This module is the perfect start. As I understand, mutations are a way to not only read, but write data? If so, that is certainly worth implementing, so a complete SPA could be possible with this graphql module alone.

Looks super cool! Does it add some public endpoint to fetch data or how does it work outside the "console" example shown on the videos?

A small preview of uploading package to Dropbox and GoogleDrive at the same time : In this screencast I am using my own connection, thus the upload process is a bit slow.

Been using lets encrypt for a number of months now. Just note the date so you can re issue the cert before it expires. In htaccess on lines starting at 90 is where you set https.

I guys, fresh new website to showcase https://iloetscher.com/ iLötscher is a Swiss company based in Zürich that provides informatics services for Apple devices and networks. We are still working on the English version and the private area. ProcessWire wise, the website is quite simple and the only non-core modules used are the Pro-fields Table and Hanna Code — both, together with Repeaters, to support the creation of the price tables: SSL is provided by the free Let's Encrypt, that I heard from in this forum (Thanks guys!). The hosting didn't support it (and I didn't have Shell access) but they were happy to install the Let's Encrypt extension for Plesk. Just wanted to let you know that it is worth insisting a bit, in case you encounter the same problem. For the time slot reservations we are using Calendly. It works quite well, and the options for embedding the system on the wesite are very flexible also. The site is responsive, of course. Feedback is more than welcome, thanks!

Happy New Year to everyone! For a project that I'm working on, I needed to have dependent checkboxes on page edit forms in the admin. Just like dependent selects but for checkboxes. I couln't find anything and decided to write my first Inputfield module. I have only tried it on PW > 3.0. But it should also work on the 2.x branch. Would be great if some of you could try it out and give some feedback. You can find the module InputfieldDependentCheckboxes at github Here's some screenshots of the module in action and instructions on how to use it. ##An Inputfield for ProcessWire admin interface that handles the display of dependent checkboxes in page fields Sometimes we need checkboxes to depend on other checkboxes in our page edit forms. This module adds this functionality to standard page field checkboxes for 2 or more checkbox fields. ## Installation 1. Copy all of the files for this module into /site/modules/InputfieldDependentCheckboxes/ 2. In your admin, go to the Modules screen and click "Refresh". Under the 'Inputfield' section, install the 'InputfieldDependentCheckboxes' module. 3. Open Modules->Configure->InputfieldPage. Under 'Inputfield modules available for page selection' add 'DependentCheckboxes' from the select dropdown and submit ##Field Setup This inputfield extends the standard checkboxes for page fields. Therefore you need to have page fields configured already that you can extend with this Inputfield type. ###Prerequisites You need to have at least 2 fields of type page that have 'Checkboxes' defined as Input field type and live on the same template. A real world example: There are different types of instructors. Each instructor type can have multiple different certifications. For this to happen, we need 2 page fields (multiple): A) instructor_types: lists pages with template 'instructor_type' B) certifications: lists pages with template 'certification' The certification template needs to have the instructor_types page field to assign one or more instructor_types to a certification. ###Setup (link checkbox fields) 1. Edit your page field A and go to the 'Input' Tab. Under 'Input field type' choose 'DependentCheckboxes'. Hit save. Now under 'Choose the target checkboxes field' choose the name of your field B. Hit save again. 2. In your page field b make sure to choose a template under 'Input' Tab under 'Selectable Pages'->'Template of selectable page(s)'. Your fields should be setup. If you now edit a page that contains the 2 fields, the dependent checkboxes should be working. EDIT: And yes, this is working for multiple dependent checkboxes, too. (I have tried it with 3 so far) Some notes on how the module works behind the scenes: - parent checkboxes (actors) that have dependent checkboxes (targets) get custom data attributes applied which contain arrays of the targets' IDs - some Javascript is initiated on acxtors and targets to handle the display based on the id arrays in the data attributes. EDIT: since this module's mention in ProcessWire Weekly it might get some more attention. I just wanted to point out that it is still in alpha state. I will continue development and more thorough testing while implementing it in an ongoing project within the next 3-5 months or so. I will eventually release a stable version then. If you use the module with only 2 dependent checkbox fields, it should work smoothly. There are still some quirks when using 3 or more and I need to figure out how to best resolve them. So please be patient (or jump in with ideas ).

The change to PDO was motivated more by the support of named parameters. Though bringing more abstraction to the DB layer also seemed like a good move for the long term, even without current plans to support other DBs. While PDO does abstract some of the considerations with supporting other databases, ProcessWire's queries are designed for MySQL, and are optimized for MySQL behavior. There's a lot of influence from the book: High Performance MySQL. Supporting another DB platform like PostgreSQL would probably not be such a straightforward thing. Though the truth is I don't know for sure, as I've not worked enough with PostgreSQL to know how similar or different the queries we use would be. But if you are looking at implementing some new fieldtypes, it would be best to look for how you might implement them with MySQL, since support for other DBs like PostgreSQL is not currently in the short term plan.