Leaderboard

I had a need to do this and there were some requests in the Table forum so... LimitTable A module for ProcessWire CMS/CMF. Allows limits and restrictions to be placed on selected Profields Table fields. For any Table field you can limit the number of rows that may be added and also prevent the use of drag-sorting and the trashing of rows. If a limit has been defined then there is an option to show all (empty) rows up to that limit. This module does not support paginated Table fields. Usage Install the LimitTable module. The module configuration screen should be self-explanatory. You can add rows in the module config as needed using the "Add another row" button. Please note that limits and restrictions are applied with CSS/JS so should not be considered tamper-proof. Module config: The effect of the above config in Page Edit. The empty rows up to the limit are shown because "Show all rows" is checked. https://github.com/Toutouwai/LimitTable https://processwire.com/modules/limit-table/

Hello, In this tutorial I show how to use the wirePopulateStringTags function in order to improve translatable strings. https://medium.com/@clsource/better-translatable-strings-in-processwire-621e9e6b18ee#.tv2u23j4i Basically it will improve how the strings are shown in the translation administration. echo wirePopulateStringTags( __('There are {count} {items} in the {place}'), ['items' => 'apples', 'count' => 32, 'place' => 'basket'] ); Will render There are 32 apples in the basket And the Translator will see There are {count} {items} in the {place}

The login function returns an user object on successful login or null on failure. You need to check this returned user object for roles: [...] $loggeduser = $session->login($input->post->user, $input->post->pass); if ( $loggeduser->isLoggedIn() ) { // user was authenticated and logged in // user has "admin" or "superuser" role foreach ($loggeduser->roles as $role) { $content .= $role->name . "<br/>"; } } [...] PS: do not forget to sanitize your input.

v0.0.9 released. You can now select multiple roles to be affected by the limit/restrictions, including the superuser role and "all roles". @NikNak, I had a change of thinking on this issue and can now see that there are situations when it is useful for the module to affect superusers, mostly to serve as a reminder and prevent accidental changes. In any case a superuser can access the module config and so change any restrictions that are affecting them when needed.

@Soma - just wanted to let you know that I have made more changes to @owzim's script. The new version adds this functionality adds dynamically added hooks like Page::viewable which were not previously detected cleans up code within a function when it's on the same line as the function definition, eg. https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/NullPage.php#L112 removes any comments from the returned info - previously if a comment was on the same line as the function definition it would be returned also. You can see my changes here: https://github.com/adrianbj/TracyDebugger/blob/master/panels/CaptainHook/CaptainHookSearch.php Let me know if you have any questions.

v0.0.3 released. You can now select multiple roles to be affected by the limit/restrictions, including the superuser role and "all roles".

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/

LimitPageTable A module for ProcessWire CMS/CMF. Allows limits and restrictions to be placed on selected PageTable fields. Usage Install the LimitPageTable module. For the PageTable field you want to limit, on the "Input" tab include "template" or "template.label" in "Table fields to display in admin". You can skip this step if your PageTable field only allows a single template. In the module config, fill out the fields in the fieldset row: PageTable field you want to limit Role that restrictions will apply to Template you want to limit (only needed if your PageTable field allows more than one template) Field you have included in the "Table fields to display in admin" setting (only needed if your PageTable field allows more than one template) Limit Option to prevent drag sorting of items (affects all rows regardless of template) Option to prevent trashing of items (affects all rows regardless of template) Option to disable all "Add" buttons for any template You can add rows as needed using the "Add another row" button. If you are using translated text for the default PageTable "Add New" button then enter the translation in "Text for default 'Add New' button". Please note that limits and restrictions are applied with CSS/JS so should not be considered tamper-proof. http://modules.processwire.com/modules/limit-page-table/ https://github.com/Toutouwai/LimitPageTable Module config: Demo showing PageTable limited to 2 pages using 'Blank' template:

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!

Thanks @bernhard your solution works pretty well.

You could do this as follows: $titles = $page->alias->implode('|', 'title', array('append' => '|')); $titles .= $page->title; $publis = $pages->find("template=publication, categ_publi=$c, author.title=$titles");

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!

Here's my idea on how a repeater field could be limited. Instead of a hard lmit there could be a "separator", eg. consider a scenario of limit 3: Item above limit Item above limit Item above limit ------ separator ----- Item below limit Item below limit Item below limit ... As you can see there is no real limit but only a visual separator. Moving item 6 to the top would push all other items one place down, but still only the first 3 would be above the limit. The advantage would be that you shouldn't need to delete an item and can reuse them later. Anyway, I'm fine with the current solution, just wanted to share

Sounds like a useful thing to have. In terms of UI I imagine something like the action buttons in Page List, where publish/unpublish/hide/unhide buttons appear when hovering the title link in the table. Will investigate how this could be added. Not sure if it's something that belongs in LimitPageTable, or should be a separate module, or perhaps added to AdminOnSteroids. Will have a think.

Just to add onto your explanations: sprintf does also support reordering of arguments, but still with an awkward syntax: $out = sprintf(__('Your city is %1$s, and your zip code is %2$s.'), $city, $zipcode); // Translated like this $out = sprintf(__('Your zip code is %2$s, and your city is %1$s.'), $city, $zipcode);

If a whitelist value is null then it simply means you have not set anything to it at the time you are checking it. Going back to the earlier code example, you must set an array to the whitelist... $san_array = array(); foreach($input->get->st as $st) { $san = $sanitizer->selectorValue($st); $san_array[] = $san; $selector .= "projectStatus=$san, "; } $input->whitelist('st', $san_array); ...before you can use the array in $input->whitelist('st') to determine which checkboxes should be selected. The code above will appear in your search results template, and it must execute before (i.e. above) your code for generating the search inputs. Of course if you are showing your search inputs on other templates besides the search results template then $input->whitelist('st') will be null, but in those cases you don't want any of the inputs to be pre-selected anyway.

You mean you want the pages that are rendered as part of Home to be accessible at /about/, /work/, etc, to human visitors but not to Google? That seems odd, especially if they don't display properly without the CSS/JS from the Home template. I think you do want to prevent direct access to those pages. This thread has some techniques for achieving that:

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

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!

Ooh, that's right. Now I get what you mean. Thank you for clarifying that for me. That's true, with this module it gets available to the public without echoing it explicitly. So you will have to setup extra permissions to make it closed to the guest user. This was the initial intention of this module really. The goal is to build a tool that will allow you to quickly bootstrap an AJAX api of your ProcessWire content to build SPA out of it. For cases like you guys describe, this module might have some drawbacks. But you could always cook your own GraphQL api and make it behave however you want. It's fairly easy after you learn a bit about it. Here is the library I use for this module.

You are completely right. I can't argue that "enabled-by-default" approach can lead to lots of security issues. That's why I am limiting the exposable pages only to selected templates. While the selector option is quite simple to implement I don't want to enable this kind of option because I believe it should not be this module's concern. The way I see it, if this module stays consistent and retrieves data only through $pages->find() api (or it's equivalent like $page->children(), $page->siblings() etc) that should give the user any type of control with the security. For example what you suggest could be achieved with a single hook. Say this is your template file where you expose your GraphQL api (something like /site/templates/graphql.php). <?php echo $modules->get('ProcessGraphQL')->executeGraphQL(); What you suggest could be achieved like this. <?php wire()->addHookAfter('Pages::find', function($event) { $event->return = $event->return->filter($mySecuritySelector); }); echo $modules->get('ProcessGraphQL')->executeGraphQL(); I would prefer users to approach security this way. This strategy to security gives full control for the user while allowing me to stick to a single rule when concerned about security and makes the code of the module much easier to reason about. I do realize that I could just insert the above code in the module and that's basically an implementation of what you suggest. But I don't want to encourage the user to solve security problems via module settings because no matter how hard I try, I won't be able to make this module dummy proof without limiting it's capabilities. Another thing I wanted to mention is that I see this module as a GraphQL representation of ProcessWire api. Like @Ivan Gretsky mentioned, if done right, this could allow us to build lot's of useful developer tools on top of this module. Even a mobile app that gives you limited site administration capabilities. But only if module is consistent with how ProcessWire behaves. And that includes the security of course. Oh no sir, not at all. I value your opinion very much. That's exactly what I wanted to hear from the community, opinions. I am thankful to you for mentioning this aspect of the module in it's early stage, before I started to implement other features that depend on it, like authentication or others that I might not think of right now.

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

You couldn't be more precise! GraphQL and ProcessWire fit each other very well. All this module does is just maps the ProcessWire's fieldtypes with GraphQL type system. It literally tells GraphQL that FieldtypeText is a StringType, FieldtypeDate is DateType and so on. And for getting the data, on average, it is less than a single line of code . Since you can access value of a page field like $pages->$fieldName all primitive fields inherit a method for accessing data from one place. I sure having lots of fun writing this module. I agree with Drupal "godfather" totally. The need for quick bootstrapping of an api service with flexible content structure is in very high demand. I had a hard time landing a job as a ProcessWire developer. So I target myself as a full-stack SPA developer in React.js/Node.js. I tried many of open source REST frameworks in Node.js that would help me get started with a project quickly. But non of them offered enough flexibility for my style of programming (I guess ProcessWire spoiled me ). At the time I figured out the best way to build REST api in Node.js I found out that REST is not flexible either. When an app starts evolving REST gets very messy. The Github built three versions of their REST api and still are not happy with it and now decided to release a GraphQL api which probably will not introduce breaking changes in the future, because GraphQL is designed that way. I think if made correctly, this module could bring a great value to many ProcessWire users. That's right. That is the main goal of this module. I will eventually implement all the features that needed to build a complete SPA with this module. I just try to move carefully and a usage feedback from community would help a lot. Just installing it and making couple queries to confirm that it works as expected would be great.

I always though graphql would only be for qraph databases, but really this looks damn rad.

If you haven't seen it already, check out the new Captain Hook panel in Tracy Debugger. If you have the Editor Protocol Handler configured you can jump straight to the hookable method in your code editor. Because the line links are generated from whatever PW version you are running it will always be correct. Pretty cool. Plus it includes the hookable methods in module classes!

I just updated the Captain Hook cheatseheet to latest version 3.x now there's a master and dev version. Thanks to @owzim for providing a cli script to parse the repos automaticly and generate a array to use. It helps a lot to update. https://somatonic.github.io/Captain-Hook/index.html

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 ).

Very useful! I use it in combination with opening hours. For this reason I have created a repeater with 7 repeats (one for each day). In this case it prevents the customer from deleting or draging a weekday from the repeater list.

@Robin S you're a man of no limits these days! Btw, what is that text from

Wonderful, thank you @Robin S - installed on 3.0.39 and all seems to be working perfectly. This kind of extra control over PageTable fields is something I find more need of the more I use this type of field.

Now everything works fine Here is a small video to demonstrate the ajax login process for others who are also interested in creating an similar login process. Finally I have decided to redirect to the same page instead to the profile page because I think it is much more comfortable for the user. The form will be loaded via ajax. All inputs (username, password) will be checked in real time against the database. If everything is correct, the user is able to click the button and the login process starts. After finishing the login process I use a get parameter in the url to show a success message. Best regards