Leaderboard

This week I've had to work on a client project (and that continues for the next week or two), but also have some good progress in the next development branch version of ProcessWire (v3.0.171), which includes the addition to two feature requests: The Repeater Fieldtype (and likewise RepeaterMatrix) was updated to improve support for the "depth" option by introducing something called "family friendly mode". This makes the "depth" setting behave in a manner where items with more indent are considered children of items with less indent (parents). So when you click and drag to move a parent item, it brings along the children too. This works whether changing the location or the indent of the parent. In addition, it enforces the parent/child relationship so that there can't be more than one level of indent between parent and child. So you couldn't (for example) have a parent-to-grandchild relationship in the repeater items. A useful case for this is when using repeaters in page builder contexts, like those Jonathan Lahijani demonstrated with RepeaterMatrix. In fact, the settings in this "family friendly" mode were his idea. More to come here too. To enable "family friendly mode", go to your Repeater or RepeaterMatrix field settings and make sure the "depth" setting is greater than 1. When greater than 1, the family-friendly option will appear as a toggle you can enable. The other thing added to the core this week was a FieldtypeDecimal module that has been requested for awhile. I was planning on making it a setting of FieldtypeFloat, largely to avoid interfering with the existing 3rd party FieldtypeDecimal module. But a few people indicated they'd prefer it to be separate. After testing on an installation that already had the 3rd party FieldtypeDecimal installed, I found it didn't cause any problems, so that alleviated my concern. To be safe, the new core FieldtypeDecimal module uses the same exact setting names as the 3rd party one, so that hopefully they should remain compatible. In my case, I found that deleting my /site/modules/FieldtypeDecimal directory, and then doing a “Modules > Refresh” enabled the core one to take over with any existing decimal fields. However, until we have reports that the same works well for others, I would suggest backing up and confirming it yourself to be safe. It's not often we intentionally introduce module name collisions, and I don't think we've ever done it in the direction where a new core module overlaps with an established 3rd party one. But in this case, it does seem to facilitate the transition a bit. That's all for this week. I've been enjoying and am looking forward to continuing with our roadmap discussions hopefully next week. Have a great weekend!

Here is the first very early concept of a Page Builder. As per the conversation in the 'ProcessWire beyond 2021' conversation, I set myself a challenge to make a clone of YOOtheme Pro's Page Builder. This was mainly spurred by @Jonathan Lahijani's excellent overview of ideas of a page builder for ProcessWire. This is still in very early stages and I am not really sure where it is headed. I would like to hear the thoughts of like-minded persons ?. I would especially love to hear from @Jonathan Lahijani, @szabesz, @AndZyk and @flydev ?? please. Concept The page builder in its current state is a Fieldtype + Inputfield supported by other behind-the-scenes Fieldtypes without Inputfields. There are no hidden or extra pages in contrast to Repeater Matrix. All values are stored in the Page Builder fields for the page being edited. The fields do not store values as JSON. Definitions for elements, rows, grids, etc as stored as JSON. Currently, for storage purposes, 4 datatypes are supported - Text (HTML), images, plain text and headlines. From a storage perspective, the latter two are one and the same. Just texts with different 'schemas/definitions'. More on this below. The fields are multitype fields. This means one page can hold multiple texts, allowing for repeatability. Similar datatypes are stored together in one field/table. For instance, there is no reason why a (future) URL element (datatype) should not be stored in the same table as plain text. At the database level, they are both just texts with similar requirements. At the processing level, URLs vs other plain texts (headlines, etc) are handled differently (validation, sanitisation, etc). Each 'element' represents a row in a table for most types (e.g. slideshows are slightly different). Querying and access of field values is via the main Fieldtype - FieldtypePageBuilder. However, the supporting Fieldtypes can be also be accessed and queried individually, if one wishes, using normal ProcessWire selectors. The supporting Fieldtypes, if such need arises could easily become custom tables instead (but best to keep them as Fieldtypes - easier querying with selectors, etc). It is totally CSS-agnostic in relation to frontend output. You bring your own CSS. In the preview, you can also use your own CSS. In the frontend, you can choose to output raw values as you wish or use inbuilt render methods to render the whole layout for you or to render the value of an element as per its tag definition (e.g. headlines as h2, h4, etc) where applicable. Fully multilingual (although the editing UI not yet implemented). Issues The main issue is the real estate needed for InputfieldPageBuilder. Any such page builder would require the whole width of the window. As you can see from the screenshot below, this obviously throws things out of kilter with respect to the ProcessWire page edit UI, in any theme (I believe). I am not a designer so would love to hear from you about possible solutions. My current thoughts are: Modal Open the page builder in a modal for editing. Pros Would allow for use of whole real estate. Title and other fields would not be in the way. Cons Editing in modals can be tricky? Other..? Process Module Pros Solves the real estate issue. Cons Disconnect between the page being edited/created and the page tree. Screenshot No attempt has been made to theme it as per any current ProcessWire theme (that I know of). This was a quick and dirty-ish clone of YTPB. As stated, however, the current ui is not acceptable as an Inputfield for, mainly, real estate reasons. Video Demo This is a demo for the Page Builder app outside ProcessWire. Thoughts? Thanks. PS: I currently have no time to continue working on this (Padloper, etc..)

@ryan and others ? Sorry I'm a little late to the party. I just wanted to share my view as a designer on an update of the core default admin themes and future branding of pw in general. This is just my opinion, and I'm aware that this can be a very subjective topic. I just want to contribute to the discussion. I really like that PW gets out of the way when it comes to designing/developing a website. It's like an unopinionated frame around my projects. The branding of PW in contrast seems very loud, opinionated and not very serious. I would enjoy a more professional/reduced color scheme (black and white and maybe one additional color). I wish the default admin themes and UI would act more like a neutral frame/canvas for the content. The future will probably be more about frontend stuff that gets rendered inside the backend (pagebuilders for example), so it would have less of a conflict with the frontend (that might have a lot of colors). Also I would love to have a option for a fixed header that takes less vertical space. While I know that clients love to see their logo, I don't like the Idea to do a custom branding of the backend based on the CI of the client (the client CI, logo and colors might not be working in an UI context). Instead I would prefer a solid default UI that gets out of the way. Another area where the branding and use of color gets in the way is on the showcase page of the PW website. The websites/projects presented here would benefit from a more neutral background (e.g. white, light grey, black). Imagine a museum where all the artwork from different artists and contexts, would be presented on a blue wall instead of a white wall. I recently released my own admin theme, which follows some of the ideas mentioned here. Maybe this can be an inspiration for a future default theme. Please don't take this the wrong way. I really appreciate all the work that goes into PW and this amazing community! I would love to know how others feel about this!

WOW! This is incredible! I think this idea really has legs and you've proven it can be done in a ProcessWire way. I would like to contribute in any way I can... ideas, styling, testing, financial. I would 100% use this on multiple projects if it could be developed further. I hope you are able to see this project through as well as Padloper. Please let me know how I can help.

Nope ?. This is all handcrafted using Vue JS + TailwindCSS + custom JS + some drag and drop library. I sometimes use vanilla JS for drag and drop but didn't this time. I have never used grapejs. You are wrong in your assumption ?..., at least in the context of what I am developing here. We are managing content; we are just not using "traditional ProcessWire inputfield interfaces". The app runs in __render() method of the inputfield. Saving is via ajax but that can be changed to form submissions with page reload if one wanted to (not that I would want to do that myself). All my responses below are with respect to this Page Builder. Wrong again. Jessica White's data actually lives in the database. Still wrong. Jessica's marital (or any other of her attributes) status lives in the database. It is retrievable via the API and editable in the app GUI...all the CRUD goodies. You update it once and it is reflected everywhere that data is used, both live as you are editing and once you save your edits. That's what is happening in this builder as well. You can choose anything. Literally, anything from the system. It's just a matter of requesting it via the API and getting back a response from the server ?. It's not shown in my demo but you can even do Page Reference fields. All data requests by the App request are vetted on the ProcessWire side (permissions, validation, sanitising, etc). Neither have I but it looks like your brief experience with it wasn't great? Maybe it was a misconception? A quick Google search tells me grapejs can work with a database backend. We can and we do....? Examples include Padloper 2, this Page Builder and other Vue JS apps I have built (unreleased). By smart content I assume you mean data stored in the database, be it in ProcessWire fields or custom tables. All the data you see in the demo of this Page Builder are stored in ProcessWire tables (Fieldtypes). You can access this data using the API and carry out any CRUD task using the usual ProcessWire API.

First off I would recommend re-reading this part of the hooks documentation: https://processwire.com/docs/modules/hooks/#conditional-hooks. If we take a closer look at your second code example, here's what it's trying to do: Add hook after the saveField() method of the Pages class has been executed ... but only if the first argument to saveField() contains string value "snipcart_item_image" Now, if you look at the definition of Pages::saveField() ... * @param Page $page Page to save * @param string|Field $field Field object or name (string) ... you can see that the first argument is actually a Page, not a string. In other words your condition doesn't really make sense here — what you're probably looking for is the second argument, which is the name of the field as a string or Field object. The conditional hooks documentation explains how to access a specific argument: $wire->addHookAfter('Pages::saveField(1:snipcart_item_image)', function($event) use($item) { Note: as you can see from the second @param definition, saveField() can receive either a string or an object. If there's a way to target both with conditional hook format, it's something I'm not aware of. I'm afraid that you're making things a bit complicated for yourself by trying to use the conditional hook syntax; it's an advanced feature that has it's use cases, but it's often easier to just hook into some method and "return" if the arguments are not what you are looking for. But, alas — there's a potentially much bigger problem here: when you save a page, ProcessWire doesn't call saveField() for each field individually. I don't know in what context you're trying to make your hook work so I can't say right away how you should write this hook, but I'd be interested to know if you gave my earlier example a try... and if so, did it do anything? If you're trying to change the value right before the page gets saved in the admin, you most likely should be hooking into Pages::saveReady. Or you could hook into Pages::savePageOrFieldReady if you also want to catch single field saves ? Edit: keep in mind that even if you hook into Pages::savePageOrFieldReady, the field name (second argument for said method) is only populated if a single field was saved. The value is not going to be there if an entire page was saved. If you take a look at my previous reply and change it the code sample to use Pages::savePageOrFieldReady, it should actually be pretty close to catching both "full page saves" and single field saves.

Yeah thanks. I am already using his latest release (with that fix) here. I'll commit the changes sometime soon. I just need to spend a bit of time revisiting the changes I made for Pete, and also revisit everyone's suggestions for improving the settings page, and also Robin's "Shortcuts" panel idea. I'll probably commit all these things together - maybe on the weekend or early next week.

Hey @kongondo! I know this project is at a very early stage, but it does seem promising. I also like your ideas about the data structure, though I'm not entirely sure I fully get it yet (might require a more hands-on example of the data vs. schema vs. database structure part). At this time I really only have one question: do you currently see this as a potential commercial module, or something that you would consider open sourcing? I get that it's very early, and I want to stress that there's absolutely nothing wrong if you think it'd be better suited for commercial release. That being said, I see this kind of tool as a pretty massive undertaking, and thus something that could benefit from larger community involvement. I for one would definitely be interested in contributing in some way, assuming that would be an option. Anyway: a very interesting project — keep up the great work! ? Just wanted to point out that I don't really see this as an issue. If we take WordPress as an example, they've always had UI's that (for similar reasons) step out of the regular Admin: Customizer from the core, for an example, as well as various plugins (Ninja Forms has a very distinctive full page form editing GUI), and in my opinion that works just fine.

Sure, the admin theme could make this sort of thing easier. But it's not excessively difficult to tweak the styling now if a person is motivated. When people make comments or requests about the admin theme styling (not just in recent topics but in the forum generally) I'm never sure if they realise that they don't need to wait for Ryan to do something in order to get what they want. It's CSS101 stuff.

I use PW on multiple websites that I admin and write content for. I'm therefore often updating my PW sites, either by writing new content (most commonly) or doing template coding, or coding other features such as logic-specific ad display. Based on my experiences across all my websites, here are my thoughts on the OP topics: Flexible content or page building - I've never needed it and can't see myself using it in the future. I already have a few things set up like footer content where I write footer-left, footer-middle, footer-right content as the body of non-templated pages, and I simply code my footer to display the body content of those 3 pages using what's already in the PW core and API. Easy, and perfect. I don't see any need for anything beyond that, such as flexible content or page building (for my purposes at least). I absolutely love the CKEditor ? and I'm not sure why or what use case anyone would want for a block editor (in fact, a block editor is a reason why I moved away from WP to PW - the WP block editor was slow and frustrating and I could achieve way faster content creation with PW). I have a few page templates where there are multiple "body" contents, and I simply use additional "body" style fields in those templates. I understand the PW CKEditor is not going to be replaced, so I'm not worried there, but I'm not doing anything that ever needs more than defining fields and displaying them with a template. Admin theme improvements - a really quite massive "pain point" for me across all my sites is the inability to order the page tree in PW admin in a way other than the default ?. When you have 90+ pages of content (which I do on several of my sites and hope to on the others later), not being able to specify a default order is very frustrating. Sure, for a 20-page site, no big deal. For anything more, it's quite hard. In particular, I'd like these 2 features: It seems both features exist, although I'm struggling to find a way to combine them. The ability (or the default) to be most recently created page at top (not the oldest created page which it seems to default to - it's basically in the reverse order of what I want.) And yes, there is the "recent" menu available in Admin, but that's not as helpful as you might think. [SUBSEQUENTLY EDITED - This feature already exists in the core! - see comment below by @adrian ] The ability to put some "sticky pages" always at the top of the page tree. For me, this would be regarding specific to ads I want to show/edit frequently, but I expect there are other people with other use cases who want certain pages to always appear at the top of the page tree. This feature is of equal or higher importance to me than changing the default order. [SUBSEQUENTLY EDITED - This feature exists in the AdminOnSteroids module - see comment below by @adrian - however, I am not sure whether or not this feature can be used with a specified sort order as mentioned in the previous point] File/media manager and more file sharing options - Yes, BUT ONLY if we can somehow specify a different alt field for an image each time that a central image is used in a new page. If that's not possible, then I'd rather stay on the default of having to re-upload the same pic separately for different pages (which is what I'm doing now anyway). For me, it's crucial that the image if used freshly in a new page, has a fresh image alt tag. Because you might want to re-use the same pic for slightly different reasons in each case. External file storage - I don't use this and can't see myself ever using this, although I can see how others might want it. I purposely like having everything on one host/location. Live preview and auto-save: Auto-save is certainly nice, but ONLY IF it does not over-ride a user-specified save. I sometimes change page content around, but then decide I don't want those changes, so I purposely don't save it. In this case, auto-save could cause me big problems if it saves the page when I did not want it to. On the other hand, I've lost content before by my own fault, by forgetting to save and then going away and my session timed out after I came back. So I certainly could use autosave as long as it saves the page in another location so as not to overwrite an existing page. Preview options are already very rich, with "new tab" and "modal" options that I use frequently, so I cannot see a use for live preview for my use cases. The existing previews are pretty amazing already! That's it from me. All of that said, I love PW, and admin-ing my sites is a breeze thanks to PW and its wonderful community of people!

Necessary disclaimer: just like you, I also mean zero disrespect, and I get that this is a topic where opinions matter, and so on ? I agree with your point about that the admin should stay out of the way, and I do also share some of your concerns regarding current admin theme. But that being said, I must admit that I quite like the current colour theme: it's pleasant, professional, not at all childish (in my opinion), and brings just the right amount of personality to the theme. Also I personally find a black/gray/white colour theme rather boring — unopinionated for sure, but also boring. On the other hand one thing that I do dislike about Admin Theme Uikit is the noise created by separator lines. And, as it happens, your theme suffers from exactly the same issue: to my eyes it's still way too noisy. Opinions, right? ? Anyway, this is a topic that is definitely worth discussing further. Also Ryan has been extending our ability to customize and build upon the Uikit admin theme lately, and I'm quite interested to see where that road takes us. I feel that with some additional tweaks and customization options it could become a solid starting point. And if that could finally resolve the age-old problem with modules having to support multiple admin themes that all work differently, all the better. (Loosely related note: I seem to recall that there was some reason why Tailwind's original gray colour set was blue-gray. For whatever reason that type of thing works better for my eyes. There are probably better examples, but Craft CMS makes extensive use of gray/blue-gray/blueish colours, and their admin looks very pleasing to me. It's not opinionated, but it's also not impersonal or boring.)

@adrian david pushed a fix: https://github.com/nette/tracy/commit/cffea9d4a625eccc870144273e60cb131edd5d40

Here you go...took longer than planned.

@ryan, what follows is only about the idea of taking Repeater Matrix in a Bard-like direction for long-form content, as referred to in my earlier post. I don't have an opinion on the "builder" idea because it's not something I or my clients need. Looking at the Bard video you can imagine it as rich text field (i.e. CKEditor or maybe Editor.js) with Repeater Matrix elements distributed through it. You can add new Matrix items and edit them within the rich text interface. Here's a mockup of what a hypothetical "Repeater Matrix Bard" field might look like: But as far as I can see such an interface would be very difficult to implement. You'd have to somehow replicate the Matrix item interface inside CKEditor or Editor.js, maybe as plugins. [Actually, as soon as I made this mockup I suddenly had another idea for how it could be done, but I'll come back to that at the end of this post]. So when I first started thinking about this idea (back when Bard was introduced to Statamic) I wrote that option off as too difficult and turned to working with the existing CKEditor and Repeater Matrix fieldtypes. Of course this was going to involve compromises and the result was never going to be as slick as the Bard interface. My idea was to use placeholders for the Matrix items within the CKEditor field, in the form of CKEditor widgets. Each widget would correspond to a Matrix item, and a Textformatter module would replace the placeholders with rendered Matrix item output when the page is rendered for the front-end. This is easy to do via $matrix_page->render(). First I experimented with keeping the Matrix field visible in Page Edit, with the Matrix field in accordion mode. Hovering a widget placeholder in CKEditor highlighted the Matrix item (to help the user work out which placeholder is linked to which Matrix item) and clicking the widget scrolled to and opened the Matrix item for editing. But this takes the user away from CKEditor and disrupts the writing experience a bit too much. So then I changed to hiding the Matrix field in Page Edit so the user only sees the CKEditor field. When they add or edit a Matrix item a Magnific modal opens where they can work with the fields within the Matrix item. I added a dropdown to the CKEditor toolbar to let users add new Matrix items/widgets within the CKEditor field. This works okay but it's not fantastic - the main dissatisfaction I have is that my widgets are rather basic. This is because I'm no expert when it comes to CKEditor and its widget system. But looking at example widgets in a tutorial it seems that it's possible for them to have richer layouts and items like images (icons?) within them. I'm using the title attribute tooltip to show the text from the Matrix item header, but it would be great if the widget contained an icon corresponding to each Matrix type (sidenote: we really need a larger selection of icons available in the core) and perhaps some of the item content. Maybe the developer could specify code for each Matrix type that would render the HTML of the widget? I fear this is all beyond me but if you're interested maybe you could explore the possibilities of this? Or see if a similar approach would be more easily accomplished in Editor.js. A screencast of the system in action: Because the user doesn't see the Matrix field it would be possible for items to become orphaned there after their corresponding widgets are deleted from the CKEditor field. But it would be good to keep orphaned items for a short while to serve as disaster recovery. So perhaps orphaned Matrix items would be automatically removed after some period of time. Coming back now to the mockup screenshot and an idea of how to achieve it... What if there was a special rich text Matrix type available to be added to any Matrix field? This would consist of a CKEditor field in inline mode (to reduce the distraction of the toolbar) together with (optional) Files and Images fields to allow for linked files and embedded images (edit: it would be good if somehow a single Files field and a single Images field was shared between all rich text items). This matrix type would render differently within the Repeater Matrix inputfield - it wouldn't have a permanently visible header and the Files and Images fields wouldn't be permanently visible either. Instead a special toolbar would appear when the rich text item was hovered (probably at the bottom to avoid clashing with the CKEditor toolbar). This toolbar would include the standard Matrix icons (sort, copy, toggle, delete) and icons that make the Files and Images fields visible for when those need to be accessed. But when nothing is hovered it would render just as the rich text portions appear in my mockup. It would also be nice if the Matrix "add new" links were replaced by a "+" icon that appears when you hover between existing Matrix items, like in Bard. That would reduce some clutter in the inputfield and allow new items to be inserted in whatever position is wanted. This approach would not be quite as nice as a single rich text field containing Matrix items. Because I think the concept of multiple text fragments is not what users imagine for a long-form article. And it would result in more pages behind the scenes, although that probably isn't a big problem. But it seems like it might be relatively simple solution to the Bard idea.

It would even be easier if the css "framework" was built upon css variables, eg: https://www.gethalfmoon.com ("easy dark mode" is also built in). That's what I call a few lines of code: https://www.gethalfmoon.com/docs/customize/ No setup, no build process, only a few lines of code, and there is no need to talk about color preferences in that case ? It has been an optional setting of the UIkit theme right from the beginning. It is easy "not to use it" ? Anyway, I add the client logo and client colors so that I can tell apart the admins I have to work with... so "branding it" is not just for the client's sake but my own, too.

Exactly. I doubt we're going to all agree on all details of how the admin theme should look. But I hope that nobody among us is sitting there gritting their teeth because the admin isn't looking how they want it to look. Because we're all website designers/developers and we know how Cascading Style Sheets work (especially the cascading part). And it's not a difficult task to add your own CSS to the admin and override the styling of elements as you like. The admin theme markup changes very rarely and so you can spend half an hour working out your overrides for colours or whatever and then reuse those styles on all projects going forward. If you compile your overrides from SCSS/LESS then it's really easy to tweak colours for specific projects via variables.

Are you doing something like adding the Justify plugin yourself? If so, you don't need to do that because it's already included in PW's InputfieldCKEditor by default. You can specify the individual justify toolbar items you want:

Definitely ?. This was for demo purposes only. My plan is to develop my own using Affinity Designer...at least the easier ones. However, I don't know how much different I could make them look compared to YOOTheme's. Thanks. Will have a look. By the way, I have been keeping an eye on this one: https://heroicons.com/ ...by the folks at TailwindCSS

I like the idea of editing in a modal (full screen to where it almost feels like its own page), or perhaps a dedicated edit page outside of PW's page editor. I think having it inline as shown in the screenshot looks bad, not to mention the lack of page width. If going the modal route, the "esc" key should not close the modal, but maybe a close button that the user has to click. Also, I would imagine the icons are copyright YOOtheme, but this library is available for commercial use for free and a quick look seems to show they have similar icons: https://github.com/vaadin/vaadin-icons

Found the solution. Thanks @teppo for your help. Your suggestion gave me the clue I needed. Here's the fixed code: $results = ** a somewhat complex search that returns a pagearray ** $perPage = 20; $start = ($input->pageNum -1) * $perPage; $results->setLimit($perPage); $results->setStart($start); if ($input->get->f) $input->whiteList('f', $input->get->f); if ($input->get->l) $input->whiteList('l', $input->get->l); if ($input->get->a) $input->whiteList('a', $input->get->a); if ($input->get->t) $input->whiteList('t', $input->get->t); $pager = $modules->get('MarkupPagerNav'); $pager->setPageNum($input->pageNum); $pagination = $pager->render($results, [ 'nextItemClass' => 'next', 'previousItemClass' => 'previous', 'currentItemClass' => 'current', 'separatorItemClass' => 'separator', 'numPageLinks' => 5 ]); foreach($results->slice($start, $perPage) as $item) { // render the thing } echo $pagination; Basically all that was missing was that setStart() call. Makes sense, as usual.

Crazy ? Thx for the clarification!

Hi @teppo. This is a holding response since I am short of time at the moment. You've raised an important issue surrounding funding of modules/remunerating developers, etc that I have been meaning to discuss in the beer garden with the whole community. As it is a broad issue, I would like to answer this question within that broader context. As for this module in particular, I haven't decided yet but leaning toward commercial. That's not cast in stone though given the broader issues I'd like to discuss. I had a feeling this would cause some confusion. I will come back with a detailed answer. For now, just note that schema is used in the sense of defining something, in this case, a column in a DB table containing JSON with the schema/description of that element with respect to layout, tags, etc. Hope I haven't confused you further. Excellent! Thanks.

Exactly my thoughts!

I saw this video pop up in my feed, and I was really happy to see it as there are folks who are comfortable with this way of managing content. Very exciting project!

Good day, @teppo! There is a rather empty Patterns and practices section in the docs. I got a suggestion for what to put there. Or should it be in examples? Anyway... Could you describe how does the template with a controller handle get variables and/or url segments? I do not quite understand that, as I have no prior experience with general purpose frameworks.

I found what I was trying to remember. Try what is said in this thread, last answer, it seems it's a related issue (I have the same one in a setup). Direct answer: Modules order in the db.

I was also thinking of mentioning it, however, Unipoly seems to implement a lot "more features" and its more advanced, soon to be released new version can be expected in weeks: http://triskweline.de/unpoly2-slides/#1 Note, that while these libraries are similar, but they are far from being the "same". Unipoly is opinionated while HTMX "is not" (at least not that much...), which is a big difference. However, Unipoly offers a lot more out of the box, so I'm myself thinking of using Unipoly v2 in the future. Unipoly v2 also – optionally – supports Bootstrap which is good for even more rapid development. I'm not a big fun of Bootstrap, but Bootstrap 5 and Unipoly 2 looks like a good combo, so I will definitely find some time to test them together in the near future.

It would be great if Wireframe got it's own Module-Specific Support forum.

It worth to mentions https://htmx.org/ the successor to intercooler.js.

The work on the project got seized so no the need is no longer valid.

My bad, I figured it out. In order to work the class only needs to extend WireData. So the following example works. <?php class MyClass extends WireData { public function ___someFunction() { // Do something } } // ready.php $this->addHookBefore('MyClass::someFunction', function($event) { // some customization });

@Robin S, bouncing on your mockup, I'm not sure if mixing permanent / appear-on-hover UI is good for the end user. To me, what seems to be the issue is the visual space PW's UI takes and I think it could (partially) be solved by allowing (in the field's settings) to remove the label + padding around it. Mixed with the inline CKEditor, it almost looks like your screenshot, except that it's still clear we're still dealing with "components" that the user can move around.

Another, somewhat similar story: https://medium.com/vimeo-engineering-blog/its-not-legacy-code-it-s-php-1f0ee0462580

Hi @johnnydoe Probably you should try to change session name for one of your installation in your site/config.php file. https://github.com/processwire/processwire/blob/master/wire/config.php#L217

Wow - totally missed the discussion here!!! That's why the page-builder-part in my post in the newer news-thread was somewhat offtopic... I'll reference it here and throw it into the discussion ? Let me comment wildly on some statements first - I'll try to summarize that in the end... Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. Please. No! I've done some research before starting with RockMatrix and editorjs was an option that I looked at. I decided against that approach. I can't really explain, but I had the feeling that this is some 3rd party concept and not the way ProcessWire would do content management. I had the feeling, that if we used something like editorjs we'd need to develop a totally new concept for all the content blocks. But WHY should we do that? WHY would that be better then using existing ProcessWire concepts? We have everything we need (speaking about Fieldtypes and Inputfields) and throwing that away would not be clever imho! Take a look at my matrix setup: First block is a headline - a regular PW "title" (text) field. I'm just removing the inputfield's header (we can already do such things easily via hooks!) Second block is a ckeditor field - similar, we remove the header and allow just a subset of usual ckeditor buttons. For example the image button is removed, because images are inserted via their own custom blocktype (gallery). That approach has several huge benefits that by far outweigh the drawbacks: Blocks are PW pages, this means you can do all kinds of PW magic with them. Think of hooks, think of custom page classes, think of doing listings using RockFinder (for example I'm using RockMatrix to hold invoice items having a description, an amount and a price and I can simply query all those items with a simple find call like "template=invoiceitem, year=2020") etc.; What about Multi-Language?! How would one build an editorjs field that properly reflects the internal PW multilang system?? What about file uploads? We know that files need pages and corresponding folders... We use existing, proven tools (fieldtypes/inputfields) Exactly. That's what I've built my matrix field for and that's what I need in every project. @Autofahrn has also put a lot of work into that topic! That sounds great. My matrix field does not allow nesting and showing items side-by-side or dragging dem from one block to another. But so far this has not been a problem at all! Quite the contrary. My clients love the ease of use. Even Non-Tec people can build great looking sites within no time. See these examples: https://www.kaumberg.gv.at/naturparadies-kaumberg/wanderwege/bergsiedlungsrunde/ https://www.kaumberg.gv.at/gemeindeamt-buergerservice/aerzte-therapeuten/gemeindeaerztin-dr-alexandra-hutsteiner/ https://www.kaumberg.gv.at/gemeindeamt-buergerservice/gemeinde-mitarbeiterinnen/ And using the same content blocks for a totally different topic: https://www.kaumberg.gv.at/gastlichkeit-tourismus-betriebe/betriebe-in-kaumberg/ This is SO flexible. If they needed any new content type (eg Youtube Video) I'd just add another matrix block and they could add videos everywhere on their website. I'm avoiding the PW admin more and more. I'm doing most of my work in RockMigrations nowadays, because it turns out that this often is quicker and less tedious than clicking around through the admin, replicating the changes on dev/live, rolling back changes manually etc etc.; Using migration scripts on the other hand I have my code in GIT, can just copy over parts as needed (git pull/git push), or simply use MultiCursor in my IDE to change the "columnWidth" setting of multiple fields at once (does anybody want to count the clicks necessary for changing 3 fields' columnWidth setting in the PW backend? ? ). I don't want to say that the PW backend is bad. Not at all. I've even wondered what @LostKobrakai is talking all the time when he showcased his migrations module back then, but I want to say that the PW backend might be really nice to have for simple use cases and beginners, but it is definitely a burden when dealing with advanced setups (think of automation, CI/CD, maybe multiple people working on one project at the same time, etc, etc). But I'm not voting for editorjs route here either! When I looked at editorjs and how plugins are built, that was a whole new world. I don't know much about all those modern javascript related dev tools and I don't really want to learn them, to be honest. Maybe that's the problem and I'm not being fair. But creating a new matrix block in my case is simply creating one single PHP file that extends \RockMatrix\Block, that's it... And I'd love to see such a setup in the core or a professionally supported one as pro module ? Sounds great ? This gets totally easy when using RockMigrations!! That's another reason why a solid migration system should definitely be part of the core! Everything would benefit a lot from such a core feature - module development, devs developing sites and reusing parts, etc... That would be a dream. Though I say again that I much more prefer defining things in code. Building user interfaces can be soo hard, while adding a hook can be so simple, efficient and clear. For example defining allowed blocks in RockMatrix is done like that: $wire->addHookAfter('RockMatrix::getAllowedBlocks', function($event) { $field = $event->arguments(0); $page = $event->arguments(1); if($field->name !== 'rmtest') return; $event->return->add([ '\RMDemo\Headline', '\RMDemo\Markup', ]); }); Imagine you had to build this as GUI... Sounds not too complicated, because you could use an ASMSelect field that lists all blocks and makes them selectable and sortable. But what if you'd want to show some blocks only to some special user role and hide them for others?! A simple if-statement in the hook. Nearly impossible to build as GUI... *emotional* Please, don't ? I've created a video that hopefully helps you all to get an impression: I think it would be helpful to clarify WHERE this discussion should happen upfront. In the forum? Via e-mail? Opening an issue (I think that's not the right place)...? But yeah... thinking about it I can imagine that monitoring all those channels is not easy and must take a lot of time...

Your points about this are all completely fair. It's up to you to integrate or reject the changes a PR does. Currently the latter however does not happen in a manner visible to the creator of the PR or anyone else looking at the PR. So they just stack up looking like they were never looked at. If you consider something not possible to be added (or even not possible in the near future) everyone is better off if the PR would be closed with a short note of the reasoning. PRs do not age well and it's better to close them than letting them sit until no longer mergeable. The closed PRs (and issues) are still searchable, so if people to their due diligence they'll see that things were rejected before, find related discussion if attached, …. If you're not happy with the code for a given change you can also help people come to a version you're happy with maintaining without needing to go code it yourself. This does even work for issues. One of the most encouraging responses to issues I know from other OSS projects is "Sounds good. PR welcome.". I rarely see that as a response to bigger feature requests, but on smaller incremental things making parts of the project better it's a good way to move the burden of actually fixing something off of the maintainer themself. If a PR is not of that kind it's totally fair to close it with something like "This is to big a change and needs upfront discussion before consideration.". You don't need to take the time of reviewing PRs in depth, when you already know you'll not merge from just the title/description/amount of changes/…. So in conclusion: Without a response from your side a open PR is dead weight in the context of the community helping you improve processwire. Someone did some work and now it's stuck. Even if the response is negative it'll give anyone involved context either to adjust and be fine with things not being added or next steps to get things integrated either by starting a needed discussion, changing the code or implementation or whatever else needs to be done before it could be merged. Given the fact PRs don't age well I also feel response should be reasonably timely – even if the merge actually happens at a later time. Take a year and the PR creator might have moved on or worked around it, the underlying code changed in the meantime so the PR is no longer easily mergeable, but the issue fixed by the PR might still be present. I know this well given I have two open PRs for processwire from 2017 – one small fix, one not as small feature. I hardly use processwire anymore by now.

I agree. The way I see it, if there's a low level SQL type that supports given functionality, there should be a fieldtype that corresponds to it, however the ProcessWire specific fieldtypes are there for when additional functionality is required that can't be supported directly through SQL. Speaking of that, it may be a bit of a limited use case, but I've wondered a few times about adding geometry fieldtypes and adding geometry selectors. There's already the FieldtypeMapMarker, but this is using just standard float fields in mySQL, while mySQL and MariaDB have support for geometry datatypes and spacial indexes, and there are times it would be nice to be able to do a query and return all the places within a given distance. I already hacked the FieldtypeMapMarker a bit to allow adding KML overlays exported from Google Earth, or mobile tracker apps, but there's certainly a lot more that could be done to give geospatial data first class treatment if enough people use it.

That's it. I just don't want to let my clients have the freedom to play with styles, at least not within boundaries I can manage by code. It would be such a pain if I have (as accountable/developer of the project) to fix the mess made by a client inside the editor. Moreover, from my experience, if I give a client some sort of freedom (especially inside the creative side of things) then he will ask me more and more (Can I do this? Can you add this for me?). The editor become their toy, and the front-end the crappiest as ever. On the flip side of the coin I would really love if we, as developers, could have the ability to let editors manage our pre-made components in a more compelling/modern visual way.

I agree that something like the YOOtheme Pro Builder would be the way to go. Maybe the next admin theme could be implemented form scratch, along with ProcessWire's frontend content builder, based on something like Alpine.js perhaps? See: https://www.youtube.com/watch?v=M3fY0E60cM0 Some sort of reactive JS library is surely needed for such a builder, especially if more that one person start working on its implementation. However, the issue is that locking the admin and the builder to the future of a JS framework is problematic, to say the least.

In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits. I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions. ( @ryan ) (note: there are many more considerations when it comes to a page builder, but if there were some sort of css-framework agnostic layout tool, that would solve the biggest page builder problem) Please share your thoughts.

@Robin S I've pushed an update to the dev branch that makes it simpler to extend AdminThemeUikit. As far as I can tell, the reason you got the result you got before is because your admin theme was likely missing all of the other files that go along with an admin theme (?). So the reason you can't just extend AdminThemeUikit and be done with it, is because the module file is only one part of the admin theme. I've updated it so that AdminThemeUikit is now built expending that you might extend the class, without all the other files. So now you can create an AdminThemeUikit derived module like this: File: /site/modules/AdminThemeTest/AdminThemeTest.module <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } } You'll also need this file in the same directory: File: /site/modules/AdminThemeTest/controller.php <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); require($config->paths->core . "admin.php"); The above would just be the same thing as AdminThemeUikit. But at that point, you can easily override and extend anything from the AdminTheme, AdminThemeFramework or AdminThemeUikit class. For instance, here the same module as above, but I'm extending the renderExtraMarkup() method to add some more markup to <head> to make the primary headline <h1> smaller (not suggesting this would be the right way to apply CSS though): <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } public function renderExtraMarkup($for) { $out = parent::renderExtraMarkup($for); if($for === 'head') { $out .= "<style type='text/css'>" . "#pw-content-head h1 { font-size: 24px }" . "</style>"; } return $out; } }

This has been a relatively common request for me as well. In fact a variant of the media library concept is on my todo list for tomorrow... ?‍♂️? I've found that this becomes more important when a site has more content and more content editors: sometimes it's about not having to maintain a separate media library (in a traditional media library, somewhat like the one found from WP, they would just upload the materials once and then reuse them everywhere with ease), and other times it's about knowing where each material has been used / being able to update it in a central place if it needs to change. In many (most) cases what we already have is more than enough, but regardless, I do run into this type of request every now and then.

Recurring dates / calendar module A big +1 from me for this. A lot of sites need this kind of functionality. The key thing is solid RRULE support in a user-friendly interface. It's really common to have events that occur on a regular schedule (e.g. the first Tuesday of the month for now until eternity) but then occasionally have exceptions where the event is moved to a different day or cancelled for a particular date. The Recurme module had the right general idea but if you take a look at the source code you can see why it's not really scalable and needs a lot of tidying. A robust calendar module is not a simple thing so it would be great to have something that's built to the standard of Ryan's other Pro modules. Flexible content I find that Repeater Matrix is fine for when the content is divided into discrete conceptual and visual blocks on the frontend. It's pretty easy to make the mental connection between "conceptual/visual block on the frontend" and "Repeater Matrix item in the backend". Where it's not so good is when you have a long piece of text that is interspersed with different pieces of other content, e.g. text - image - text - graph - text - pullquote - text. In this scenario the editor/author wants to think of the text as one conceptual unit. Breaking the text across multiple Repeater Matrix items feels wrong, and it's difficult to locate and move paragraphs between the different blocks. For this scenario (which is pretty common now - think of Medium articles or other longform articles containing rich content) the Statamic Bard fieldtype looks like it nails the solution pretty well. The user wants to see a single flow of text with elements floating inside the text that represent the other pieces of content. These floating elements should reveal the content they contain (or at least the type of content) so that the user can understand what is what, but perhaps be edited outside of the text editing interface where that is more practical, e.g. click an element to edit it in a modal. I have actually made a couple of different experimental modules that expand Repeater Matrix in this direction but haven't found a fully satisfactory solution yet. Admin theme I'm pretty happy with AdminThemeUikit and don't think it looks dated. I've said before that there's too much padding between and around elements and the main page heading is way too huge (maybe this is where the "cartoonish" criticism comes from), but these things are very simple to fix with custom CSS overrides. I wouldn't want to see the admin styling change every year and I can't relate to the desire to be endlessly changing the admin to keep up with the latest fads. The admin is a place you go to do work, not to see pretty things. It should be plain and utilitarian, which AdminThemeUikit already is. Having said that, a couple of ideas that would make it easier for those who want to tweak the admin: 1. Maybe there could be more config fields in AdminThemeUikit to let people adjust things like spacing and font size without having to add their own stylesheet to the admin. 2. It would be pretty good if developers could more easily create modules that extend AdminThemeUikit so if they want a customised admin theme they only have to override certain specific methods rather than completely duplicating the module. Right now if you do... class AdminThemeFoo extends AdminThemeUikit ...the admin experience completely breaks so it's not currently a good foundation to build on. And it would be good if there were more hookable methods in AdminThemeUikit so that it becomes possible to manipulate the main menus for instance.

Looks like someone (apparently a single user) has been going around forums and vulnerability databases posting about a ProcessWire "local file inclusion" vulnerability, claiming that in a specific old version of ProcessWire (2.4.0) simply passing "download" GET attribute to index.php is enough to download any local file on the system, including files that may be outside the ProcessWire installation path. This is not a real ProcessWire vulnerability — this kind of argument has never existed in any version of the system. Simply put the report is either fake, mistake, or there could be some custom-built vulnerable piece of code (or other vulnerable software) on the host resulting in this behaviour. We take such claims seriously, however unlikely they may seem, so just to make sure I've just checked parts of the codebase in both 2.4.0 (where this is supposedly occurring) as well as various later versions, and there's zero evidence to back this claim up. I've also manually tested this on various setups, including a brand new 2.4.0 installation, to no avail. (Note: I wouldn't post about this here unless the original claim was relatively widely spread. Just felt it made sense to clear things up.) --- That being said: as one builds sites using ProcessWire (just like with any other system) they need to be careful not to introduce vulnerabilities of their own. ProcessWire is armed with brilliant tools for preventing common vulnerabilities — the selector engine helps avoid various SQL issues, Sanitizer has many tools for cleaning up dirty data, SessionCSRF makes implementing proper CSRF protection downright trivial, etc. — but it can't protect you automatically from every mistake ? More security tips: https://processwire.com/docs/security/.

There are a few problems with that code: Switching $magazine to $page doesn't actually help at all. $page is not defined here either. As I mentioned in my previous post, you're in function context, and in that context you only have access to a) function arguments ($event), b) variables you've made accessible with "use" (currently there are none), and c) global functions. $page is none of those. Another issue is that there's no savedPageOrField method for Inputfield, so Inputfield(...)::savedPageOrField is never triggered — what you're looking for is Pages::savedPageOrField. From your post I assume that you've put this code in the template file, i.e. /site/templates/your_template_name.php? If so, the hook only applies to when you're viewing a page using that template, i.e. it has no effect in Admin. I'm not sure if that's what you really intended, but I'd assume not — more likely you'd want to put this hook somewhere it gets added in the admin as well, so perhaps /site/init.php or /site/ready.php. ... and, finally, even if your code did work, you would've likely ran into an infinite loop: if you hook into page save and save the page, that'll trigger the page save hook, which will then save the page and trigger the page save hook again, which... you know the drill. Pages::saveReady() is often better method to hook, as you can just modify the page values, and they'll get saved soon after (you don't have to call save in your hook) ? In this case something along these lines could work: // hook into Pages::saveReady $wire->addHookafter('Pages::saveReady', function($event) { // get current Page object — in this case this is the first argument for the $event object $page = $event->arguments[0]; // bail out early if current Page *doesn't* have the field we're interested in if (!$page->template->hasField('snipcart_item_image')) return; // ... and also bail out early if the snipcart_item_image field hasn't changed if (!$page->isChanged('snipcart_item_image')) return; // now that we know that snipcart_item_image has changed, set a custom value to another field $page->set('imagecolorat', 'YOUR_NEW_VALUE_HERE'); // finally, populate our modified $page object back to the event $event->arguments(0, $page); }); Note: written in browser and not properly tested.

I know you mentioned docs being confusing, but I'd still suggest taking another look at them — specifically this part, as it explains this pretty clearly: https://processwire.com/docs/modules/hooks/#defining-hooks. To simplify things a bit... the key difference between the first two is that $wire->addHookAfter() works outside classes, while $this->addHookAfter() is how you'd usually attach the hook when you're in a method of a class (i.e. while you're working on a module of your own). $page->addHookAfter() attaches the hook to the current Page object (which $page typically refers to), not all Page objects in general. Important distinction in case you're working with multiple pages and don't want your hook to run for all of them. Not sure if that explains it any better than the docs, but again the biggest difference is just the context in which you're defining the hook (use $wire when in template files, /site/init.php, /site/ready.php, /site/admin.php, etc. and $this when you're within a method in a class) and whether you want your hook to apply to a single object ($page, $pages, or a specific item such as $mypage where $mypage = $pages->get('some_selector')) or all items of a specific type. Most commonly you'll need your own hookable methods when you're, say, developing a reusable module. Instead of tweaking the module on a per-site basis, you'll likely want to keep it as-is and rather make some minor modifications by hooking into it's methods. This way you can easily update the module without having to redo or work around your modifications every single time. On some edge cases you might have a utility function on the site, and then depending on some other event you may want to say that "at this specific instance the method should do something else", so you'd want to make it hookable. Can't think of many cases where that'd make sense, though. I'm not sure what you're getting at here. Is this is just an example of what you're doing at the moment? Either way your hook looks fine to me. Should've read this more carefully. You're accessing $magazine object here, but if this is your entire code, that won't work — you're not defining $magazine variable anywhere. Since you're in function scope, you only have access to the arguments passed to that function, variables you've passed in with "use" language construct, and global functions. Even if $magazine exists outside your function, you'd have to pass it in with function($event) use ($magazine) { ... } That being said, what you're probably looking for is something like Pages::savedPageOrField(). If you take a look at that docs page, there are code examples dealing with changes etc. Or, alternatively, Pages::savePageOrFieldReady(), which occurs right before the page/field is saved (which means that you can modify the values right before they are saved to the database). ... and please let me know if I missed your point here ?

It does, it's just not documented unfortunately. I linked to information about it in my earlier post above. Here is a demo... Page structure: Field settings for subcategory field: "page.category" will be replaced with the ID of the page selected in the Category inputfield in Page Edit, whenever that field changes. The "has_parent" part is just to avoid unwanted pages appearing in the Subcategory inputfield if the Category inputfield is changed to empty (no page selected). Result:

I think @Sérgio Jardim's suggest may be the best solution... create a PageReference field 'property_permission' then add it to the user template so when a user is added the admin can set which pages they have access to... if ($user->property_permission->has("id=$page->id") || $user->property_permission->has("id=$page->parentID")) Thoughts? Also while anyone is here... can you hook into a new user creation? Preferably a hookAfter?

There is limited (and undocumented) AJAX 'dependent selects' support built into Page Reference fields. You must use the 'Custom find' or 'Selector string' option for defining selectable pages, and reference the source Page Reference field (that exists on the same page) using syntax like this: parent=page.page_reference_field_name Based on testing I have found: It only works for Select, Select Multiple or AsmSelect inputfields It does not work inside a repeater item

That would require an in-memory sort. One way to do it (as we wait for @LostKobrakai's better answer ).... Create and populate a property 'distance' on the fly for each page in the PageArray then sort the array by that property. An example: // get a PageArray $res = $pages->find('template=basic-page, limit=15'); // assign distances to a property 'distance' created on the fly foreach ($res as $r) { $r->distance = rand(5, 100);// we assign some random distance just for testing } // testing output $out = ''; // sort #$res->sort('distance');// sort ascending $res->sort('-distance');// sort descending // confirm sorting worked $out .= '<ol>'; foreach ($res as $r) { $out .= '<li>' . $r->title . ': distance - ' . $r->distance . ' Miles</li>'; } $out .= '</ol>'; // it works! echo $out; You should get results similar to this: X-Small: distance - 84 Miles XX-Large: distance - 84 Miles Small: distance - 77 Miles US Open: distance - 75 Miles About Us: distance - 74 Miles Our Achievements: distance - 69 Miles Key Staff: distance - 65 Miles Who We Are: distance - 57 Miles X-Large: distance - 57 Miles Senior Management: distance - 51 Miles Medium: distance - 41 Miles Sizes: distance - 39 Miles Colours: distance - 25 Miles Large: distance - 10 Miles What We Do: distance - 9 Miles Useful reading: PageArray