Leaderboard

Hi Folks, We've soft launched a client's site, https://canadia.ie Short summary of ingredients: UIKit based UI Some Vue.js sprinkles: Axios, GrahpQl, lot of methods for the product filtering Usual arsenal of PW modules like AOIM, AllInOneSeo, AutoSmush LeafletMaps, etc DO Server + a new tool 'RunCloud' to handle server config and the time consuming bits like SSL, DB setup etc Considering we only rolled to production today for the soft launch the site is very fast - especially filtering products, it's by far running 20x faster than the staging server. I'll post a more detailed update once we have finished fine tuning and installing any other post production modules.

Go to Modules > Core > AdminThemeUiKit. You can choose the Gravatar option or you can edit the user template to add an images field which can be used for manually added images. Remember that the user template is a system template so you need to go to Setup > Templates > Filters > Show System Templates.

Hey Ralf, yes this is possible. You have to assign the permission "page-edit-created" to a role, for example "editor". With this permission a user with this role is only able to edit his own created entries. And there is an additional permission "page-edit-trash-created" that allows users to trash pages they created themself.

This is an interesting thought. My opinion has always been: teach a man/woman to fish = pw core and API (basically, /wire/) man/woman fishing = /site/ So, modules, or as others call them, custom plugins, are exactly where the fishing should be happening. I don't find it at all WordPressy since ProcessWire's (custom) modules, unlike WordPress's, are not the cobbling together of disparate things to provide a solution to a problem that should have fundamentally been resolved by the core. Agreed, but therein also lies the beauty of reusability. If I find myself building blogs with every/most sites that I build, it makes sense to package the blog solution. In other words, modules ?. The point about second-guessing what fields a user needs is a good one, but it is not one without a solution. This is easily solved (again, back to blog module) by a 2-step installer that asks what fields the user needs. We also have Fields like Table and DynamicSelects that allow you to add/remove fields/columns even post-install.

Seems like we're talking about a couple of different things here: 1. Making certain "things" (don't think I can be more specific than that) reusable in multiple projects that you work on now and in the future. These are for in-house use by a single developer or team of developers and not shared publicly with the PW community (in the modules directory for instance). You could try and use modules for this purpose (I think this is what @bernhard is interested in) or any number of other approaches. This is stuff that's very much down to individual workflow preferences and I don't think the PW core can provide easy solutions that are going to suit everyone. 2. Modules that are shared publicly with the PW community. This is totally a matter of opinion, but personally I'm not enthusiastic about things like sliders and blogs being packaged and distributed as modules. In seems very WordPressy and not really the PW way (teach a man to fish, etc). A module could provide some building block that is useful for making a slider or a blog but it shouldn't do things like try and anticipate all the fields a user needs, output all the markup, bundle third-party JS libraries and suchlike. The beauty of PW is that it's so quick and easy to build solutions that are exactly tailored to the project at hand with nothing unnecessary left lying around. And while developing these solutions you're always learning how to be a better developer. A plug-and-play module that outputs whole pieces of the website works against that IMHO.

You seem to be confusing Fieldsets and Fieldgroups. They are very different things. Fieldsets are special fields to help you group fields together for the purposes of how they are displayed on a page during edit. In a sense, they group the Inputfields of the fields within the Fieldset. Each Fieldset is then displayed in its own tab during page edit. As usual though, the order or even the presence of fields on a page have no bearing on their appearance in the frontend. Back to the main question, I quote the definitions of Fields, Fieldgroups and Templates as per the docs:? Fields That just means a database table, that is created via ProcessWire using a defined schema and installed as a module. You can read more about them here. Fieldgroups You will rarely have to interact directly with Fieldgroups. Each template you create has a corresponding Fieldgroup. A Fieldgroup just says these are the fields available in this template. Hence, it is possible to reuse a field across different templates (i.e. across different Fieldgroups). More about them here. Templates This one is self-explanatory, me thinks ?. More about them here.

There is no method call on the repeater matrix field value there - I think you meant to include ->find(): $items = $page->matrix_slider->find('start=1,limit=3'); That should work.

You can use: $input->post('reset-button') or $input->post->{'reset-button'} This is not a PW issue, but rather a PHP one - you just can't use hyphens like that. That is why PW field names use underscores and not hyphens.

Hello Adrian!!! Thank you very much for your answer! Now I get it!!! Processwire has the best forum ever!!! Thank you so much!

Try to use slice() $matrix = $pages->get(11203)->my_matrix; $items = $matrix->slice(1, 3);

Finally ?? Thank you adrian for this awesome tool and your great support in the forum!

It's great to see a government agency using Processwire. Here across the Tasman, I think Silverstripe has been mandated as the government CMS of choice which is sort of ok in some respects, but it's a lot more complex than it needs to be for many projects.

You can render the comments list and comment form for another page by calling render() and renderForm() on the value of the comments field of that other page. For example: // Get the page $p = $pages(1234); // Render comments list echo $p->comments->render(); // Render comment form echo $p->comments->renderForm(); If you have the "Redirect after comment post?" option checked then the user will be redirected to the page being commented on after the form is submitted. You probably don't want that so you could adjust the value of the hidden page_id field in the comment form. Unfortunately there's not much that's hookable in the FieldtypeComments module so you'd have to do this by editing CommentForm.php (first copy the FieldtypeComments module to /site/modules/) or use Javascript to change the field value. Alternatively you could disable the built-in redirect option and handle redirection after form submission via your own code.

A couple of months ago we launched our very first PW site, which was just a very small site concerning a conference taking place in 2020. Last week we launched our second site, and it was a much bigger project - https://jobs.antarctica.gov.au/. Our jobs (both in Antarctica and within Australia) were previously a part of our main site at http://www.antarctica.gov.au (which is yet to be redesigned and moved into PW), so we were tasked with creating a brand new site in time for the recruitment season opening in early December. While the timeframe was tight (we only had about a month to build it), it was great to be able to work within PW, and then to introduce our editors to it. They love it in comparison to our old CMS (as do we!).

Thx @Robin S, interesting points. As always it's not black/white - the question is how far one can/should go in terms of packing things into a module vs. building it from scratch all the time via the API. IMHO there are standard things like blogs, forum, sliders, guestbook etc. that are not that easy and quickly to create with PW and therefore cost a lot of time and money on my end. I wished I had more reusable products for such tasks. And I'm working on it. On the other hand I love the freedom of PW. But I think both worlds can live well together in our universe. And that might be another argument for using regular fields over custom fieldtypes @kongondo: When using regular fields, the user can easily customize those templates to their very own needs. Imagine a blog module that ships with fields blog_title blog_date blog_content blog_gallery If the user needed a field to store files he could either create a PR with an update script (again both migrations and export/import would not work) or create this single field on his own and just use it for himself. This would not be that easy if those 4 fields where wrapped in a single custom blog fieldtype (that would be the WordPress way of a plugin). Do you understand what I'm trying to say? ? Not trying to convice anybody here - just enjoying to get valuable input as this is in my head for quite a long time...

I don't think that this is a special case at all. Imagine a slider module that could help us to create an image slider for our websites. It could create the markup (maybe let the user choose the css framework) and it could also create the necessary fields in the admin and add those fields to the templates that should display a slider. I've had lots of those situations finding myself copying and pasting code snippets from one site to another. Finding a bug in one page, having to fix it in all my sites manually etc etc. Now, that's what I call messy ? If we had a proper API that made those tasks easy, I think we would get a lot more reusable modules just like the SEO module, because then it would be a lot easier to create such modules and push fixes, changes or updates. And upgrading existing projects would only be one click (or git pull). Agree! I've learned a lot from your modules. But I still think the API need one abstraction layer on top of that. See for example how hard it is to edit a field in template context: https://processwire.com/talk/topic/6656-change-field-description-in-context-via-api/ It should be somethink like this, imho: $api->editInTemplateContext('mytemplate', function($field) { $field->label = 'Custom label for mytemplate'; }); The migrations module offers some of those helpers. It's one step. But there is at least one more step missing...

I agree, and this is a situation I've encountered. I just do what can be done with JSON, the rest I do using other API, as an after-step. I beg to differ. I don't get the point about being messy. If you have an installer and an uninstaller, that covers the job. The blog module, for instance, needs to store preferences data somewhere. Whether these are stored as data in a field on a page, or in the modules config, they all end up in the database and are transparent to the user. Storing such preferences in a file (I'm not saying that is what you are suggesting) seems inefficient to me and prone to error, i/o. I don't think this is a problem at all. You always remove templates first (after deleting your pages, of course). It doesn't matter if it has fields, using the API, the template will be removed. You then delete the fields you installed. Coupled with clear documentation and a big warning sign on the module's config page, there shouldn't be any cause for confusion. This is how I do it in all my bigger modules. In addition, my uninstall routines do not automatically remove the fields and templates created by the module. Instead, there is a cleanup page accessible only to superusers. If they hit 'remove' having read the warnings, it means they know what they are doing. I'd love to hear your opinions regarding storage of module data, though.

It's not the same. On the 2nd command the result for you is test_a.png and for me test.png.

Sometimes a module does need to create fields, templates and pages but it would be the exception rather than the rule. Most Process modules, even complex ones with multiple (pseudo) sub-pages such as Admin Actions, do not create fields, templates or pages other than the single page used to execute the Process. Instead they use multiple execute() methods that work via URL segments. The forms on those pseudo sub-pages don't save data to PW fields but save all the module-related data to the module's config (stored as JSON in a single field in the database). The "nav" array in the module info takes care of creating the navigation to sub-pages. But perhaps you already know this if you've studied ProcessHello and other Process modules. Some off-the-top-of-my-head cases where you probably would need real fields/templates/pages for a module: You want to store files or images for use with the module. You want to use a Repeater and don't want the extra work to create to repeatable input type in the Process module. You want to store a larger amount of data than is allowed for in the TEXT column type used for module config data (although alternatively your module could create a dedicated table to store its data).

I guess @Gadgetto is talking about how to create/edit/remove/move/etc fields/templates/pages/etc. when they are necessary for an installable and reusable module? Then pages import/export is no option. You can have a look here how you can do that: https://github.com/nicoknoll/MarkupSEO/blob/master/MarkupSEO.module#L971-L1095

Hi, sorry not too much time, I think you could use/play with the in-built export/import feature : by @horst Code to read: https://github.com/processwire/processwire/blob/dev/wire/core/PagesExportImport.php Have fun !

Hmmm, there is a new action for PageListerPro (https://processwire.com/blog/posts/processwire-3.0.121-core-updates-and-more/).

Noticed the button today, and donated directly ? Thanks again @adrian

It ignores the "Character replacements" from the InputfieldPageName module and on repeaters it replaces "Character replacements" and HTML entities with underscores. Please remove that update. The 1.2.2 version does the job perfect.

Yep, good catch - please try the latest version.

Can you completely remove the HTML entities? For example if on the text field I write: "Test" then the file will be renamed to: quot-test-quot.jpg instead of test.jpg.

RockFinder v1.1.0 now supports filters. This makes it possible to use custom access control (eg showing only certain rows on a RockGrid): https://github.com/BernhardBaumrock/RockFinder/commit/3e4daae0f283280672ab606a1eef1b16497f19fe https://github.com/BernhardBaumrock/RockFinder/blob/3e4daae0f283280672ab606a1eef1b16497f19fe/readme.md#filters--access-control Filters & Access Control You can filter the resulting rows by custom callbacks: // show only rows that have an id > 3 $finder = new RockFinder('id>0, limit=5', ['title', 'status']); $finder->filter(function($row) { return $row->id > 3; }); You can also use these filters for showing only editable pages by the current user. Be careful! This will load pages into memory and you will lose the performance benefits of RockFinder / direct SQL queries. $finder->filter(function($row) { $page = $this->wire->pages->get($row->id); return $page->editable(); }); One thing to mention is that you can apply these filters BEFORE or AFTER closures have been applied. If you apply them BEFORE executing the closures it might be a little more performant (because closures will not be executed for rows that have been removed by the filter), but you will not have access to columns that are populated via closures (like page path).

@horst thanks for confirming! And: oughta check the modules directory more frequently. A horn of plenty! ?

@Ralf Which PHP version are you using? "self::new" is a syntax that threw an error prior to PHP 7. Since PW minimum requirements is PHP 5.3 it is a bug introduced in version 3.0.117. Like @adrian said, reverting to 3.0.116 or upgrading to PHP >=7.0 should fix it. Anyway, I would also like to use this comment to continue a discussion that started in the comments sections of the blog post about the newly introduced WireArray::new() static method. I posted a pretty long comment about that which never got published. (As a side node, that is highly frustrating, taking into account I took quite some time researching background information to the comment I made. So here is going to be a shorter version of that post) The discussion started with @teppo and @bernhard asking, why a new concept of WireArray::new() was introduced to initialise a new WireArray with data. More intuitive would be if you could just initialise it using new WireArray() and pass your data to the constructor. That's how it works for most other objects in ProcessWire too. To that @ryan replied: Now, I do understand why this is necessary, but just like Teppo and Bernhard I'm not 100% happy with it. It seems like a small thing we shouldn't care too much about, but I came to love ProcessWire because I usually do things I learned them using plain PHP and most of the time they just work the way I expect it. This new WireArray::new syntax is something I would intuitevly do wrong, then wonder why it doesn't work, then search the documentation, and finally ask myself, why I can't just use new WireArray(). And that's a workflow that's slowing me as a developer down, a workflow I'm accustomed to from Wordpress, not from ProcessWire. So although it doesn't seem like a big thing, is there a chance we could make new WireArray() work for initialising WireArray objects with data? As far as I could see there are four classes derived from WireArray and implementing their own constructor. Would it be possible to refactor those?

@Ralf - I would recommend installing 3.0.116 for the moment. It looks like this is not the only bug introduced in 3.0.117 - the Profields Table field is also throwing warnings that need attention. Note that there is no 3.0.118 yet

Try: $rep = $ref->repeater_field->get(1222); It should get the you the repeater item with ID 1222. This is a RepeaterPage which is pretty much a normal Page object. I don't have very clear how you know which repeater item you want to edit and where are you getting the data that is meant to be set on the repeater items. Every repeater field is an array of pages, where you can also use the find/get methods to match pages through selectors. Also, every repeater Item can have it's fields set and saved pretty much the same as normal pages.

Just some explanation because it is interesting... This isn't something that is specific to Repeaters - it applies to any selector used on a PageArray/WireArray (a Repeater field returns a PageArray). When you do $some_pagearray->find() this is different to a $pages->find() - the method name is the same but they are actually totally different methods. See find() method in the PageFinder class vs the WireArray class. When using $pages->find() the method refers back to the fieldtype for each queried field and the fieldtypes can do some special preparation to the queried value. In the case of a Datetime field the value is passed through strtotime() if it is a string. So this allows "today" to be converted to a timestamp. But when using $some_pagearray->find() this process does not happen, so the queried value must be a timestamp. Another gotcha to watch out for is using the page status as a string in a selector. With $pages->find() you can do something like "status!=hidden" but this won't work with a selector in $some_pagearray->find(). I think it would be nice if things like this did work with PageArrays - there is an open request for it.

u can.do theis too function starwar() { extract(wire('all')->getArray()); echo "may.the be force.wit u $user->name and alsos.wit $page->path"; }