Leaderboard

You should not use "post" but "get" for a searchform. This way it's not trying to resubmit the form. The design pattern when using "post" for Forms usually is PRG https://en.wikipedia.org/wiki/Post/Redirect/Get

I'd leave the title field as is. Names (urls) are generated from the title when you create a page. If your pages are live, then better leave the title as is. How many? This affects how you should run the script below Not a great idea! No need for html here. This is a better way IMO That's why we have the API :-). See script below. TEST BEFORE USE IN PRODUCTION SITE! Log in as superuser Copy and paste the following code into a template file, maybe the one used by your home page. Visit a page using the template in #2 Check if things went OK Delete code from template file when done If you have lots of project pages, make use of the start and limit parameters. /** * Copy title field contents to a specified text field on the same page. * * @param string $fieldName Name of the field to edit. * @param string $templateName Name of the template file whose pages we are editing. * @param integer $start Start of $pages->find(). * @param integer $limit Limit of $pages->find(). * @return void */ function generateDisplayTitle($fieldName, $templateName, $start=0, $limit=10) { // only superusers allowed! if(!wire('user')->isSuperuser()) return; // fetch a limited number of pages $editPages = wire('pages')->find("template=$templateName,start=$start,limit=$limit"); # we found pages if($editPages->count) { foreach ($editPages as $editPage) { $editPage->{$fieldName} = $editPage->title; $editPage->of(false); $editPage->save($fieldName); $editPage->of(true); } } } // call the function - here, we start at index 2 and limit to 3 pages // the field we want to copy content to is called 'display_title' // the template of the pages we want is 'projects' generateDisplayTitle('display_title', 'projects', 2,3); # not many pages use (i.e. do all) #generateDisplayTitle('display_title', 'projects');

New version committed that adds a Maximize button to the Console panel as a whole which results in a fullscreen editing and review experience. Thanks to @tpr for his usual tweaks to my styling :) I also added the regular fullscreen/halfscreen buttons to the Dumps and Dumps Recorder panels. These buttons are on several panels where the content can be quite large - they should have been on these panels all the time really. Let me know if you have any issues with any of this - hopefully it should make things easier to work with.

Hey @pwired The point is that when you do this ... <ul> <?php foreach ($pages->find("template=news-item, limit=5, sort=created") as $item): ?> <li><a href="<?= $item->url ?>"><?= $item->title ?></a></li> <?php endforeach; ?> </ul> ... it looks a bit cleaner (as in "less like code mixed with markup") than doing something like this: <ul> <?php foreach ($pages->find("template=news-item, limit=5, sort=created") as $item) { echo "<li><a href='" . $item->url . "'>" . $item->title . "</a></li>"; } ?> </ul> ... or this: <ul> <?php foreach ($pages->find("template=news-item, limit=5, sort=created") as $item) { ?> <li><a href="<?php echo $item->url; ?>"><?php echo $item->title; ?></a></li> <?php } ?> </ul> I wouldn't say that there's anything wrong with using selectors within template files, although personally I try to avoid even that when possible. What we're discussing here is simply the syntax used in template files: if you use "full-blown", especially multiline <?php ... ?> code blocks it can seem like you're mixing view side (markup) with business logic (code) even if you're not. On the other hand (probably not what you meant, but just to clarify) if you're wondering why business logic and markup should be separated in the first place, there are a number of reasons to do that. In my case the biggest benefits are a) the ability to alter data structure (model), business logic, or representation (markup) without touching other parts of the site or app, and b) the ability to switch entire view – or use multiple views simultaneously – without having to duplicate any actual "code". (There's a sh*tload of stuff about this in the web, so I won't go into too much detail here. Just google "separation of concerns".) --- Slightly off-topic, but regarding selector use within markup, and why I personally prefer to avoid that: this is in part because in my opinion it looks cleaner, but also because this way I can tweak template names, data structures, etc. without having to modify my views at all. This in turn becomes more useful when you have multiple views for the same data. So, once again, "depends on the use case" ?

This basically does the same as kongondo's script, but has a nice GUI if you prefer. This is one the actions in the AdmimActions module.

Hey @j00st, if you go and edit your original post, it will allow you to edit the title and prepend [SOLVED].

The new Console panel fullscreen mode now has keyboard shortcuts to collapse the code or results panes quickly. Here you can see me toggling all code, all results, and the split of both. Shortcuts are: CTRL+SHFT+ Up arrow - collapses code pane Down arrow - collapses results pane Left arrow - to restore split to what it was before you initiated any pane collapses. Hopefully you'll find this a really quick way to get to the view you need.

In future, will the editors, when they create a new project page, be inputting the display title themselves? Yes ? Yes. The defaults are you start from the beginning (0) and you get everything (limit=0 aka, no limit). In my example, I wanted to start from 2 (not a good example, I know) A better example is, assuming I had done a batch before, say the first 100 pages. In the next batch, I'd start from start=101 and limit=100..meaning, I do 100 at a time. There's a way to automate this, but that's a lot more code :-). Not quite. It would work though, but since you want to apply to all projects pages, there is no need to enter a start and limit. The following would do: generateDisplayTitle('display_title','projects'); It should be the name of the template. In my example, it was 'projects'. Adapt to your needs, so yes, 'project' in your case. But it can be any template with a display_title (or whatever you've named the field) field whose pages you need to edit. Test on a local install first ?

z-index is tricky, if a parent element has lower index then you can't make a child element positioned above it. I hope I can modify AOS to overcome this.

I know this is an old thread, but since it looks unsolved I thought I would share what worked for me in case people are searching the forums. Here are the steps I took: renamed mystyles.js to customstyles.js located at site/modules/InputfieldCKEditor/customstyles.js edited customstyles.js to change the text from mystyles to customstyles.... CKEDITOR.stylesSet.add( 'custom-styles', [ edit the field settings for the field to point to the new customstyles.js The problem for me was that I needed to change the prefix as well from mystyles:/site/modules/InputfieldCKEditor/customstyles.js to customstyles:/site/modules/InputfieldCKEditor/customstyles.js They have to match the file name. Hope that helps someone.

WP is great for things. But here we talk about websites ?

Hi, Teppo Thanks for this clarification and showing these examples. You even have it explained better than what I read in most stackoverflow post. I have saved your post in my Design patterns folder. I see now there is more than just <?php ......?> You are right it makes things better readable and separatable. Maybe it also makes it less load for memory ? I just checked if my code editer is capable of highlighting this style of php syntax, and yes it highlights this style of php code nicely where it should ? All good, thanks.

I guess... we all love and use 3rd party scripts, tools, services and modules for our ProcessWire projects. From image galleries to contact forms and newsletter subscription services lot's of things are already there and ready for use. So I am looking for your most common used and trusted scripts, tools, services and modules. You may ask yourself why I want to know this and before hiding everything behind curtains here is the answer: I plan to create a collection of ready to use ProcessWire snippets for common and often used scripts, tools, services and modules. Therefore I'd like to know what you use for your projects so I can create those ready-to-use snippets. I already have a broad collection of snippets I use everytime but I think there could be much much more. For example: I like to use Owl Carousel 2 and Slick slider for image galleries and/or sliders and Mailchimp as a newsletter subscription service. The main goal is that I want to provide working solutions and answers for ProcessWire starters. More and more questions in the forums are 3rd party related (How do I use this gallery script in PW? or How does this service could be used in PW?) and for those I want to create a copy&paste / ready-to-use collection of snippets. So... I ask you to tell me your most used scripts, tools, services and modules. Feel free to share your trusted 3rd party options with me. P.S.: I don't ask you for your snippets and solutions as they are your business secret and someone already paid you for it. But... if you want to share your scripts with me and the public you are more than welcome. P.S. 2: Modules will be part of this collection Things, thoughts and details about my project so far: Idea: born Domain: registered Hosting: paid / sponsored Scripts: in progress Tools: in progress Services: in progress Modules: in progress Free, premium, freemium: free (no ads, no tracking, no affiliate links) Authors: you & me (full credits given to you) Ideas, thoughts, questions, answers? Let me know!

Hi all, I have posted this in the VIP support forum of Padloper as well. Some of you do not have access to that board so posting here as well. Hopefully it doesn't count as spamming?! In June 2018, Antti announced that he was looking for a new product owner for Padloper. Sometime after, I had a fruitful discussion with him about my vision for the project if I was to take over. We agreed that commitment, motivation and a concrete plan were all important ingredients for the continued success of Padloper. I would like to officially announce that I am now the product owner and lead developer of Padloper. For those who may not know, I am the author and maintainer of several ProcessWire modules, both free and commercial. I am also a moderator in the ProcessWire forums. I would like to share with you a number of things regarding what’s going to happen next. This will be a long read. First, I would like to thank Antti for developing a great product. A lot of man-hours, dedication, passion and love has gone into making Padloper what it is today. Secondly, I would like to thank all users of Padloper. A great product is nothing without active users utilising it, putting it to the test, reporting bugs (even offering possible solutions) and proposing new features. So, thank you for helping make Padloper great! Support Thousands of hours have gone into developing Padloper. Although the code is well-written and easy to follow, Padloper is a big application with many moving parts. As such, it will take some time before I can fully grasp its inner workings. To make this transition as smooth as possible, Antti will help me with support for Padloper for some time. Currently, Padloper has a dedicated support forum. This is an arrangement between Ryan and Antti. The support forum works great as it allows the opening of multiple support threads to cover different issues. I have yet to speak to Ryan whether this arrangement can continue. However, given that I have other pro modules that I support in the open forums, it is unlikely that I will be requesting Ryan to let Padloper’s dedicated forum carry forth. A dedicated forum for one of my pro modules and open forums for my other pro modules will lead to confusion and questions from users of those other modules. Hence, Padloper support in the forums will move to the open forums. The disadvantage here is obviously the fact that support will be offered in one single (and maybe massive) support thread. To get around a ‘single thread support forum’, I am thinking of developing a simple online support queue system for all my modules. Meanwhile, support will continue in a new single thread and via email. Roadmap This list is neither exhaustive nor cast in stone. Its aim is to give an overview of my plans for Padloper. · Padloper 2 – a new major release · New backend for Padloper · Optional pro frontend module for Padloper · Documentation · New payment modules Let’s talk a bit about this list. Padloper 2 Release Padloper 2 will be a major release that incorporates a new, central backend shop for Padloper. This will be a new process module that pulls from the existing parts of Padloper (data models, etc) into one interface (more on this below). This version will also be extensible in the frontend, allowing for the plugging in of a new, optional, commercial frontend shop (full featured shop profile). Padloper 2 will not support the current ‘any page can be a product’ paradigm. Technically, products will still be pages. However, all products will utilise the same Padloper template. These will be invisible to the shop users themselves (e.g., hidden in admin tree). Only superusers will have full control of the Padloper system stuff. Support The current Padloper will continue to be supported until the new Padloper 2 is released. New features will be included in Padloper 2 only. Once Padloper 2 is released, legacy Padloper will only receive security fixes. All other support will cease. Upgrade There will be no upgrade path from the current Padloper to Padloper 2. Although their underlying architecture is the same, making sure that everything works in different setups and environments will be time consuming. However, for those who really need to migrate, if time allows and for an agreed fee, I could develop a custom script for the migration. Backend A new backend interface will be the major visual difference between the existing Padloper and Padloper 2. It goes beyond visual differences though. The new backend will be the single gateway for managing all shop-related features, both current and new ones. The backend will unify and include: · Easily add shop products. · Ability to add as little or as many custom fields to products as required (title, SKU, price, discount field, image/photo, description, categories, tags, etc). · Discounts manager (including auto start/expire discount codes). · Customers manager. · Invoices manager. · Taxes management. · Payment gateways manager. · Improved digital products management. · Stock management. · Manual order creation. · Graphical sales report. · Customer support. · Access-controlled shop editors/staff. · Dashboard for shop metrics. · Shop settings. · Product variations. · Import/export products as CSV or JSON. · Products search/filter. · Etc. Users will be able to turn off backend features that they do not need. This will enable a more streamlined experience for users. I plan to release Padloper 2 within 4 - 6 months, hopefully sooner. This is a major undertaking, hence the timescale. Please note that the first release of Padloper 2 will not include all of the above planned features. The idea is to build incrementally, adding new features in minor updates, focusing on stability, usability and security. Frontend Past requests have included the development of a full featured frontend shop. This is planned for Padloper 2. However, this will be an optional pro module priced separately from Padloper itself. The ability to build own frontend shops using Padloper API will still continue. For those who want a plug-n-play solution, this frontend shop will come in handy. The frontend shop profile will feature an ajax-powered shopping cart and a customisable ready-to-go theme. Pricing Model There are no plans to change the current prices of the 3 Padloper licences (Single, Developer and Agency). However, in order to continue to provide Padloper as a stable product with great features, it is also important that it remains a competitive and financially sustainable project. In order for this to happen and to also bring Padloper in line with my existing pro modules, the pricing model itself has to change. Starting from Padloper 2, the pricing model will shift to an ‘annual subscription’ model rather than the current ‘lifetime licence model’. I am fully aware that there are different opinions for and against annual subscriptions. However, I believe that this model is the most equitable approach that suits both the developer and the clients. The annual subscription will allow users (licence holders) to get 12 months of free VIP support for Padloper as well as future updates available within that time period. After the 12 months, users will be able to renew (online) their subscription at a discounted cost (worked as a fraction of the full purchase price) for a further 12 months (perpetually). Users will be able to continue to use Padloper for life even if they don’t renew their subscriptions. Upgrading current licences to Padloper 2 will be a paid upgrade. Current users of Padloper will get an attractive discount. This will be a time-limited offer (maybe a couple of months) that will start with the release of Padloper 2. New customers will pay the full price for Padloper 2. I hope the planned features are reason enough for you to consider upgrading to Padloper 2. Payment Modules I will be taking over as the maintainer and lead developer of the existing payment gateways (Payment base class, PayPal and Stripe). New payment modules are also planned. Payment modules will continue to be free. However, only ProcessWire 3+ support will be provided going forward. Padloper Domain and Future Downloads I have also taken charge of the Padloper domain. Within the next 12 months, purchase and download of Padloper will shift to processwireshop.pw. Please note that this is not the official shop for ProcessWire! It just bears a name that reflects its product offerings ?. Eventually, traffic to padloper.pw will redirect to processwireshop.pw. Feedback I would love to hear your thoughts about the upcoming changes and any feature requests you might have for Padloper 2. Whilst I cannot guarantee that any request will be implemented, I can promise that I will thoughtfully consider all feedback. Thanks for reading and thank you for supporting Padloper! kongondo

Hello there, I've started using ProcessWire at work a while ago and I have been really enjoying building modular, clean and fast sites based on the CMS (at work, I usually post as @schwarzdesign). While building my first couple of websites with ProcessWire, I have written some useful helper functions for repetitive tasks. In this post I want to showcase and explain a particular function that generates a responsive image tag based on an image field, in the hope that some of you will find it useful :) I'll give a short explanation of responsive images and then walk through the different steps involved in generating the necessary markup & image variations. I want to keep this beginner-friendly, so most of you can probably skip over some parts. What are responsive images I want to keep this part short, there's a really good in-depth article about responsive images on MDN if you are interested in the details. The short version is that a responsive image tag is simply an <img>-tag that includes a couple of alternative image sources with different resolutions for the browser to choose from. This way, smaller screens can download the small image variant and save data, whereas high-resolution retina displays can download the extra-large variants for a crisp display experience. This information is contained in two special attributes: srcset - This attribute contains a list of source URLs for this image. For each source, the width of the image in pixels is specified. sizes - This attribute tells the browser how wide a space is available for the image, based on media queries (usually the width of the viewport). This is what a complete responsive image tag may look like: <img srcset="/site/assets/files/1015/happy_sheep_07.300x0.jpg 300w, /site/assets/files/1015/happy_sheep_07.600x0.jpg 600w, /site/assets/files/1015/happy_sheep_07.900x0.jpg 900w, /site/assets/files/1015/happy_sheep_07.1200x0.jpg 1200w, /site/assets/files/1015/happy_sheep_07.1800x0.jpg 1800w, /site/assets/files/1015/happy_sheep_07.2400x0.jpg 2400w" sizes="(min-width: 1140px) 350px, (min-width: 992px) 480px, (min-width: 576px) 540px, 100vw" src="/site/assets/files/1015/happy_sheep_07.1200x0.jpg" alt="One sheep"> This tells the browser that there are six different sources for this image available, ranging from 300px to 2400px wide variants (those are all the same image, just in different resolutions). It also tells the browser how wide the space for the image will be: 350px for viewports >= 1140px 480px for viewports >= 992px 540px for viewports >= 576px 100vw (full viewport width) for smaller viewports The sizes queries are checked in order of appearance and the browser uses the first one that matches. So now, the browser can calculate how large the image needs to be and then select the best fit from the srcset list to download. For browsers that don't support responsive images, a medium-sized variant is included as the normal src-Attribute. This is quite a lot of markup which I don't want to write by hand every time I want to place an image in a ProcessWire template. The helper function will need to generate both the markup and the variations of the original image. Building a reusable responsive image function Let's start with a function that takes two parameters: a Pageimage object and a standard width. Every time you access an image field through the API in a template (e.g. $page->my_image_field), you get a Pageimage object. Let's start with a skeleton for our function: function buildResponsiveImage( Pageimage $img, int $standard_width ): string { $default_img = $img->maxWidth($standard_width); return '<img src="' . $default_img->url() . '" alt="' . $img->description() . '">'; } // usage example echo buildResponsiveImage($page->my_image_field, 1200); This is already enough for a normal img tag (and it will serve as a fallback for older browsers). Now let's start adding to this, trying to keep the function as flexible and reusable as possible. Generating alternate resolutions We want to add a parameter that will allow the caller to specify in what sizes the alternatives should be generated. We could just accept an array parameter that contains the desired sizes as integers. But that is not very extendible, as we'll need to specify those sizes in each function call and change them all if the normal size of the image in the layout changes. Instead, we can use an array of factors; that will allow us to set a reasonable default, and still enable us to manually overwrite it. In the following, the function gets an optional parameter $variant_factor. // get the original image in full size $original_img = $img->getOriginal() ?? $img; // the default image for the src attribute, it wont be upscaled $default_image = $original_img->width($standard_width, ['upscaling' => false]); // the maximum size for our generated images $full_image_width = $original_img->width(); // fill the variant factors with defaults if not set if (empty($variant_factors)) { $variant_factors = [0.25, 0.5, 0.75, 1, 1.5, 2]; } // build the srcset attribute string, and generate the corresponding widths $srcset = []; foreach ($variant_factors as $factor) { // round up, srcset doesn't allow fractions $width = ceil($standard_width * $factor); // we won't upscale images if ($width <= $full_image_width) { $srcset[] = $original_img->width($width)->url() . " {$width}w"; } } $srcset = implode(', ', $srcset); // example usage echo buildResponsiveImage($page->my_image_field, 1200, [0.4, 0.5, 0.6, 0.8, 1, 1.25, 1.5, 2]); Note that for resizing purposes, we want to get the original image through the API first, as we will generate some larger alternatives of the images for retina displays. We also don't want to generate upscaled versions of the image if the original image isn't wide enough, so I added a constraint for that. The great thing about the foreach-loop is that it generates the markup and the images on the server at the same time. When we call $original_img->width($width), ProcessWire automatically generates a variant of the image in that size if it doesn't exist already. So we need to do little work in terms of image manipulation. Generating the sizes attribute markup For this, we could build elaborate abstractions of the normal media queries, but for now, I've kept it very simple. The sizes attribute is defined through another array parameter that contains the media queries as strings in order of appearance. $sizes_attribute = implode(', ', $sizes_queries); The media queries are always separated by commas followed by a space character, so that part can be handled by the function. We'll still need to manually write the media queries when calling the function though, so that is something that can be improved upon. Finetuning & improvements This is what the function looks like now: function buildResponsiveImage( Pageimage $img, int $standard_width, array $sizes_queries, ?array $variant_factors = [] ): string { // get the original image in full size $original_img = $img->getOriginal() ?? $img; // the default image for the src attribute, it wont be upscaled $default_image = $original_img->width($standard_width, ['upscaling' => false]); // the maximum size for our generated images $full_image_width = $original_img->width(); // fill the variant factors with defaults if not set if (empty($variant_factors)) { $variant_factors = [0.25, 0.5, 0.75, 1, 1.5, 2]; } // build the srcset attribute string, and generate the corresponding widths $srcset = []; foreach ($variant_factors as $factor) { // round up, srcset doesn't allow fractions $width = ceil($standard_width * $factor); // we won't upscale images if ($width <= $full_image_width) { $srcset[] = $original_img->width($width)->url() . " {$width}w"; } } $srcset = implode(', ', $srcset); return '<img src="' . $default_img->url() . '" alt="' . $img->description() . '" sizes="' . $sizes_attribute . '" srcset="' . $srcset . '">'; } It contains all the part we need, but there are some optimizations to make. First, we can make the $sizes_queries parameters optional. The sizes attribute default to 100vw (so the browser will always download an image large enough to fill the entire viewport width). This isn't optimal as it wastes bandwidth if the image doesn't fill the viewport, but it's good enough as a fallback. We can also make the width optional. When I have used this function in a project, the image I passed in was oftentimes already resized to the correct size. So we can make $standard_width an optional parameter that defaults to the width of the passed image. if (empty($standard_width)) { $standard_width = $img->width(); } Finally, we want to be able to pass in arbitrary attributes that will be added to the element. For now, we can just add a parameter $attributes that will be an associative array of attribute => value pairs. Then we need to collapse those into html markup. $attr_string = implode( ' ', array_map( function($attr, $value) { return $attr . '="' . $value . '"'; }, array_keys($attributes), $attributes ) ); This will also allow for some cleanup in the way the other attributes are generated, as we can simply add those to the $attributes array along the way. Here's the final version of this function with typehints and PHPDoc. Feel free to use this is your own projects. /** * Builds a responsive image element including different resolutions * of the passed image and optionally a sizes attribute build from * the passed queries. * * @param \Processwire\Pageimage $img The base image. * @param int|null $standard_width The standard width for this image. Use 0 or NULL to use the inherent size of the passed image. * @param array|null $attributes Optional array of html attributes. * @param array|null $sizes_queries The full queries and sizes for the sizes attribute. * @param array|null $variant_factors The multiplication factors for the alternate resolutions. * @return string */ function buildResponsiveImage( \Processwire\Pageimage $img, ?int $standard_width = 0, ?array $attributes = [], ?array $sizes_queries = [], ?array $variant_factors = [] ): string { // if $attributes is null, default to an empty array $attributes = $attributes ?? []; // if the standard width is empty, use the inherent width of the image if (empty($standard_width)) { $standard_width = $img->width(); } // get the original image in full size $original_img = $img->getOriginal() ?? $img; // the default image for the src attribute, it wont be // upscaled if the desired width is larger than the original $default_image = $original_img->width($standard_width, ['upscaling' => false]); // we won't create images larger than the original $full_image_width = $original_img->width(); // fill the variant factors with defaults if (empty($variant_factors)) { $variant_factors = [0.25, 0.5, 0.75, 1, 1.5, 2]; } // build the srcset attribute string, and generate the corresponding widths $srcset = []; foreach ($variant_factors as $factor) { // round up, srcset doesn't allow fractions $width = ceil($standard_width * $factor); // we won't upscale images if ($width <= $full_image_width) { $srcset[] = $original_img->width($width)->url() . " {$width}w"; } } $attributes['srcset'] = implode(', ', $srcset); // build the sizes attribute string if ($sizes_queries) { $attributes['sizes'] = implode(', ', $sizes_queries); } // add src fallback and alt attribute $attributes['src'] = $default_image->url(); if ($img->description()) { $attriutes['alt'] = $img->description(); } // implode the attributes array to html markup $attr_string = implode(' ', array_map(function($attr, $value) { return $attr . '="' . $value . '"'; }, array_keys($attributes), $attributes)); return "<img ${attr_string}>"; } Example usage with all arguments: echo buildResponsiveImage( $page->testimage, 1200, ['class' => 'img-fluid', 'id' => 'photo'], [ '(min-width: 1140px) 350px', '(min-width: 992px) 480px', '(min-width: 576px) 540px', '100vw' ], [0.4, 0.5, 0.6, 0.8, 1, 1.25, 1.5, 2] ); Result: <img class="img-fluid" id="photo" srcset="/site/assets/files/1/sean-pierce-1053024-unsplash.480x0.jpg 480w, /site/assets/files/1/sean-pierce-1053024-unsplash.600x0.jpg 600w, /site/assets/files/1/sean-pierce-1053024-unsplash.720x0.jpg 720w, /site/assets/files/1/sean-pierce-1053024-unsplash.960x0.jpg 960w, /site/assets/files/1/sean-pierce-1053024-unsplash.1200x0.jpg 1200w, /site/assets/files/1/sean-pierce-1053024-unsplash.1500x0.jpg 1500w, /site/assets/files/1/sean-pierce-1053024-unsplash.1800x0.jpg 1800w, /site/assets/files/1/sean-pierce-1053024-unsplash.2400x0.jpg 2400w" sizes="(min-width: 1140px) 350px, (min-width: 992px) 480px, (min-width: 576px) 540px, 100vw" src="/site/assets/files/1/sean-pierce-1053024-unsplash.1200x0.jpg" alt="by Sean Pierce"> Now this is actually too much functionality for one function; also, some of the code will be exactly the same for other, similar helper functions. If some of you are interested, I'll write a second part on how to split this into multiple smaller helper functions with some ideas on how to build upon it. But this has gotten long enough, so yeah, I hope this will be helpful or interesting to some of you :) Also, if you recognized any problems with this approach, or can point out some possible improvements, let me know. Thanks for reading!

I'm someone who has been developing websites for a while, mostly doing full stack .NET development and ASP scripting before that, while using Silverstripe and some other PHP frameworks for some smaller projects which worked well enough for quite some time. Now I have some time on my hands and decided to evaluate some different CMS options. Diving in as a newbie into: Wordpress Processwire CraftCMS After a short while I decided that Wordpress was out while I'm still evaluating Craft and Processwire. My question is, is there any interest here in reading about my experiences in trying to get the feature set I want up and running, with these other systems?

Hi Ryan Just added a fix for this in 3.0.112. See the Issue here on github: https://github.com/processwire/processwire-issues/issues/675#issuecomment-420958397 I also added my final hook in the comments. regards, tom

MarkupSrcSet doesn't use JS to generate the markup. I guess the JSON format that misled you, in fact the module was rewritten a year ago, see this post: https://processwire.com/talk/topic/12981-markupsrcset/?do=findComment&amp;comment=150129

Hi Bernard, I didn't know that module, looks interesting as well ? Well, it's a different approach in that I'm not using javascript and instead generate the entire function based on the passed parameters. I'm just using native functionality instead of Javascript, which is good if you don't have to support older browsers. The generation of the srcset and corresponding images seems to be handled in a similar way though, so it comes down to preferences I guess. Hi horst, thanks ? I actually don't know how this interacts with changing focus points, my last projects didn't really involve heavy usage of the focus points. I'll need to do some testing, I'll update the function when I get to it. For my last projects I just temporarily put $img->removeVariations() in the function and clicked through the site (should be easy to automate based on the sitemap). Though this will be trouble when the editors manually create variations. Hm, using a suffix for the generated images is a good idea, this way they could all be invalidated at once. I haven't used suffixes yet, I'll look into that. Do you have a suggestion on how to modify the function accordingly? ?

Sure! ? Maybe - if it is easy - it would also make sense to have a fullscreen for the console code input. But that's only some ideas. Everything works great for me as it is. Just suggestions for improvements.

You need wireHTTP to send a GET or HEAD request to get back the status code. ?

Hey @bernhard - I like this, but I am thinking of maybe applying it to the entire results windows, rather than a specific dump result, so it would look like this. This way you would still have fullscreen, but it makes it easier to inspect the different dumps without needing to exit fullscreen and then initiate it on another dump. Does this seem ok to you?

I don't remember where I pulled this illustration from. I maybe found it somewhere here in the forum or here https://www.cmscritic.com. It corresponds largely to my personal experience. Another dimension, called 'security' is missing and would also help to make a good decision ...

make all languages viewable and put the following code in your home template if ($user->language->isDefault() === false) { $session->redirect($page->localUrl($languages->getDefault())); }

Probably a namespace issue - try new \ProcessWire\WireUpload

Hey @adrian what do you think of adding a fullscreen button to the dump div right beside the collapse toggles? When having large dumps this could greatly improve readability and it would just need to apply a simple class with these css rules: element.style { position: fixed; left: 0; top: 0; z-index: 99999; width: 100%; height: 100%; background-color: #fff; overflow: scroll; } Then it could turn this: Into that: The collapse toggles still work. Of course we'd also need a "close fullscreen" button (or maybe ESC keyboard shortcut?)

Great idea, thanks! Added in v0.1.8.

One more update to handle when you're close to the end of the siblings. There might be a better way to do this - this was just what came to mind quickly ?

Just had another thought ? For pages with more than 25 siblings, I wonder if it would be worth putting the current page in the middle of the list of options, with 12 before and 12 after. At the moment, if the page being edited is beyond the first 25 it doesn't show in the list and so there is no way to access pages on either side of the current one. I think this is fairly efficient: public function ___getSiblings($page) { $numSiblings = $page->parent->numChildren(); $start = $numSiblings > 25 ? ($page->index - 12 > 0 ? $page->index - 12 : 0) : 0; while($numSiblings - $start < 25) $start--; $siblings = $page->siblings("start=$start, limit=25, include=all"); $siblings->filter("listable=1"); return $siblings; } Instead of this where you can't see page "27" in the list: you now get this with it right in the middle: You probably need to do some more testing to make sure there are no issues with sorting. Maybe the selector needs: sort=sort Did some testing here and it seems to be working great.

You can do many kinds of sorting/counting/aggregating using RockFinder quite easily and efficiently, I just posted an example:

Thanks, that is excactly what I need. Great ideas from Ivan. I had the same, but he was quicker ?

It can be handled by the new stuff I set up recently. Have a read here: It allows you to set Tracy settings in config.php or config-dev.php (so it's local only). I think this is probably the best solution. Let me know how you find it and if you have any suggestions for improvements. PS - there is some further discussion about the instigation of this feature starting around here: https://processwire.com/talk/topic/5693-new-module-type-wiremail/?do=findComment&amp;comment=172371

Are you using a JS framework? You need to make sure the X-Requested-With header is sent so that PHP (and therefore Tracy) can recognize it as an AJAX call. jQuery does this by default, but other frameworks may not, eg Angular. In pure/vanilla JS, you can do: xmlhttp.setRequestHeader("X-Requested-With", "XMLHttpRequest"); In Angular you can do: $http.defaults.headers.common["X-Requested-With"] = "XMLHttpRequest";

Interesting that in this case InnoDB faster and yet there have been other issues where it's much slower: https://github.com/processwire/processwire-issues/issues/692 I am sure there's a good reason for it, but it does make the decision on which to use more difficult. Maybe MyISAM for most tables and InnoDB for the sessions table if you are using SessionHandlerDB?

Yes, when you try to output a image field from a module, hook or bootstrap script it is an array, even if you set it to single in the back-end. ?

You're talking about short echo tags (<?= ... ?>) right? In that regard I agree: that's a good solution in template use. Short open tags (<? ... ?>) are a different thing entirely, and although earlier decision to remove them was apparently cancelled, they're still discouraged and disabled by default.

Could be interesting if you can integrate this as an option: https://omnipay.thephpleague.com/ because it has several implementations for gateways by the community: https://omnipay.thephpleague.com/gateways/community/ and can be extended easily... It will be perfect if you can check the backend of Shopify (14 days free trial), is really easy to use and understand for the customers. The workflow concepts and the organization of product information, collections, discounts, inventory, etc is very simple and concise, minimal enough for a regular store. My personal recommendation is to stay away from Magento like UI and concepts. Maybe the backend could use some ideas similar to your Media Manager or Visual Page Selector, I like the visual look and the user interaction.

My thoughts FWIW... the dependent modules, eg Fieldtype & Inputfield version numbers should be in line with the module version number. To keep things consistent, if the dependent Fieldtype or Inputfield are updated, the module version should be updated too to alert devs of the change

$u = $users->find("last_name=Smith"); foreach($u as $uu) { echo "{$uu->first_name} {$uu->last_name}<br>"; } // combine: (marital_status is a page-reference field in my test setup) $u = $users->find("marital_status=divorced, last_name=Smith"); foreach($u as $uu) { echo "{$uu->first_name} {$uu->last_name}, {$uu->marital_status->title} <br>"; }

Hi, I've just read about Open Collective: https://wptavern.com/new-backyourstack-tool-drives-financial-support-for-open-source-projects ProcessWire or the top 3 (or 4?) most popular ProcessWire modules might be able to utilize it. I opened a "request": https://github.com/processwire/processwire-requests/issues/218 Top modules: https://weekly.pw/issue/202/ Tracy Debugger by @adrian AdminOnSteroids by @tpr FormBuilder and ProCache by @ryan

Hi guys As a @sforsman's coworker I'll let him know about this. We do use namespaced version of this module ourselves.

https://www.baumrock.com/portfolio/hr-diamonds.com/ I built this website for my client hrdiamonds.com - a great HR company based in Vienna, Austria. They were totally unhappy with the result of the former agency so it was easier to rebuild the website from scratch than adopting the old CMS (that was actually only 2 years young!)... Design by @lokomotivan built with UiKit Highlights: Frontend-Editing barba.js for smooth page transitions ProCache, of course Favourite client quote of the CEO: Happy to hear your feedback