Leaderboard

There's a couple things that made me think this part of the core could be better (and nothing related to middleware). First is that PW didn't originally support multi-language URLs, and so the LanguageSupportPageNames module was built to hook in and add support for that. There are benefits (performance, simplicity, etc.) to having that logic lower-level in the core and part of the same logic that identifies non-multi-language URLs. So that's something I've been interested in for a long time, but it was always more than I wanted to get into. The other thing is that I was working on that SessionAllow module and found it was a real drawback not to be able to know what Page was requested before deciding on things like whether to allow a session or not. Granted, we can still know the request URL before we know the Page, but it just seemed a lot more flexible for the core to know the requested Page much earlier in the boot process. That way, we can do things like configure whether sessions are allowed on a per-template basis, where such an option seems to make the most sense. Another example is 404 pages—maybe we don't need a session on a 404 page. But without knowing whether the URL will resolve to a Page or not, we didn't have that choice. Following these updates, we will. Lastly, I just like to revisit the core logic for things and improve it when/where possible, which helps to keep it fresh on the mind. But I don't like to get into replacing this kind of major core code when it'll soon be merged to the master, as this is the kind of stuff that needs more testing over a longer period of time. So with a comfortably stable master version available right now, it seemed like a good time to work on this.

Field that stores one or more references to ProcessWire pages with additional data in field context. Values are editable via page edit modal of the referenced page provided from the field if module AdminPageFieldEditLinks is installed and "Enable link to create new pages?" is checked in field settings. Requirements: AdminPageFieldEditLinks >= 3.1.4 https://github.com/kixe/FieldtypePageContextData https://processwire.com/modules/fieldtype-page-context-data/ Use case example: The planning of the Tonmeistertagung in the CCD (Congress Center Düsseldorf) from November 3rd, 2021 to November 6th, 2021 is in the finalization phase. The conference consists of a conference part and an exhibition. The planning is done via a separate frontendless PW instance. There, all companies (pages) that are active at various events are kept in a pool. Changes (address, logo) can always be done there. For the exhibition of the current conference in November, the exhibitor-companies (pages) are selected via a page reference field. A stand number must now be assigned to each selected company (page). We had originally solved this using the Profield FieldtypeTable. However, this had the disadvantage that each entry again made all companies available for selection and did not recognize which were already selected in a previous table row. The new field type now allows the value (company's stand number) to be assigned to a Company (page) in context to a specific Pagefield living in a specific page. https://tonmeistertagung.com/en/exhibitors/exhibition/

This week I've been focusing on the dev branch and some low level code optimization, especially as it relates to the PW boot process, translating URLs to pages and identifying the page, language, URL segments, page numbers, etc. from the request URL. I'm breaking down much of the logic (currently in the ProcessPageView module) into more focused parts that can become part of PW's $pages API, increasing reusability of related code. (Don't worry, this won't affect any existing hooks). At the same time, I'm looking for opportunities for optimization and performance improvement, and have already found a few. For instance, the LanguageSupportPageNames module introduces overhead into some page finding operations and there's good improvement potential there, among others. I'm pretty much still in the middle of it all though, so am going to hold off on committing any of this to the dev branch until it's further along. But since we've got a quiet commit log this week, I just wanted to keep you up-to-date. Hopefully some of these fairly significant updates will be stable enough to commit to the dev branch next week. By the way, these updates will also enable the SessionAllow module (from last week) to be configurable by page, as PW will now identify the requested page before starting the session. More soon. Have a great weekend!

@Morphosis, welcome to the PW forums! ? It's unlikely that this is related to browser differences. What's more likely is that you are logged in to the PW backend in Chrome (probably as superuser) but in Safari you are not logged in, or logged in as a less privileged user. So the area to focus on is fields or templates that have access restrictions. If I understand right you have created a Page Reference select field (selectfromrepeater) and set the selectable pages to be items in a repeater field. The template used by a repeater field (named in the format "repeater_[field_name]") is not accessible by non-superusers. The idea is that users should not have direct access to repeater pages but instead must access them via the repeater field value. So if you are defining selectable pages for the selectfromrepeater field using a selector string like this... template=repeater_yourfieldname ...then this will cause problems when a non-superuser works with the field. The "official" way to get repeater pages is via the repeater field value, so you would use the "Custom PHP code" option for defining selectable pages: $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'selectfromrepeater') { // Get the page that contains the repeater field however suits $page_with_repeater_field = $event->pages->get(1234); // The event return is the repeater field value $event->return = $page_with_repeater_field->repeater_field_name; } }); Technically you could stick with the selector string option and explicitly disable the access control when getting the repeater pages... template=repeater_yourfieldname, check_access=0 ...but in doing that you would be going against the way the core wants you to work with repeater pages, so perhaps better not to do that unless you're 100% clear on all details of how repeater fields work. When debugging issues like this, the Tracy Debugger module is a huge help. The bd() method is all you need to learn to start with.

@AndZyk Here's a new fieldtype I have been working on for the past weeks. These draggable blocks are defined by developer using custom templates, and they are fully stylable. The module is quite far from being production ready, but I wanted to share this, since I think this might be something you're looking for ? Proper teaser video will come after I reach the first milestone in development process.

I was curious and tested out the new Blocks + Layout feature of Kirby 3.5 and here is my brief experience: The interface of the Layout feature is really nice and its fun to add or drag & drop blocks. If the Repeater Matrix would have such an interface, it could be a nice layout builder in ProcessWire. Also it is possible to add custom settings for each row, which makes it possible to customize your layout more. But currently it is not possible to switch the layout (f. e. from 3 columns to 4 columns). If you want to do this, you have to add a new row and drag & drop the blocks there. Also you cannot add custom settings to each column. This feature is currently in development. As for the blocks: You have a default set of blocks (Text, Image, Video etc.) which is nice and covers most of the content needs. Each block has its own snippet, similar to field templates. So you are free to customize the default blocks. Or you can create custom blocks with own fields. But you cannot see all fields of the custom blocks in the layout interface. To edit custom blocks you have to click on the block, which I think is ok in my opinion. In my opinion the Blocks + Layout feature is cool, but has its limitations at the moment. It is a nice mix of layout builder and customization. I wish the Repeater Matrix could be enhanced in this way. But I know that layout builder are no easy task. ?

Kirby 3.5 is now released and the Blocks + Layout feature looks awesome. Something I still miss in ProcessWire. I know for Blocks we have the Repeater Matrix and you could use it for layouts too, but its not that intuitive in the back-end in my opinion. A module like the Layout feature of Kirby would be really awesome. ? By the way, they have a really good marketing strategy in promoting their features. At least it is working for me. ?

I had the same problem and it had me perplexed for a while. My Command Line Interface script bootstraps ProcessWire and then fails without even the tiniest hint of an error message. In my case, the problem was that code from /site/ready.php was being executed when ProcessWire was bootstrapped. The code I had in /site/ready.php was only intended for execution in specific situations while web browsing (not CLI). So I took the code inside that file and wrapped it inside this: if(php_sapi_name() !== "cli") { // code inside /site/ready.php }

For a field that can contain multiple images, the value of that field is always going to be a type of array. So you'd have to either check to see if there are any items in the array, or try to retrieve the first time like Soma did. Here's how I usually check if there are any images: if(count($page->images)) { // images here } else { // no images } When it comes to a single image field, you are dealing with just one item that is either set or it isn't (rather than an array). You only need to check if it has a value: if($page->image) { // image here } else { // no image } When you use $pages->find(), $pages->get(), $page->children(), etc., you can also find pages that have a given amount of images. So if you wanted to find pages that don't have any images, you could do this: $pages->find("images.count=0"); ...or pages that have one or more images: $pages->find("images.count>0");