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.