Michael van Laar

@Robin S You made my day! ?

Something for the upcoming holidays. :-)

AdminOnSteroids has a nice feature to make pages stick to the top of the page tree. Is there an easy way to do the opposite—make a page stick to the bottom of the page tree? What I’d like to use it for: Usually I have a test page in my PW setup. This is handy because the main content of a page is often created using a Repeater Matrix field. If I add a new type to this field, I can test it on the test page (which usually uses the basic page template). In the page tree, I usually position this test page as the last page before the 404 page. 404 page, the admin section and trash are always at the bottom of the fist level of the page tree. I’d like to see my test page work the same: It should be positioned before the 404 page. And when I add a new page directly under home (with the first level of the page tree being manually sortable), I’d like the new page to be inserted just before my test page instead of just before the 404 page.

I haven’t really investigated this. But it’s interesting to get a little insight into how PW handles all the database queries when rendering a page. Thanks for that. ? Perhaps I’m going to play around with the Autojoin settings a little bit. For now, caching does the job. But autoloading fields would perhaps make sense to improve the performance of the first rendering of a page, the result of which is then stored in the cache.

Regarding the frontend: The lazyloading is only done for images and all of the required information is already in the rendered HTML. So after the initial rendering of the page, everything is finished as far as PW is concerned. By the way, the query count of the page with 30 content blocks is 366.

Without cache it takes about 760 ms—tested from the same location in Germany: https://www.webpagetest.org/result/181020_BK_fbeaed2dca272e2bb1aa182557e47372/1/details/#waterfall_view_step1 So there is a significant difference. Of course I could make the whole site faster by using ProCache, moving to another webspace provider and using a CDN. ? It depends. I use lazysizes, too. And I always include a noscript version, so that all links to the various image sizes are in src attributes, so crawlers can read them. I recently read that when the Google bot crawls a page for the first time, no JavaScript is executed, so it only grabs what’s in the HTML code. After a while (hours/days/weeks, depends on the specific case) the bot returns and then takes a bit more time to execute JavaScript and does a more comprehensive crawl. So everything should work without an image sitemap.

Thanks for the answer. ? So I stick with the Repeater Matrix solution. The page is cached, using the default cache. The server is located in Germany. The time-to-first-bite is around 300 ms when I test it from Germany: https://www.webpagetest.org/result/181020_N8_c213855c7f91cd11779d0debf99f8db9/2/details/#waterfall_view_step1 I include images and videos due to SEO reasons. Because of the type of lazy loading solution I use, Google may not be able to get to know all of the images. That’s why I chose to build my own template for this instead of using the module. But of course, this is more because I wanted to test what is possible, and it is not a mandatory thing. Right now I still have all of the repeater items opened right away in the backend. But I use the “Inline Editor” option for CKEditor fields, so the editor button bar etc, only load when I edit the field. I like this solution because with all repeater items opened I can simply use the browsers on-page search function to get me to the section of the page I want to edit. With around 10 repeater items this works great without any performance issues. With around 30 repeater items, it gets slower, e.g. when you click somewhere into an already activated CKEditor field, it takes around 2 seconds until the cursor actually appears at this location. That’s why I thought, PageTableExtended could be a nice alternative because I could output all of the text—so it is searchable—and avoid the performance issues (because there are no directly editable fields). But I personally like Repeater MAtrix much more here. It’s much more intuitive to use for website editors.

Hi folks, I have a simple(?) question, followed by a slightly lengthy background explanation: Is it a good idea—in terms of scalability and frontend performance—to use a Repeater Matrix or PageTable field to build modular content blocks? And here is the background explanation: I’m quite obsessed with the idea of using modular blocks to build the content of a page. Each type of element (e. g. images, videos, quotes, code examples, but also more complex elements like image galleries, promotion boxes for products or events) gets its own set of input fields, encapsulated in a container. The page’s content—or certain parts of it—are then built by stacking containers of different element types. Using such content blocks allows all kinds of pre-processing happening behind the scenes. By now I implemented modular content blocks in one ProcessWire instance, using a Repeater Matrix field. This works great but comes along with some serious performance issues. Let’s ignore the backend-related performance issues. They can be solved by either not opening all Repeater items or by building a solution using a PageTable field and the PageTableExtended module instead of Repeater Matrix. Regarding the frontend: I noticed that it’s pretty much unusable without activated cache. No surprise. This article page, for example, consists of 30 different content blocks—plus some more page references for author, category, article series, etc. Without activated cache, the loading time is simply unacceptable. The PHP object with all its sub-objects must be quite big, which explains the slow server response. With activated cache, the pages load pretty fast (letting aside the external cookie banner which is an experiment), due to the performance optimization features I built into the content block templates. But there is more than just article pages: What about list pages? What about the XML sitemap which in my case iterates over all content blocks of all pages to include information about all images and embedded videos? The blog where I use the Repeater Matrix content block solution is still very small (because I haven’t had the time to write articles). But what happens when such a website gets bigger? Think of a website with 150 pages, each consisting of 20 content blocks. Let’s stick to the XML sitemap example: ProcessWire would have to iterate over 3150 pages in total to render the output. This wouldn’t happen too often because the output can be saved—using the built-in cache or ProCache. But it needs to be done on a regular basis. That’s why my question: Is it a good idea to build modular content blocks like this with ProcessWire? Does caching do the trick in the frontend? Or are there some hidden strings attached when a project scales? Is there perhaps a better solution than using a Repeater Matrix or PageTable field? Of course, I could turn to other CMSs which use such content blocks as part of their core concept: the PHP-based Neos or the Node.js-based ApostropheCMS , for example. (Even the plain old TYPO3 uses content blocks, but I would never voluntarily use TYPO3 if I can avoid it.) But those are far more complex to set up, implement and maintain, so I’d really like to stick to ProcessWire.

Obviously ImageMagick causes this bug in combination with uploading JPG files, according to the AJAX error message. After deinstalling the IMagick Image Sizer module, uploading JPGs is no problem. This was my test case: Uploading the PNG file testupload1png.png With ImageMagick: upload works ?? Without ImageMagick: upload works ?? Uploading the same image as above converted into the JPG file testupload1jpg.jpg With ImageMagick: upload results in an error message and doesn’t show up in Media Manager. ?? AJAX error message: “no decode delegate for this image format `JPEG' @ error/constitute.c/ReadImage/504” Without ImageMagick: upload works ?? Uploading a second PMG file testupload2png.png With ImageMagick: upload works ?? AND somehow “pushes” the failed JPG upload into the Media Manager, so now all three uploaded files show up as they should. Without ImageMagick: upload works ?? I guess I can now either not use ImageMagick (which I just used because my hoster provides it on their servers as a default and it was recommended because of better memory usage). Or I can ask the support of my hoster about this problem.

I just bought and installed the module (v0.1.1 with Jquery File Upload v0.0.6), but get the same “Empty file upload result” error messages as mentioned a year ago. ? (Using PW 3.0.98) A little bit of testing revealed an interesting pattern: I upload a single image which is processed without problems. -> Shows up as it should. (I use “After Uploading“ setting no. 1.) I upload a second single image which returns the “Empty file upload result” error message. -> New image doesn’t show up in the Media Manager and the three temporary files in /site/assets/MediaManager/jqfu/.files_no_show and in /site/assets/MediaManager/jqfu/.files_no_show/thumbnails exist and look good when looked at in the browser. I upload a third single image which is processed without problems. -> Now all three images (including the second one) show up correctly in the Media Manager. Unfortunately I can’t tell the exact reason why the error message appears. I even tested small images (around 260 KB, so that should not trigger any memory problems while processing): The png version of one image could be uploaded while the jpg version triggered the “Empty file upload result” error message. The jpg version had about the same filesize as the png file—compressed as well as uncompressed, according to the infos in GIMP.

I just used a Repeater field on a hidden “website config” page to create my own menu building tool with exactly the features I needed for that website, including using multi-language fields within the repeater.

@Standard Forge, if you just want to make one or two minor changes to a rendered menu without having to build all the markup yourself (using getMenuItems()), you can do a quick str_replace. Example: $menu = $modules->get('MarkupMenuBuilder'); // cache the rendered menu $schema_menu = $menu->render('my-menu-name'); // alter the rendered menu to your desire $schema_menu = str_replace('<li ', '<li itemprop="name" ', $schema_menu); $schema_menu = str_replace('<a ', '<a itemprop="url" ', $schema_menu); // output the altered menu echo $schema_menu; Quick and dirty, I know. But if you are using delayed output anyway, it’s just one or two lines of code.

I took a few minutes to investigate. As far as I understand, the variable $redirectURL in /wire/modulesProcessProcessPageView.module is used to perform the above mentioned redirect (as well as any redirect which is necessary when handling URLs). In this case the varibale $redirectURL is set in /wire/modules/LanguageSupport/LanguageSupportPageNames.module, between line 202 and line 317. If it’s possible at all to eliminate the default language’s name segment from the URLs of pages of a specific tree branch – which is something @ryan or someone knowing the core really well could tell –, writing a hook that alters $redirectURL before it is used would be the direction I’d think of. But since I still haven’t had much time to learn more about the different hooks, this is only a guess.

I have the same challenge now on a multilang site. Using PW 3.0.42 with the default multi-language setup. A certain branch of the page tree should act as a kind of microsite, with different templates etc. But only in the default language (English). As far as I understand I’d “only” have to disable the automatic redirect from domain.com/microsite to domain.com/en/microsite – which is obviously a default feature of the multi-language setup – for the specific branch. I guess this feature is hidden somewhere in the LanguageSupport core module. So it should be hookable (since pretty much everything in PW is hookable). Anyone has a deeper understanding of the LanguageSupport core module and can provide a hint?

Great idea and great module! Saves me some rather ugly additions to the displayed title page in the page tree. One thing for the Christmas wish list: It would be even greater if the module would provide a way to set up several different rule sets. So you could set up different icons to mark different things.

Ah, great. Gotta test this the next days.

Thanks for the explanation, @matjazp. As I said, I'm fine with being able to use resmush.it via the module, since resmush.it works like a charm, and I don’t have any images which are not sooner or later made publicly available (so there are no privacy issues). Being independent from resmush.it would be a nice extra, but it’s not really required from my side. This would be interesting for cases where PW and Autosmush are used to build a website for a closed user group with confidential content which should not be send around between servers.

Of course I used the individual options. I also tried commenting out the pngquant_bin setting, hoping that the modiule would go on trying to use the next available PNG optimizer. But it didn’t work. I got the error message that pngquant could not be found.

Since my Linux knowledge is quite limited, I had to research and try a bit. Only the last option (inserting the path into the module file) worked – but only for jpegoptim. If i try to upload a png, I receive an error message telling me that the pngquant command doesn’t work, even if the module now knows the path to the binary. To be honest, that’s too much work to investigate. I just use resmush.it as long as it works.

Anyone has a solution for multi-language menus with custom menu items? For pages localisation works using the default_title option. But this is not possible with custom menu items. And since the items’ title field is not a multi-language field, I have no idea how to solve this. But I’m probably not the first one stumbling over this. ;-) If not, I think I have an idea how to build a solution using nested repeater fields.

Is there anything I have to set up to use the local optimization tools? I'm on a shared webspace, but each customer has a separate FastCGI PHP interpreter. So it should work according to the module’s documentation. Or did I miss anything? The error messages say “Command "jpegoptim" not found.” or the similar message for pngs.

Great! I was looking for a module like this after https://minimize.pw/ closed the doors. I have to test it tomorrow. I guess it works with Croppable Image 3, too, doesn’t it? Or let’s better phrase it: Does automatic mode work with all modules which extend the functionality of PW’s default image field? That would really make optimizing images a no-brainer.

I know, images differ from the other media types a little bit. As an alternative to the above described I could think of input field types which work like Croppable Image 3 or ImageFocusArea, but use a Media Manager image instead of a directly uploaded image. I know this is not something which can be done with Media Manager itself. It would rather be a concept of being able not just to extend the standard image field but to extend a king of “remote image” fieldtype the same way. But I think this would have to be in the core, so that every module which extends or uses the standard (direct upload) image field could use this “get an image from Media Manager and apply the module’s magic to it” image field.

Great module from what I could see in the videos. Definitely something I want to use in my upcoming projects. Only one question regarding the handling and output of images Is there a way to make any kind of pre-defined crop-settings (like in the Croppable Image 3 module) or something like the focus area from the (unsurpassedly useful but unfortunately not PW 3 compatible) ImageFocusArea module available with Media Manager? Why I ask In my websites I use responsive images wherever possible, usually using the picture element because I often need its art direction feature. So my workflow in PW 2.x was: Use the ImageFocusArea module’s input field to upload an image. Define the important region (= “focus”) of the image which must be fully visible in all cropped image variations. Have ProcessWire create all required sizes of all required image variations directly from the original image using the image sizing options (extended by the ImageFocusArea module) in the template files. The two big pros of this workflow were that the user only had to define the important area of the image once – and was not bothered with any cropping settings (like finding a good-looking image section for an extremely wide horizontal format) – and that all required variations and sizes (I usually use about 10 different images per picture element) were created directly from the original image (which ensures best quality because no unnecessary compression steps were included). In PW 3.x I had to change this due to the new image field which makes the ImageFocusArea module incompatible with PW 3: Use the Croppable Image 3 module’s input field to upload an image. Use the input field’s settings to define the biggest (in pixels) version of each required aspect ratio variation of the image. Let the user define the best looking image sections for the different crop variations (let’s say we need a 2:1 aspect ratio version and a 4:3 aspect ratio version of the image for one picture element). Have ProcessWire create the required downscaled versions of the “source images” (i. e. the variants created using the pre-defined crop settings of the Croppable Image input field) using the standard image sizing options in the template files. While it works, the two big cons here are that the user has to define the different aspect ratio variations manually (assuming that the automatically created default cropping around the image’s center isn’t the best-looking option) and that the downscaled variations of each aspect ratio variations are created from an already processed image (so this includes at least one unnecessary compression step). And of course changing aspect ratio variations later (because of a website layout revision) can result in a lot of manual work to adapt cropped image variations. What would really be a great extension for Media Manager in my opinion It would be great if the ImageFocusArea module’s functionality would be available in Media Manager under PW 3. This would make using different image variations a no-brainer – without the website editor having to know anything about image variations, aspect ratios, sizes, cropping, etc.: The website editor uploads an image in Media Manager. The website editor defines the important area of the image which may never be cut away. The website editor selects the image on the respective page using Media Manager’s input field. That’s it. The template files take care of the rest. And even if the website layout completely changes the selected image needs not to be touched, since all required image variations are created from the original, centrally available image, making sure that the image’s main motive is always presented in the best possible way. Of course, when inserted into a CKEditor field, the editor can apply an individual cropping if desired. Unfortunately I’m not a backend developer at all. So I can’t make any code suggestions on how to make this work.

Wow, thanks @Robin S. That’s exactly what I was searching for. I haven’t learned much about hooks yet, simply because there was no need by now. I thought I have to write a module to achieve this. But putting this in the ready.php works like a charm and is super easy to set up.