Leaderboard

Select Once Per Table Adds a setting to "Select", "Page (Select)" and "Page (Autocomplete Single)" columns in a ProFields Table field so that each option can only be selected once per table. Requires the ProFields Table module. There could be a number of situations where this module might be useful, but perhaps the primary situation is when you want to store extra information for pages that are selected in a Page Reference field. So instead of using a Page Reference field like this... ...you could use a ProFields Table field together with Select Once Per Table to store extra information for each selected page like this... The module ensures that pages/options that are already selected in the Table field are disabled as you add new rows or edit existing rows. Configuration To enable the module for any "Select", "Page (Select)" or "Page (Autocomplete Single)" column in your Table field, edit the column settings and add selectOnce=1. https://github.com/Toutouwai/SelectOncePerTable https://processwire.com/modules/select-once-per-table/

https://jacquescartierchamplain.ca The Jacques Cartier and Champlain Bridges Incorporated (the Corporation), in Montreal Canada, is responsible for the Jacques Cartier Bridge, the original Champlain Bridge, the Estacade, the Île des Sœurs Bypass Bridge, the federal sections of Bonaventure Expressway and the Honoré Mercier Bridge, as well as the Melocheville Tunnel. They asked Spiria to rethink the content of their site in Wordpress and to optimize the customer experience. The site is highly viewed as it shows live traffic status for the various structures managed by the organization. Once a work notice is registered, administrators can directly send to Mailchimp mailing lists and also post directly to Twitter, in both official languages. Most of the coding is done in-house, but the usual modules (FormBuilder, ProCache, ProFields, SeoMaestro, WireMailSMTP, etc.) are put to work. The module TwitterLatteReplace was used for rendering the pages. Administrators love their new experience with ProcessWire!

Over the years, I've experimented with using RepeaterMatrix as the basis of a rich page builder. I've gone through at least a dozen concepts, most of which hit the chopping block due to either being too complex, not well thought out, too clever or too limiting. To my knowledge, the only other CMS that takes the "Builder" approach that I've demonstrated is DjangoCMS (meaning, it has a matrix-like field with depth support). While the "Builder" approach works well, it could be too advanced for some people. Therefore the other approach is the "Classic" approach where you don't deal with containers/rows/columns (which instead is handled by template code), and simply enter the content in the respective field. This is easy to understand, but has drawbacks in terms of flexibility. If it were made to be too flexible, it would become a "God" block which is bad. Then I finally thought of a third approach which is a mix between the Builder and Classic approach. It uses the basic builder blocks, combined with the layout from the matrix item template file. By using the basic builder blocks, you get the plethora of options. It requires an extra page to be created behind the scenes however, but live preview still works. I made a video comparing all the above (10m duration). I want to hear your feedback on this as I am ~75% done with my super module (doing a lot of code and concept cleaning at this point) and want to finish off this portion of it. (note: I'm posting this in the Dev Talk forum since this is a discussion / not support request)

Not a solution for VSCode but just for comparison... PhpStorm automatically adds the parent folder to the tab label as soon as two files are open with the same name. It's a nice feature.

Here is an article where I did something similar for a client project "Disable select option if already selected in another select box". In my case it is only a JavaScript without settings and it works for every select, not only in Pro fields table.

I pushed a new release fixing an issue from the previous update: I forgot to update the name of the inputfield as well when switching from templates to allowedTemplates, resulting in an issue when trying to add/remove templates. You might need to uninstall / reinstall the module, though it shouldn't be an issue to do so.

I've checked it out. I turned out I was wrong, and tabs in VS code already do it out of the box (actually just like PHP Storm as on @Robin S's screens): and you can configure it even more)) But the paths look so small I didn't notice them. And sometimes they still are not explicit enough. But maybe I just need to get used to this.

Nice to have this conversation going on) Thanks @Jonathan Lahijani! The 1st approach There is probably a room for each of the approaches. For now I am always using the 2nd one. It is the easiest for non-technical people and I have them in the admin. I do not think that I will ever use the 1st approach as it is. It is too complicated and too closely coupled with the markup IMHO. Not unless we make it more visual. To do it, we need at least 1, 2 and 9 from this list. The 2nd approach I can see how the 2nd approach could be made more configurable. You said earlier you're using Mystique for the options. I would've build option sets for different option groups: Оne for the section, dealing with section background, margins, width and so on. One for the grid, making columns proportions adjustable (50/50, 30/70, 33/33/33, 25/25/50 and so on). That option set should be limited by the pre-defined number of columns for block, so you wouldn't have 33/33/33 for a block that only should be displayed in 2 columns grid. Option sets for image and text (for the example in the video). The easiest way to implement those option sets is having them in separate Mystique fields. But they also probably could be merged into one general options field using this (hope I understood it right, didn't try it). Using separate fields would bring the benefit of positioning options next to corresponding items (like putting image options next to image field). I understand that this could be a lot of work to configure those option sets, but that could pay off in the long run. The main downside to 2nd approach is that you cannot easily and visually change elements' position/order. Like making image+text field a field+image. Or adding another column making it text+image+text. The 3rd approach I like the idea of using the 3rd approach, but I do not like the implementation. It indeed looks kind of hacky. I would stay closer to RM basic functionality, though extend it. I think that there could be a neat way to make it if @ryanwould help us here. We would need to implement no. 1 (and 2)))) from this list (Make possible to define allowed children for the matrix types.) This would make 1s approach more solid, but also help us with the third. So we would only allow image and text block under image+text. We would need to make possible creating groups of blocks from add block button. So when we add image+text block image and text blocks are automatically created under it. Might be already possible with hooks. We need to think what happens when we move one of the child blocks somewhere else, so there would be only text under image+text and no text. Or make it impossible to move them out of that nesting. Or teach our content managers to not do it (worst scenario)) Well, lots of hacks needed too) But at least the text and image blocks are under the parent block and are manageable the same way as others. --- There are other possible approaches. Probably Johnathan already thought/tried them, but putting them here for more alternatives. The 1+3 approach Let's have only general section block with options (no rows and columns) and content blocks. Content blocks can (but not should) go under section. If they are NOT under section, they display as full width. If there are more than 1 content blocks under section, they are displayed in columns. If you add 4 - there are 4 columns. Widths are adjustable on the content block label. If there are more than 100% of total width, they are displayed in 2 rows. Still we need no. 1 and 2 from this list to not allow content blocks be nested under each other. The Repeater/RM inside RM approach The name says it. Image and text blocks are inside of a RM nested inside Image+text field. Lots of extra fields, lots of configs, but I do it sometimes.

Yes, it's InputfieldTextTags: https://processwire.com/blog/posts/pw-3.0.177/

I always watch carefully your videos. You've put so much thought into it, it really shows how you've found the advantages and drawbacks of each solution. I also started experimenting with the first option where you basically need to set up the container, rows and columns first before working on your content. Template-wise, I figured that tracking depth could get complicated quickly, and I abandoned the idea, but it sure looks like the most flexible, less "hacky" way compared the new, third option you're proposing. Sure, it requires thinking about design first before inputting your content, and I'm not sure I would offer that option to most of my clients as it requires some learning and a designer/developer frame of mind ("what's the deal about those rows and container anyway?" is what I'd imagine they'd say), but if I'm the sole editor, I'll love to have that option! The classic option is of course always a good, although obviously more limited option, that is intuitive and supported out of the box without some clever hack and double modals such as the new, hybrid approach. I can't shake the feeling that the third option is going to be brittle and need an ever-growing set of workarounds for all the use cases out there. Personally, I've gone a different route. That's probably going to sound half-baked to you, but it might be of interest to some. Instead of trying to cram all the blocks on the same page, I'm using subpages as containers for those blocks. In other words, from the parent page, I loop through all the children to build my page out of this series of containers / sections. So each child page is basically a section of the parent page, where I only need to apply columns, then place my blocks inside. If I need to change the order of those sections, it's just a drag and drop away: I simply move the child page up or down below the parent page. I've not fully explored the possibility, and I'm still experimenting with this on a couple of sites, but I've found it flexible enough for most of my uses, and easy to code. On each child page, first there's a combo (pro) field that holds the basic design settings for the current section, such as margin, padding, background color, width, etc. Then I set up my columns with a simple text field that holds predefined tags for responsive widths and optionally offsets and additional classes, and inside my blocks. Here's a screenshot (in Spanish, sorry) of something very similar to what you've shown in your video: a text on the left, and image on the right.

I really like the idea behind the third approach where every block has its sets of options to work with. I don't really like the way to access them, via a modal interface, even tought I think you've used it since it's the current best way pw gives us to stay in the state of the page edit. One better approach would be to have somewhere a tab (or tabs) for each and every component inside the block (in this case image and text, as for your example) where the options might have their place to live, something similar to what we already have for the rest of the pages. Or maybe, and even better, use the pw native sliding panels to edit the content of each block. Great job by the way!

Just what I need for a current project. Brill!

Hi @adrian, thanks for the report. Please update to v0.4.4 and it should work.

I've added support for "Page (Autocomplete Single)" columns in v0.2.0.

Hey @stanoliver. Are you trying to render the snippet on the front-end only for logged-in users? If so, I've just added an option for that to the latest version of the module (1.4.0). Users to render the snippet for (all, logged in, or non-logged in) can now be selected via snippet settings. Let me know if I misunderstood your question, though ?

Hi @Robin S - just wondering if it would be difficult to make this appear in the Profields Table field for CkEditor Textareas? I know they use CkEditor's inline mode so not sure if that is a problem or not. Thanks.

Turn on debug mode in config.php. When you are able to log into the admin, go to the debug accordion at the bottom. Under 'Pages Loaded', how many pages does it say it loaded?

@stanoliver - I'll let @kongondo discuss his Matrix fieldtype more - I do use it and like most things, it has its pros and cons. It looks to me like the Profields Table field module might be best suited to your needs.

great idea. I could really use it. In my case I have an Autocomplete instead of a Select for the page reference (too many targets) and unfortunately, there double entries are still selectable. But intercepting here, might be another level of complexity. But I might soon find a use case where this fits in well. Thanks for the module!

Please show how you call get_zehner(). It looks like you’re passing in a Page object $page, but Page has no method count() that takes a selector. You can only call it without any arguments and it will give you the number of children of that page: https://processwire.com/api/ref/page/count/. Perhaps you want to use pages()->count($selector)? Also, this line is outside of <?php ?> tags and will not be executed: $mitglied->mitglied_kategorie = $_POST['Kategorie']; Also, please indent and use the forum’s code feature.

I do not understand. I asked for the field type of mitglied_kategorie.

What is your monitor size?)))

Fabulous idea, as always Robin!

Agreed, this is kind of annoying. I don't run into this too often nowadays since I tend to keep only those files open which I currently work on — and usually all of them are visible at the same time, with the editor split into 2-5 columns/rows — but your suggestion makes sense to me. I'll look into this ?

Thanks for the clarifications, Ivan. At the moment the <?= $partials->sublayouts->sublayout_name() ?> approach is probably the closest alternative one to what you've been using. Or, alternatively, you could split common parts of the layout to partials, and include those in two different layouts, leaving out the layout/sublayout separation altogether. That being said, I just mocked up locally a setup where layouts can be embedded within layouts. This is probably even closer, though I feel like it needs a bit more polish and testing ?

Not sure how common this sort of practice is, but we always define custom colours for each project — usually with generic names such as brand-1, brand-2, etc. (unless the client has named colours or a lot of colours, in which case more specific naming helps). In fact in most cases I only use two colours from the default palette: black and white. Everything else (including shades of gray) are either custom colours, or just black/white with specific opacity applied ? Same thing goes with paddings: while we use the default spacing scale, there are always a few "project specific" values; half, single, double, triple, etc. Usually these are pretty straightforward (single = 1rem, etc.) but sticking to predefined, named values does make it a tad easier to make changes later. I don't think there's a built-in way for this. Depending on the specific use case I'd probably pick one of two options: If it's just a few colours etc. that need to change, add those to the shared theme config file for the site and handle the "colour theme" in code. If there are a lot of changes and/or for some other reason you want to clearly separate styles for different parts of the site, create a separate Tailwind config file and adjust your build process accordingly. How that would work depends on what kind of build process is in use, but generally speaking it shouldn't be too difficult ? If you google something like "tailwind multiple themes", you'll probably find other solutions as well. I've never needed this type of functionality, so haven't given it much thought.

You could also add the parent element as first element in the sub nav. The processwire website does it also this way.

I've seen some hacks / config settings for VSCode to display at least the parent folder of a file. Never tried or used them... but maybe still worth trying to look into this. Just an example: https://stackoverflow.com/questions/39598007/showing-path-in-file-tabs-in-visual-studio-code

@Abe Cube please use the code input to post code: Example: <?php namespace ProcessWire; class TabExtension extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'Foo test module', 'summary' => 'An example of creating a module', 'version' => 1, 'summary' => 'Display message when pages are saved', 'autoload' => true, ]; } public function ready() { $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'addButtons'); } public function addButtons($event) { $page = $event->object->getPage(); if ($page->template == "bewerbung") { $form = $event->return; $inputfields = new InputfieldWrapper(); $tab = new InputfieldWrapper(); $tab->attr('title', 'Settings'); $tab->attr('class', 'WireTab'); $markup = $this->modules->get('InputfieldMarkup'); $markup->label = 'Settings'; $markup->value = '<p>Just a placeholder for some inputfields.</p>'; $tab->add($markup); $inputfields->add($tab); $form->add($inputfields); } } }

Please read this blog entry. You can use images, links, a dropdown or your own custom solution for adding new matrix items: New Repeater and Repeater Matrix features (processwire.com)

If I got this right, you've got a three-layer approach (layout - sublayout - view) instead of Wireframe's regular two-layer design (layout - view). If so, this is not really something I've had much need for before, but here are a couple of rough ideas: If you have, say, "single column sublayout" and "two column sublayout", you could include the content that you'd usually put into these directly in the main layout file, accompanied by some sort of switch. For an example you could pass an argument to the layout via the bootstrap file (or from the Controller class), stating which sublayout you want to use for current page/template, and then just include related if statement in the layout file. This is, of course, not a very clean solution if sublayouts differ a lot from each other. But if the differences are minor and/or sublayouts are relatively simple, then introducing a whole new layer might be overcomplicating things a bit. You could use partials: instead of directly including <?= $placeholders->default ?> in your layout file, you could call <?= $partials->sublayouts->single_column() ?> etc. and thus mimic that extra layer. Of course this still requires some method of defining which sublayout to use for each template or page. Now, one thing I don't fully grasp is that how do you decide which template(s) use a specific sublayout? If I knew that, I might be able to suggest better solution. Would also be interesting to hear a bit more about what exactly is in the layout vs. sublayout. This might be something that we could support in Wireframe right out of the box — though before that I'd like to fully understand how it should work, and what is / what are the problem(s) it solves ?

There is an option for changing the "created" date via the API using quiet mode: $page->created = $timestamp $page->save(array('quiet' => true)); This only works for created though, not modified. This is what I use for modified - make sure you do this after the last $page->save() or it will be overwritten. $sql = "UPDATE `pages` SET `modified` = '".date('Y-m-d H:i:s', $timestamp)."' WHERE `id` = '".$page->id."';"; $update = wire('db')->query($sql);

You can keep on using UIKit but it is not a silver bullet solution for any situation. Find any mobile menu/accordion navigation on jqueryscript dot net for free with code examples, and demos ready for you to use with processwire. Have a look here: https://www.jqueryscript.net/