Leaderboard

I'd planned on writing up a blog post today and bumping the PW version up to 3.0.125, but working on documentation pages ended up taking up most of the day. My hands are getting a bit tired from all the writing, so I'll keep this post short. ? I'll have a more formal post with more on the 3.0.125 version next week. People have been asking for more information on the various ProcessWire API access methods, as well as more information on the Functions API. I've written up a new documentation page that covers all the details. Though it's become a bit long, so next week I might split off the Functions API part into a separate child page. But for now, this is what I've got—the new documentation page is located here: https://processwire.com/docs/start/api-access/ In addition, the ProcessWire API Explorer module has been updated to support documentation for ProcessWire's procedural functions this week. And as a result, our online API documentation page now covers them all too. I spiffed up the phpdoc on all of them (and in some cases re-wrote the content) in preparation for that. For those that were asking for more documentation on the API functions, this page also has a section dedicated for those. Here's a direct link to our more than 50 procedural functions available in PW that previously didn't have any online documentation: https://processwire.com/api/ref/functions/

Ryan - thanks for all the work on those docs. I'm afraid my concerns around mixing approaches in the examples on the homepage still stand, but it's definitely great having the differences / pros / cons documented, even if a little verbosely at the moment. I am kinda curious why the procedural functions are documented now. Perhaps there are still several that don't have object oriented versions, but I guess for consistency I'd rather see them all have an OO version available and make it clear that those are the primary methods to use. Or do you find yourself using the procedural versions in certain situations still? Could you please document when you would use these over their OO versions?

I actually like the verbose style for this type of documentation. Ryan has significantly filled in the gaps of missing centrally located documentation. There's much to read now. I find that better to have than the typical documentation that is full of bullet points. I truly hope he continues along this path because I believe it helps everyone in learning the more technical parts of ProcessWire. I also like that community members are actively asking to contribute to making the documentation meaningful. The active positivity of community members and the quality of thoughtful or extremely helpful answers given are what makes being on this forum truly unique.

The first bullet point seemed to answer my question from the previous thread: module's can't add features to the Functions API, it's immutable in that regard. The second bullet point, on the other hand, seems to contradict the first one: module developers can indeed create new functions for API variables, effectively adding to the Functions API – even if behind the scenes the implementation isn't identical. It might be worthwhile clarifying the wording here a bit, I at least found this part confusing. Leaving the "it's a very specific list of functions that doesn't change" part out and perhaps adding "By default" before "Only those that are likely" would be an improvement – unless I'm misunderstanding the whole thing? Also, a table of contents would be really nice for these longer pages. --- Overall I think it's great that there's now documentation for a lot of stuff that was completely missing before. I do agree with @adrian in that the new documentation is a bit verbose, though. It's a lot to browse if I simply want to get the facts. My own writing style tends to be extremely verbose, so I should know ? @ryan, would be possible to allow others to somehow make suggestions to the content of the site (and particularly docs) without having to open a new issue for every suggestion? It'd be amazing if we could somehow make some kind of change suggestions and submit them directly via the site, perhaps publicly – or at least for a limited group of volunteer editors. Trust me, I do realise that keeping everything up to date, managing the core, writing weekly posts, and whatnot must be an unbelievably time-consuming job. Just looking for ways the community could perhaps participate.

I'm really in love with FormBuilder, but the one thing missing to match all my end users' expectations were repeatable field groups. Think repeaters, in ProcessWire terms. Our primary application of PW is our corporate intranet, so "lines" of fields are quite common in the forms I build. We have all kinds of request forms where the information for a varying number of colleagues needs to be entered (from meal order to flight booking request) and where it is simply impractical to send a form for each, and I don't want to clutter my forms with multiple instances of fields that may only get used ten percent of the time. That's why I started to build FormBuilderMultiplier (link to GitHub). What it does: Adds an option to make a regular Fieldgroup repeatable Lets you limit the number of instances of a Fieldgroup on the form Adds an "Add row" button the form that adds another instance of the Fieldgroup's fields Adds a counter suffix at the end of every affected field's label Stores the entered values just like regular fields Makes the entered values available in preview and email notifications Supports most text based fields, textareas and selects (really, I haven't had enough time to test all the available choices yet) What it doesn't do (yet): Support saving to ProcessWire pages (i.e. real Repeaters) I haven't tested all the validation stuff, Date/Time inputs etc. yet, but since I'm utterly swamped with other stuff at work, I didn't want to wait until I have it polished. Any feedback is welcome. There might also be some issues with different output frameworks that I haven't encountered yet. The forms I work with mostly use UIKit. Status: Still alpha, so test well before using it in the field. Known issues: When rows are added, the form's iframe needs to be resized, which isn't completely clean yet. How it works: The Fieldgroup settings are added through regular hooks, as is the logic that adds the necessary field copies for processing the form and displaying previews. "Multiplied" field instances are suffixed with _NUM, where NUM is an incremental integer starting from 1. So if you have add two fields named "surname" and "givenname" to a fieldgroup and check the "multiply" checkbox, the form will initially have "surname_1" and "givenname_1" field (I'm still considering changing that to make the risk to shoot oneself into the foot by having a regular "surname_1" field somewhere else in the form less likely). When a "row" is added, the first row is cloned through JS and the counter in the fields' IDs, names and "for" attributes as well as the counter in the label are incremented before appending the copies to the Fieldset container in the form. To keep backend and frontend in sync, a hidden field named [name of the fieldset]__multiplier_rows is added to the form. Both the backend and the frontend script use this to store and retrieve the number of "rows". ToDo: Naturally, add the option to store the data in real repeaters when saving to pages. Do a lot of testing (and likely fixing). Make a few things (like the "Add row" button label etc.) configurable in field(set) context. Add a smooth API to retrieve the multiplied values as WireArrays. The mandatory moving screenshot:

I also re-read this thread and found out why i had to do the custom method to get the sender domain; However, the module does have the ability to change the sending domain on the fly, but it was not working at all when i posted the comment below; this could take some testing to figure out if the added method is necessary, or will be fixed once the send method observes all of the overrides. Just tested and it is working now, and i'm able to override the sending domain upon instantiation of the mail, therefore the mods i posted above are not necessary; The new version I forked on GH only has the 1 change, which is the commenting out of the send alias. ----- this is the fork: https://github.com/outflux3/WireMailMailgun and i guess once all of the changes are made and it is tested, we could try and see about getting this one switched on the modules directory. For @adrian's dilemma, i think the easiest thing would be to have a setting in the module config that when clicked causes the module to not include the public send() method; so the config value is checked and then we include that method from an external file, unless there is a better way. So anyone upgrading would keep the same functionality as before, but can elect to check the box to "remove the public send() " or something like that.

Ryan, thanks for the update. It would be great to get an update of "Selectors as regular and associative arrays".

Here is a more sophisticated version if you have a large number of siblings and don't want to include all of them in the pager navigation. <?php // Limit for number of sibling links $limit = 9; // Get the number of visible siblings $num_siblings = $page->parent->numChildren(true); // The default start value is zero $start = 0; // If the number of siblings is greater than the limit then we need to adjust the start value if($num_siblings > $limit) { // Get the halfway point of the limit $half_limit = floor($limit / 2); // Get the index of the current page relative to its siblings $index = $page->index(); // Adjust the start value to keep the current page within the sibling links if($index > $half_limit) $start = $index - $half_limit; if($num_siblings - $start < $limit) $start = $num_siblings - $limit; } $items = $page->siblings("start=$start, limit=$limit"); // Next page and previous page relative to current page $next_page = $page->next(); $prev_page = $page->prev(); ?> <?php if($items->count > 1): ?> <ul> <?php if($prev_page->id): ?> <li><a href="<?= $prev_page->url ?>">Previous</a></li> <?php endif; ?> <?php if($start > 0): ?> <li>&hellip;</li> <?php endif; ?> <?php foreach($items as $item): ?> <li class="<?= $page === $item ? 'current' : '' ?>"><a href="<?= $item->url ?>"><?= $item->index() + 1 ?></a></li> <?php endforeach; ?> <?php if($num_siblings > $start + $limit): ?> <li>&hellip;</li> <?php endif; ?> <?php if($next_page->id): ?> <li><a href="<?= $next_page->url ?>">Next</a></li> <?php endif; ?> </ul> <?php endif; ?>

@teppo AAH! I can't believe I wasted so much time looking into namespaces and scope context yesterday!!! How embarrassing. Thank you.

Info: All new features and download link will be updated in the first post.

Sure, i don't see any reason I couldn't maintain the module; I think it is basically stable and we'd just need to all contribute our changes, test it and then it should be good to go... I'll try and get that setup soon..

New version committed and it is now named Admin Tools.

@Soma Yeah this is my issue with Vue.JS - I use Vue.JS often for two way data-binding which is amazing to be able to easily update content and do visual changes to the site based on those updates. For example adding something to a basket. It's much easier with Vue than jQuery or JavaScript. My issue with Vue is exactly that. You can use it just on a component basis or you can use it to render your entire UI. To me it just doesn't make sense to use it to render an entire UI with a website. A web app sure, but a website it's often overkill and introduces that exact problem. You can introduce server side rendering of Vue with Nuxt but then it just seems like another layer of 'over complication'. I personally stopped using Vue for websites unless I absolutely needed two way binding. It just didn't make sense and the extra complication of implementing it such as having to convert everything from ProcessWire into a JSON feed. EDIT: Noticed this post still gets likes, so what's changed since then? AlpineJS. AlpineJS is a solution to this exact problem, worth a look for anyone wanting to do some cool UI stuff without including all of Vue features and overhead.

I'm a little embarrassed to admit that after several years of working in PW I still don't "get" output formatting in the context of saving pages and fields. I understand that when I get the value of a field it is automatically formatted when output formatting is on, and that I can switch this off to get the unformatted value. What I don't understand is why I need to turn off output formatting when I am saving a new value to a page. It's output formatting, not input formatting, right? Even more befuddling to me is the fact that this often results in a fatal error if I forget to do it, crashing my site. I also have to remember to turn it back on again afterwords, or else I can introduce security flaws into my code. I'm sure Ryan must have a reason for requiring switching output formatting off when doing a save, but if this is so important and is always required, why isn't it just baked right into the save() method? I know the new setAndSave() method now does this for individual fields. It would be great to have a similar method when saving an entire Page.

I was just looking through the Pages::save method and it does appear that PW automatically turns off outputFormatting before it saves the fields. So I think I understand now what's happening here a little better. It's true that outputFormatting has nothing to do with input. However, a Page object will apply outputFormatting when you call one of its fields (properties), even if the field has never been saved to the database. When a page object is later saved, the save() function loops through each field and writes it to the database. In other words, it gets its output. So outputFormatting must be turned off when it does this or it will not save the value that you actually input. So that makes sense. But I still don't understand why PW requires ME to set of(false) if the save() method already does this. Because I very rarely need to retrieve a value from a field, modify it, and set it again. So I would appreciate it if PW didn't crash in the cases where I just want to save a new value... Edit: Also, in those cases where I do need to retrieve an unformatted value, I would prefer if I could specifically use $page->getUnformatted('field_name'), modify the value, and then do $page->field_name = '$modifiedValue' and $page->save() instead of having to store the current state of of(), turn it off, and then restore the previous state.

Hey all, I've converted the ProcessWire 2.3 rules to Nginx. Hope this will help some people Greetings, Niek server { listen 80; listen 443 ssl; root /var/www/example.com/public_html; server_name example.com www.example.com; ssl_certificate /etc/pki/tls/certs/example.com.crt; ssl_certificate_key /etc/pki/tls/private/example.com.key; client_max_body_size 50m; access_log /var/www/example.com/_logs/access.log; error_log /var/www/example.com/_logs/error.log; # ----------------------------------------------------------------------------------------------- # Set default directory index files # ----------------------------------------------------------------------------------------------- index index.php index.html index.htm; # ----------------------------------------------------------------------------------------------- # Optional: Redirect users to the 'www.' version of the site (uncomment to enable). # For example: http://processwire.com/ would be redirected to http://www.processwire.com/ # ----------------------------------------------------------------------------------------------- if ($host !~* ^www\.) { rewrite ^(.*)$ $scheme://www.$host$1 permanent; } # ----------------------------------------------------------------------------------------------- # Access Restrictions: Protect ProcessWire system files # ----------------------------------------------------------------------------------------------- # Block access to ProcessWire system files location ~ \.(inc|info|module|sh|sql)$ { deny all; } # Block access to any file or directory that begins with a period location ~ /\. { deny all; } # Block access to protected assets directories location ~ ^/(site|site-[^/]+)/assets/(cache|logs|backups|sessions|config|install|tmp)($|/.*$) { deny all; } # Block acceess to the /site/install/ directory location ~ ^/(site|site-[^/]+)/install($|/.*$) { deny all; } # Block dirs in /site/assets/ dirs that start with a hyphen location ~ ^/(site|site-[^/]+)/assets.*/-.+/.* { deny all; } # Block access to /wire/config.php, /site/config.php, /site/config-dev.php, and /wire/index.config.php location ~ ^/(wire|site|site-[^/]+)/(config|index\.config|config-dev)\.php$ { deny all; } # Block access to any PHP-based files in /templates-admin/ location ~ ^/(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP or markup files in /site/templates/ location ~ ^/(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ { deny all; } # Block access to any PHP files in /site/assets/ location ~ ^/(site|site-[^/]+)/assets($|/|/.*\.php)$ { deny all; } # Block access to any PHP files in core or core module directories location ~ ^/wire/(core|modules)/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any PHP files in /site/modules/ location ~ ^/(site|site-[^/]+)/modules/.*\.(php|inc|tpl|module)$ { deny all; } # Block access to any software identifying txt files location ~ ^/(COPYRIGHT|INSTALL|README|htaccess)\.(txt|md)$ { deny all; } # Block all http access to the default/uninstalled site-default directory location ~ ^/site-default/ { deny all; } # ----------------------------------------------------------------------------------------------- # If the request is for a static file, then set expires header and disable logging. # Give control to ProcessWire if the requested file or directory is non-existing. # ----------------------------------------------------------------------------------------------- location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|eot|woff|ttf)$ { expires 24h; log_not_found off; access_log off; try_files $uri $uri/ /index.php?it=$uri&$args; } # ----------------------------------------------------------------------------------------------- # This location processes all other requests. If the request is for a file or directory that # physically exists on the server, then load the file. Else give control to ProcessWire. # ----------------------------------------------------------------------------------------------- location / { try_files $uri $uri/ /index.php?it=$uri&$args; } # ----------------------------------------------------------------------------------------------- # Pass .php requests to fastcgi socket # ----------------------------------------------------------------------------------------------- location ~ \.php$ { # Check if the requested PHP file actually exists for security try_files $uri =404; # Fix for server variables that behave differently under nginx/php-fpm than typically expected fastcgi_split_path_info ^(.+\.php)(/.+)$; # Set environment variables include fastcgi_params; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # Pass request to php-fpm fastcgi socket fastcgi_pass unix:/var/run/example.com_fpm.sock; } }