Leaderboard

This latest version on the dev branch continues resolving GitHub issue reports as the last few versions have done. A new page finding capability has been added as well, and that's what we'll focus on in this post: https://processwire.com/blog/posts/processwire-3.0.91-core-updates/

I don't think it needs to be automatic, but perhaps the instructions could be expanded. Currently all they say is: "Create your processes then enter a path to the json or php definition of the fields in the path field." and that didn't initially make sense to me. I think spell it out: 1. Create a page under Admin (at the top level or under Setup if you prefer) 2. Save the page and then choose the ProcessSettingsFactory process from the dropdown. 3. Enter the path to youre settings file. Not sure using a placeholder is good the way you did - I actually thought it was already filled out with: settings/site-settings.php I also think you should say included "samples", not examples, because of the folder they are stored in. Hope that helps.

No, a form doesn't work that way. The way you have it set up now you have a single form with multiple submit buttons. It doesn't matter which submit button you click, the submitted form data will be the same. The thing is that the name of each post variable is determined by the name of the input element it corresponds to. Where you have multiple inputs with the same name (which you will have unless you rename them using something like what I suggested before) only the last input of each name will actually make it into post. Although you could change to having multiple forms (one for each grandchild page) I don't think the idea of multiple submit buttons is a good one. Where users see multiple fields from multiple pages in the same module interface the expectation will be that they can edit all of these fields at once. But in fact all changes they make besides those inside the form they click the submit button for will be lost. Users might not notice that which could cause problems, or they might notice it and report it to you as a bug. You don't really want either of those. A single form with a single submit button would be better, then you loop through the submitted form data and use the added page ID prefix to connect it to the relevant page. But remember you need to sanitize all the submitted data. It looks like you're sort of recreating ProcessPageEdit with your module here - have a look at ProcessPageEdit::processInput to get an idea of the kinds of things to look out for. If the action of your form points to your Process module page (which it will do by default unless you changed it) then all the post data will be accessible in the init() method of your module, as you are already trying. But as I said above, the array of data is in $this->input->post. You mentioned you have Tracy installed - so do... bd($this->input->post); ...in your init() method and you will see the post data you have available.

I think that integrity constraint violation definitely needs attention! But back to the issue at hand - have you tried using Tracy in Production mode to log the errors. When she emails, she only sends one until you clear the sent email flag, so your inbox won't be bombarded with repeat errors. Tracy also has Slack and Monolog adapters: https://componette.com/search/tracy available, but I guess it wouldn't be hard to write a Jira one if you prefer that.

Tried with FieldtypeMatrix; Works like a charm. Great addition for our intern site-search-functions!

Inspired by the "max megapixels" option for the client-side image resizer, I made a simple module that adds target megapixel resizing for Pageimages. Image Megapixels A module for ProcessWire CMS/CMF. Adds methods to Pageimage objects useful for resizing to a target megapixel value. Example use You are creating a lightbox gallery of images with different aspect ratios. For the enlargements, rather than setting a fixed maximum width or height you want all the enlargements have the same size in terms of area, allowing a panoramic image to be wider than a square image, for instance. Another use case is sizing a gallery of sponsor logos. The supplied logos are different aspect ratios but you need to ensure the logos are sized so each has equal prominence on the page. The effect of resizing three different aspect ratios by the same megapixel target value can be seen in the screenshot below: Installation Install the Image Megapixels module. API // basic usage $pageimage = $pageimage->megapixels(float $megapixels); // usage with all arguments $pageimage = $pageimage->megapixels(float $megapixels, array $options = []); Example: foreach($page->images as $image) { echo "<img src='$image->megapixels(0.8)->url' alt='$image->description'>" } If needed you can supply an array of options for Pageimage::size() as a second argument. Getting dimensions If you just want to get the height and width dimensions needed to size an image to the given number of megapixels you can use the Pageimage::megapixelsDimensions() method that this module also adds. It returns an array with width and height as keys. Example of how this could be used to output a gallery of logos: foreach($page->logos as $logo) { $dimensions = $logo->megapixelsDimensions(0.01); $width = $dimensions['width']; $height = $dimensions['height']; $width2x = $width * 2; $height2x = $height * 2; echo "<img src='{$logo->size($width, $height)->url}' srcset='{$logo->size($width, $height)->url} 1x, {$logo->size($width2x, $height2x)->url} 2x' alt='Logo' width='$width' height='$height'>"; } https://github.com/Toutouwai/ImageMegapixels https://processwire.com/modules/image-megapixels/

I recently started to build Vue SPAs with ProcessWire as the backend, connected with a REST API. Thanks to code and the help of @LostKobrakai (How to use FastRoute with ProcessWire) and @clsource (REST-Helper) I got it up and running pretty quickly and now have put all of it in a site profile for others to use. It includes the REST API with routing for different endpoints, JWT Auth and a simple Vue SPA which shows the process of logging in a user (nevertheless, you don't have to use the Vue part, the API will work on it's own). Check it out here: https://github.com/thomasaull/RestApiProfile I'm pretty sure, it's not the perfect or most sophisticsted solution, but it gets the job done for me… Feedback or Improvements are very welcome Update: This site profile is a module now: https://github.com/thomasaull/RestApi

You don't even need to do that If you have the Request Info panel running, you will see the POST variables automatically populated - depending on your scenario it might be in the main bar, or the "redirect" bar.,

I wasn't sure but after checking I can say that AOS supports additional fields added by Image Extra module

Maybe setup some simple rules with Zapier or IFTTT? Perhaps even post automated tickets to JIRA or some similar app? btw, the same error appeared earlier in the forums:

Thanks Teppo, looks great! The bugs I reported earlier were not fixed on these updates. That make me look more careful the server setup and the issue was that PW timezone was not the same that server was using - that caused history tab to work inproperly. Interesting thing is that the field specific compare/restore did work nicely even on bad configuration.

Hi All, Wonder if anybody can offer any advice on using PHPStorm and auto completion? I'm in a standard template file and if I type say $page-> and ask for some suggestions via Control-Space I get a 'no suggestions' tooltip. I've just learn't about the functions API which seem to autocomplete just fine. Just can't seem to get the variables based API working. Am I doing something wrong? I see Ryans .phpstorm.meta.php file in /wire/core and am thinking the 2nd section being noted about not working might be causing the problem? I'm still a little new to PHPStorm but the project all seems setup and working fine just not this part. I've attached mini screenshots what I see when trying to auto complete with both the functions API and the variables one. All the examples I come across seem to use the variables API and not the functions one, any big reason not to use it? I'm no PHP expert so I might not be understanding an obvious 'don't use scenario', be gentle lol Cheers All. ** A little addition, whilst the functions API is autocompleting for functions like children() and the template field 'title' If I add a custom field I don't see it in the autocomplete list? I'm not quite sure how PHPStorm can pull in those fields in the right context so I'm thinking my understanding is wrong on how this all works! Seems a shame to use an IDE with such strong code inspection etc for PHP and not be able to use it as much as possible in the template files **

Maybe increase script timeout too? PHP default is 30 seconds. Smaller video uploads work fine? Try enabling ZIP uploads for this field and see if that helps.

Can you describe in more detail what this means? Why can't you use tags for this? Sorting by filename is trivial "out of the box" with PW: $imgs = $page->images; foreach($imgs as $img) { $imageFileNames[] = $img->name; } sort($imageFileNames); echo '<pre>'; print_r($imageFileNames); echo '</pre>'; (assuming you need sorting in the frontend output). If you would add tags and / or descriptions you could build an associative array instead.

That's awesome news! A few quick questions though: Can these new find methods also be used with findMany() and $pages->findIDs() ? Can I use this with Pro Fields as well? e.g. if I have a text field in a Matrix Repeater, will these be also considered?

The bare bones are: $form = $this->modules->InputfieldForm; $parent = $this->pages(1234); // Get the parent page foreach($parent->children as $child) { if(!$child->hasChildren) continue; $fs_level_1 = $this->modules->InputfieldFieldset; $fs_level_1->label = $child->title; $fs_level_1->collapsed = Inputfield::collapsedYes; foreach($child->children as $grandchild) { $inputfields = $grandchild->getInputfields(); $fs_level_2 = $this->modules->InputfieldFieldset; $fs_level_2->label = $grandchild->title; $fs_level_2->collapsed = Inputfield::collapsedYes; $fs_level_2->add($inputfields); $fs_level_1->add($fs_level_2); } $form->add($fs_level_1); } // Add submit button or anything else here // ... return $form->render();

Preview of upcoming Media Manager Version 012 Better, cleaner, ProcessWire 3 UI! Custom columns (add custom fields to media templates; frontend access via API: e.g. $m->email; $m->body, etc) Edit media page directly Ajax update of Media Manager field on a page Disable media views centrally (e.g. manage only image media) Add extra images to image media field (e.g. front, back, top, side views, etc of an image) Better media previews More..... ETA: 3 - 5 weeks Early screenshots (some stuff subject to change)

Version 2.1.0 of VersionControl was just pushed to the 2.0 branch at GitHub. Note that this update changes the field-level UI quite a bit (see screenshot below). Personally I like this UI better anyway, but the main reason for the change was that it would've been a major pain to get the old UI to work with both the (current) default admin theme and AdminThemeUikit – let alone any third party admin themes. The colour theme is currently hardcoded, so it doesn't adapt to whatever changes you might've made to your admin theme. It's also exactly the same for both built-in admin themes. I could make some parts configurable at some point, but for the time being this is better than nothing. Next up: more testing. I'm pretty sure that there are a few bugs here and there that I've managed to miss, and I'd like the core features of this module to be as solid as possible. I'm also contemplating giving the History tab a major facelift, but that's not exactly the first item on my list right now

Sudanese Radio Website : http://hala96.com/

By strange coincidence, I was just thinking that maybe PW should have a standard EditorConfig file as part of the suite. Whilst it does not address all of the code styling issues raised above, it would allow us to all get the tabs/spaces/line endings/whitespace trimming right for this project by just using an editor that either supports EditorConfig out of the box, or via a plugin. I've started using it on my current project and it seems to work quite well.

A stock PW3 installation should actually be faster than PW2 – it certainly is on all of my installations. There's a lot more optimization in PW3 than in PW2. If that's not what you are seeing, then it's time to start looking for where the bottleneck is. PW3 does not have more significant overhead than PW2 except when it is compiling a file for the first time. The 30% increase numbers mentioned above sound to me like that is a request where PW is compiling a file. You can expect a request where it has to re-compile a file to take longer. But it only has to do that once, when a file changes and needs to be re-compiled. Maybe that's a common occurrence on a dev site, but should be a rare one on a production site. I'm measuring here with Chrome dev tools, ProfilerPro and my own timers using the Debug class. What tool are you guys using to measure times, and in what quantity? Before deciding something is PW3 related, I really suggest testing with a basic/blank profile without other modules installed. If you are consistently seeing any kind of increase in render times under PW3, my guess would be that something is getting recompiled on every request for some reason or another, or that there is another module involved that runs slower under PW3 for some reason. Edit--A few things to add: Debug mode is going to be slower in PW3 than in PW2, simply because PW3 is tracking a lot more stuff than PW2 did. With debug mode off there should be no difference though. Keep in mind debug mode is for development, and not something you should ever leave enabled on a production site. PW3 is more efficient with resources than PW2. PW3's boot time (stuff it does before executing your template file) is 20% to 45% faster in my testing. PW3 executes 20% to 25% fewer queries as part of the boot, and loads up to 50% fewer pages. Autoload modules become part of the boot process, so I test with no 3rd party modules installed. The file compiler can potentially add a little bit of overhead even when it doesn't need to compile, because it has to determine whether something needs compilation. But on a default site profile we're talking about maybe 10ms at the most here. If you turn off the template compiler, then that overhead is gone. While PW3 uses fewer resources on the database side, but sometimes more resources on the file system side. If you've got a slow file system, you might notice it more in PW3 than in PW2. For those of you seeing PW3 to be slower than PW2, if it's determined that 3rd party modules are not a factor, I would be curious what's happening in the template files. Perhaps there is a bottleneck in a certain API call or something that we're not aware of yet. It would be interesting to see the results of profiling the API calls in your template files using ProfilerPro or Debug::timer() calls. Mostly specific to Soma: PW2 and PW3 are identical in terms of how they use joins and indexes. Regardless of version, PW will use as many joins as it takes to execute the selector you give it. Just like you can create complex or inefficient SQL queries you can also create equally inefficient $pages->find() calls if you aren't being careful. Using PW's API doesn't mean you are somehow bypassing the database. Your find() queries still become SQL queries. So if you are working on big and complex projects, then you need to watch and profile your work. When you a come across a complex find() operation that is expensive, refactor it to be simpler or break it down into smaller parts. Pay attention to how many pages you load in memory at once. Don't use find() and children() calls without "limit" selectors when dealing with potentially large sets. With regard to indexing, PW logically indexes all the columns that are likely to be used in find() operations, but if you are querying columns in a table have no index for whatever reason (3rd party module that forgot an index, or column not commonly used for queries), you may need to add one. Most of us never need to do this, but since you mentioned "big and complex" you may be in the territory where you have to apply more consideration to these things.

I think you can simply deinstall Session Login Throttle module.