Leaderboard

@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.

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/

@AndZyk, I don't think this is entirely accurate. Maybe things have changed since I last read the thread but below is the quote from @ryan with respect to his thoughts on a layout / page builder: https://processwire.com/talk/topic/25129-weekly-update-–-12-february-2021/ So, it is not a matter of lack of interest but more about 'lack of expertise', albeit with willingness to support it on the PHP (ProcessWire) side ?. By the way, I could have offered to take lead on this but until a certain module is released (getting very close now! ?), I don't have much time for anything else ?.

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.

Hello @Fokke, thank you for the teaser of your module. I am exited to see more of it. Since @ryan doesn't seem to be interested in developing a layout builder solution, it is nice that somebody else gives it a shoot. If your teaser video is ready, feel free to mention me. ? Regards, Andreas

Make child pages of page beeing edited selectable in a page field named: nameOfTheField $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'nameOfTheField') { $event->return = $event->pages->find('parent=' . wire('input')->get->id); } });

I made this post yesterday:

Try adding a backslash prefix in front of the class namespace use \Mautic\Auth\ApiAuth; use \Mautic\MauticApi;

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!

Don't know if anything changed since 2017 and just found this post by coincidence but wanted to show how this can be done easily now in 2020 ? $wire->addHookAfter('ProcessPageEdit::getSubmitActions', function(HookEvent $event) { $actions = $event->return; $actions[] = [ 'value' => 'foo', 'icon' => 'check', 'label' => 'foo', ]; $event->return = $actions; }); The value of the clicked submit action is stored in $input->post->_after_submit_action (you can hook Pages::saved or ProcessPageEdit::processInput)

@Peter Knight Alright, I found the code-bit I mentioned before:

I guess it's just CSS? a.InputfieldRepeaterAddLink.InputfieldRepeaterMatrixAddLink.InputfieldRepeaterAddLinkInit[data-type="3"] { font-size: 0; width: 150px; height: 100px; display: inline-block; background-image: url(https://via.placeholder.com/150); background-repeat: no-repeat; } span.ui-priority-secondary { display: none; }

Just for the record, since it's closely related to this thread, there's a pull request in GitHub about SQLite support (opened back in May). There are quite a few changes and most likely it isn't in sync with current dev branch (it's based on the master branch), but still works as a nice proof of concept for SQLite support. If any SQLite user here is able to get that one running and could run a few tests to see how well it behaves (the questions Ryan asked in his comment to the PR, like how well selectors work etc.) it would be interesting to hear.