Leaderboard

I've updated Combo to use @Robin S strategy for moving the subfields around the page editor and posted it in the ProFields download thread as v2. The definition is available for any Combo subfield and it's very simple, but I figure it's something at least to start with.... it's working and ready to use. It does use a datalist-based autocomplete, so you don't necessarily have to remember all your field names. Thanks Robin S. for the idea on how to make it work, it seems to be a clean and reliable way to do it.

A quick proof-of-concept using the API only... Before (Combo subfields grouped together inside fieldset): After (Combo subfields interspersed with other fields): Hooks: // Reposition Combo subfield inputfields in Page Edit $wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) { /** @var InputfieldWrapper $wrapper */ $wrapper = $event->return; // Imagine this is sort order data coming from some config field $insert_after = [ 'test_combo_colours' => 'image', 'test_combo_description' => 'file', 'test_combo_decimal' => 'test_repeater', ]; // Get the Combo subfield inputfields $combo = $wrapper->getChildByName('test_combo'); $combo_inputs = $combo->getInputfields(); // Reposition them foreach($insert_after as $combo_subfield_name => $normal_field_name) { $combo_subfield = $combo_inputs->getChildByName($combo_subfield_name); $normal_field = $wrapper->getChildByName($normal_field_name); $wrapper->insertAfter($combo_subfield, $normal_field); } // Cannot just remove the Combo inputfield or else subfield value changes don't get processed // So instead a separate hook is used to replace the rendered output of the Combo inputfield // $wrapper->remove($combo); $event->return = $wrapper; }); // Don't render anything for the Combo inputfield $wire->addHookBefore('InputfieldCombo::render', function(HookEvent $event) { /** @var InputfieldCombo $inputfield */ $inputfield = $event->object; $field = $inputfield->hasField; if($field->name === 'test_combo') { $inputfield->wrapAttr('style', 'display:none'); $event->replace = true; }; });

Awesome, thanks @ryan!! I'm just about to go away on holiday but looking forward to working with Combo when I get back. I think it would be cool to have a visualisation of the subfield placement in Edit Template, and when subfields are moved in the visualisation it populates that custom placement field in template context behind the scenes. But that's just an icing on the cake thing, and maybe a better fit for a third-party module. Thanks again for Combo - it's a pretty revolutionary addition to the PW toolbox I reckon. ?

@Robin S Great idea, that's a nice proof of concept. That getInputfields() method is only in Combo, so I hadn't even considered using it for that purpose, but looking at the way you've done it, it looks like it actually is possible to do this, and without JS. Nice. I was thinking JS might be the only way since Combo is an Inputfield that renders markup, rather than an InputfieldWrapper that keeps a collection of Inputfields that can be grabbed and manipulated. But using that getInputfields() method seems to get around that limitation, opening up the ability to detach those individual Inputfields via hooks. Does everything seem to work during form processing and such? It looks like the Combo Inputfields might get processed twice on form submit? If so, you could make it conditionally add the buildFormContent() hook only if empty($_POST['id']) or something like that. But since it's a proof of concept, that hardly matters. If you don't mind me experimenting further with your idea here, I will see what I can do to build something like it in. Even just a simple subfield setting in Combo that lets you specify "Insert this subfield [after or before] [field_name] when present in the form" seems like it could add value here without adding too much configuration baggage.

@Robin S No doubt, that would be nice. But as far as the core goes, that's a pretty major project and involves creating a new interface method for all Fieldtype modules. It could be months, and I'm not sure we'll ever get into that or not, or whether 3rd party, etc. Whereas, this was something simple that could be added today, right now, that will at least make the option available. If it sees a lot of use, I'm sure we'll keep expanding the options. But as it is right now, Combo is the only field that can do this (thanks to your contribution), so I think it probably makes sense that it's also the place where you specify it, at least for the moment. It's not perfect, but very often pursuing perfection means either never starting, or never finishing. ? @adrian Actually the list position is still relevant, it just becomes relative to any other fields that have been moved to the same field. Or if the field being moved-to is present in one template and not another where the Combo field is used, then the list position is also still relevant when it displays in the Combo field. Let's say you specified the same "body" field for all of the subfields in the Combo (to insert after). It would move all those fields after the "body" field in the page editor, and they would retain the drag/drop order you have put them in. The end result would look the same as the Combo field, but without the wrapper/fieldset. I had to play around a bit to get this working, but it is in the version I posted, so wanted to mention that the list position still matters, especially if moving multiple subfields to the same location.

Thanks @Robin S and @ryan - this makes Combo an entirely new beast - so much more powerful and flexible - thank you both for your persistence and openness to making this work. I do agree with Robin that the way the ordering is configured is not ideal - it could be very time consuming for example if you have a combo field with lots of subfields and you need to insert in images field right in the middle. I do agree with Robin though that it's definitely confusing looking at the order of fields in the template settings now, especially in the scenario where you have custom placed all of the combo's subfields. You have this combo field in the list is a position that really has no relevance anymore. BTW, I really like the fact that if you use the new Custom Form Placement option for every subfield, it completely removes the label/fieldset container of the combo field which I think is often a key part to giving this the flexibility it needs to be useful in a wider variety of use cases.

I found this little gem just the other day: https://github.com/felippe-regazio/php-hot-reloader How do you do live reloading?

You can use padding/margins to tweak but first define your rows and columns so that they overlap where required. In the example below I have a text block partially overlapping an image. On small screens, the text overlaps at the bottom and on larger screens, the text is on the left and overlaps the image on the right.

You should get some good inspiration here: https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/core/ProcessWire.php#L410-L459 ?

Hi @modifiedcontent It's really easy, and I suggest you to copy the MyCommentForm.php file from /wire/fieltype/fieldtypeComments, put it in your template directory then rename it to _MyCommentForm.php and modify this file to your need - for you it's the renderFormThread() function which is interesting and there to be tweaked. Then in a template, you put the following code : include("./_MyCommentForm.php"); CommentStars::setDefault('star', '<i class="fa fa-star"></i>'); //<= star item using fontawesome icon $options = array(...); // options of your form, check `myCommentForm.php` $myCommentsForm = new MyCommentForm($page, $page->comments, $options); echo $myCommentsForm->render(); You have also a good function to start here to control all the comments markup : An screenshot of what can be done (sorry for the screencast, I can't resize it.) Enregistrement #3.mp4

Very easy using css grid no need flex to do that. Use z index bigger for div two and use grid-area to locate div one and div two.

Try: $pages->count("has_parent=$child, template=tops, projekt_top_vermietet=1") notice that I changed the single quotes to double quotes, so the variable inside them can be evaluated.

Hello friends! I have another module for you, which will make your daily work as a Processwire developer easier. Introducing: AppApi This module helps you to create api-endpoints, to which an app or an external service can connect to. Features Simple routing definition Authentication - Three different authentication-mechanisms are ready to use. Access-management via UI Multiple different applications with unique access-rights and authentication-mechanisms can be defined The documentation has become quite extensive, so have a look at the Github repository for details: Installation Defining Applications Api-Keys PHP-Session (Recommended for on-site usage) Single JWT (Recommended for external server-calls) Double JWT (Recommended for apps) Creating Endpoints Output Formatting Error Handling Example: Listing Users Example: Universal Twack Api Routes Page Handlers File Handlers A special thanks goes to Thomas Aull , whose module RestApi was the starting point to this project. This module is not meant to replace this module because it does a great job. But if you want to connect and manage multiple apps or need other authentication methods, this module might help you. I am already very curious about your feedback and would be glad if the module helps you a little bit.

Admin Theme Canvas A minimal admin theme with optimised page editor UI, based on Uikit 3. Currently this is close to stable, but users are advised to be cautious and test thoroughly. This theme is tested in all major Browsers including IE 11, Edge (>85), Chrome (>85), Firefox (>81), Safari (>11). If you find any bugs or have ideas for improvements, feel free to post your feedback. Download from Github Download from Modules Page Features Minimal black and white admin theme Fixed masthead navigation Direct access to page tree navigation inside page dropdown Less distraction for editors (when editing a page, the tabs are displayed as a dropdown menu inside the main navigation) Options to customise the ui Less distraction for editors Direct access to page tree navigation inside dropdown Page tree Options to customise the ui Login (inspired by AdminThemeBoss) Requirements Process Wire 3.0.100 or greater Installation Go to “Modules > Site > Add New“ Paste the Module Class Name “AdminThemeCanvas“ into the field “Add Module From Directory“ Click “Download And Install“ On the overview, click “Download And Install“ again… On the following screen, click “Install Now“ Go to your user profile page and change the theme to Admin Theme Canvas

I see, yes that's true. If you move all the subfields out of it, then it's basically just a non-visible placeholder at that point.

Sorry @ryan - I think maybe I wasn't clear - the "list position" I was referring to, is the position of the combo field in the ordered list of fields within the template settings. Once you have separately configured the position of all combo subfields, it doesn't matter where you put the combo field in the template field list. It's not a big problem - just an observation. Thanks again for making this possible!

Hi @Pip, thanks for reaching out, I think I know what the problem is. The module should work with any number of templates and on any number of fields. However, before creating a link for a given title, the module checks if the page the title belongs to is actually viewable. I made this the default because for a "normal" use case it doesn't make sense to create a link to a page the current user can't actually view. Based on your screenshots it looks like you display all hero abilities on the page for that hero, so I'm guessing the hero abilities don't have their own sub-pages in the frontend? If there's no hero-ability.php template, no hero-ability pages will be viewable, so the module will not create any links for those. In version 4.0.0 of the module I added a checkbox to disable the viewable checks for use cases like this one. Your screenshot looks like your site has an older version installed, so make sure to update to the latest version if you don't see the checkbox. After the update the option should appear in the new configuration fieldset Markup and output settings. By the way if my assumption is correct, you may want to use the hook TextformatterPageTitleLinks::buildTitleMarkup to modify the link for hero-ability pages to point to that ability on the hero page instead (using anchor links). See my answer here for details. If that doesn't solve the problem: I've written a bit about how to check what the module is doing in my answer here, use that to determine whether the module (a) is not finding the desired titles or (b) is finding the titles but not creating links for them. This can help you find out what's going wrong. Let me know if you need more help!

Hi @MoritzLost Thanks for making the module. It's really handy for sites that have majorly a lot of pages. I'm working on a game site where there are heroes and their special abilities, items, etc. . Was totally delighted that it was working on my test environment but I noticed that (sorry if it feels snobbish but itemizing helps me think lol) hyperlinking only works on the Body textarea it only works on one page template so it seems I have two templates - hero and hero-ability. They're both in the module settings. I've also counter checked that my textarea fields have the same settings as the Body textarea. Did I do something wrong? Or did I misunderstand something? Thanks.

I am currently working on custom comment form output and custom comment list output. I copied `CommentForm.php` as `CommentFormUikit.php` and copied `CommentList.php` as `CommentListUikit.php`. Renamed class names on these and extend base classes files and removed not used codes and modified needed sections. When i want to use my custom outputs : <?php // include customization classes include __DIR__ . '/CommentListUikit.php'; include __DIR__ . '/CommentFormUikit.php'; // custom list output echo $page->comments->render(['className' => 'CommentListUikit']); // custom form output echo $page->comments->renderForm(['className' => 'CommentFormUikit']); ?> CommentListUikit.php <?php namespace ProcessWire; class CommentListUikit extends CommentList { // do your customizations } CommentFormUikit.php <?php namespace ProcessWire; class CommentFormUikit extends CommentForm { // do your customizations } Example output for uikit 3 frontend framework, still working on it, specially writing a javascript for comment form

Good find ! Now I can use this together with my browser console to see what I am doing. Thanks for posting.

Oh diogo you´re the man! Thanks a lot - I have tried already with has_parent, and I knew there is only a small mistake by me. Thanks a lot!

1st: Make a backup!! I'd try setting the type of the field to FieldtypeText in the DB, then the error should be gone and you should be able to delete it. Or you delete the row in db table "fields" and then you delete the db table field_yourfieldname

I want to share in my use case using FormBuilder, Textareas and Combo. I manage a martial arts association website in Australia. We produce certification for jury and athletes. I use Textareas field to store the integers and manipulate those values in Hanna Code and use that code in FormBuilder markup field for the quiz certification. Since we have a lot of user types from students, instructors, martial arts schools etc.; this is where Combo field suit to store all members data separated from their user's profile account. Doing this way, the user profile data only consists of essential data such as user name, first/last name, email and password etc. Then I can re-use that Combo field in any project as well. So in my use case, the combination of FormBuilder, Textareas and Combo are beneficial.

You need to create enough rows and columns, and span your contents, I believe. See Jen Simmons here:

It rearranges them using JS. I can't remember now but presumably I struck a problem trying to reorder the inputfields using the API before the form renders, because that would be better for sure. I'll PM you the module so you can take a closer look.

HOLY SMOKES, all i had to do was Log in!!!!!!!!!!!

I can't believe that never occured to me - I'm going to push my skeleton project to a new app right now. Finally 2020 is begining to look up ...

Thanks Ryan, My worry about the stated goal of Profields is the desire to reduce the number of required fields - I am not saying that Combo doesn't do an excellent job of this - clearly it does. My concern is why we want to reduce the number of fields - for me, the only reason really is performance. I don't mind giving up simplicity of managing fields for the added flexibility, which is why I don't personally like Textareas. That doesn't mean I don't think Combo isn't awesome - it clearly is - it's just a matter of being careful about when / why you decide to use it. I am really just wanting this discussion to help us all think through the tradeoffs of our decisions now we have this extra tool. I think the key take away that I am getting is that Combo is something to consider when: 1) Fields always belong together in the editor 2) You will always (or almost always) use them all together when rendering on the frontend 3) You are certain you won't ever want to include non-supported subfields (like images) 4) The Combo field contains enough subfields that the performance (DB query) is significantly greater than going with separate fields I am sure that the Combo field can provide more performance - I haven't ever actually questioned that - the key thing for me though is making sure I don't choose it in an effort to have more performance, only to find out that later on there are new requirements that mean that I have to move everything to separate fields - I can already see the need for a new action for AdminActions for automatically separating a Combo field into separate fields and moving all the data to those new fields. Regarding talking about Textareas and Combo together - I think that's because in a couple of key ways they are very similar: 1) They only appear as one field in the system 2) They only use one DB table 3) They are lumped together in the page editor as what looks like a fieldset 4) They are the two main Profields that are designed to reduce the number of fields in the system I understand that otherwise they are very different. Anyway, I do hope this conversation has helped everyone a little and not come across as critical in any way - sorry if I am too brash sometimes - it comes with my Aussie heritage I guess ?

Sorry Ryan if any of our comments came across as criticism of Combo - I do think it has the potential to be very useful and I completely understand why the subfields can't actually be visually separated. What worries me I guess is the stated goal of Profields: "ProFields are an powerful group of ProcessWire field types (with custom inputs) that enable you to manage more data with fewer fields. This saves you time, reduces overhead, and makes development more efficient and even more fun." I guess I am wondering why I'd actually want to have fewer fields (how much less overhead is there actually) - in reality I don't re-use fields that often because of the issues of not having a self-documenting name when calling a field via the API. Yes, title, body, images, etc are fine, but after that it ends up seeming contrived to have a name that is both generic enough and yet semantic enough to not be confusing. Obviously text_1, text_2 is not very useful, but anything more specific is sometimes just as confusing if you are going to re-use for different purposes. Yes, it's a balancing act and I don't have any complaints - I make a decision one way or the other and move on. But, we have these Profields (just talking about Textareas and Combo) to do something that perhaps isn't that beneficial in very many cases. In your address example - how much of a performance advantage will it actually have? What if I also need first_name and last_name fields outside of the address combo field - now I start wondering whether I want a combo address field that includes these, or I want an address field that is just location info, with the first/last name fields separate, or do I just go with all separate fields for ultimate flexibility. We are spoiled for choices in PW, but sometimes I just wonder if too many choices can lead to confusion. Honestly, if there was no performance advantage to the Combo field approach, I wouldn't ever consider using it because of the reduced flexibility - I don't have any logistical issues with managing lots of regular PW fields - it's very easy and extremely flexible. Again, I know we are all very appreciative of all the options you have made available - it's incredible really, just perhaps a little overwhelming trying to balance flexibility with the unknown performance advantages / disadvantages. Finally, I think I mentioned this when you first announced Combo - an example of when I would use it is where I have used a Table field, but restricted it to one row - in this case, I wanted easy SQL querying of scientific metadata that was several fields per page. It will be brilliant for this use cases like this and can't wait to use it for these sorts of things, but I am going to resist the urge to use it for any "normal content" fields. Thanks again for all your hard work.

When I talk about the goal of ProFields being to reduce the number of fields necessary, I don't mean that to stretch into “at all costs”, going beyond what would be logically related in a fieldset or object, or stepping outside the responsibility and purpose of fields. All of the ProFields are focused on reducing field usage for cases where logically grouping them makes sense: visually, semantically, structurally. ProFields are not intended to hack around, change the meaning of, or blur the lines of what’s provided by ProcessWire. ProFields are designed to work with ProcessWire, using its interface and architecture to maximum effect, extending it in the way it’s designed to be extended. There’s nothing that a field like Combo (or any other) could do to make its subfields start pretending they are regular fields. So it’s not even a request I can entertain because it’s simply not possible for a Fieldtype to get involved in that. Don’t look for any ProField (or any field) to do this, because that’s well outside what a field can do technically, and outside of its responsibility or control. If you find yourself having this interest for subfields in a particular field tossed around in different locations of the template, take a step back and ask why. Then consider, this is what ProcessWire fields do, it’s what they are for, and they do it without breaking the borders of responsibility or blurring any lines of what they are. There’s nothing wrong with using regular ProcessWire fields for their intended purpose. Neither Combo nor any of the ProFields are meant to replace that. ProFields answer specific things, they are not intended to replace the template-field relationship, nor could they. Use ProFields where they cross over with a specific need they answer, and skip them when they don't. I understand subfields are cool and popular now, but fields are still where it’s at. Templates are still templates and fields are still fields. A Combo field is also still a field (not a template), and a subfield is still a subfield (not a field). I’d drive myself mad and have an unmaintainable code base if I started mixing up these things or breaking their relationships. I’d like to better understand why you would want to do any of this stuff in the first place (versus just using Fields how they are supposed to be used). Is it because you want them to be stored together behind-the-scenes so that they can be searched as one? Is it because it’s less tables to look at in your DB or less fields to see in your Setup > Fields? Is it because you think it might use less memory/resources that way? Or something else? I think if I understand what the underlying point of this is, that would be helpful. If it turns out that there really is some significant and real benefit in doing this, that can’t be met by using the system as intended, then I’d be interested in looking into it further. But it’s something that would have to be considered in the core and managed by the template (fieldgroup component). That’s because a Field getting involved in the responsibilities and relationships of templates to fields would be bad architecture and a broken system. Whereas, if the core provided an interface where a Field can specify which of its subfields are allowed to be visually “detached” in the page editor, and the template and page editor know of and read that interface, that’s where the architecture could work (no responsibilities broken). The Uikit theme is not a requirement of Combo, so if you find Reno isn't working, that's likely just a 1st beta version glitch that I need to work out. I'll get that figured out.

@999design I have the same issue, even though the paragraph tags have no attributes in my case. Tried it as links and as plain text between p tags, no luck.

Just my opinion, but I don't quite understand whats the benefit to get rid of one dependency to immediately replace it with another dependency. I have no experience with VueJS or Angular yet, but as far as I can see, you would be completely dependent on one of those frameworks. In this case I'm maybe a little bit old school, but I like jQuery and also don't understand, why everybody wants to get rid of it as fast as possible. Also the comparison of ProcessWires API with jQuery was on of the first things, that got me interested. Luckily it is not our decision to decide.

For me, the reality is that when I use "vanilla" scripts, each one coming from different developers with its own code for dom traversal and manipulation, yes they are in plain js without dependencies ... but with a tons of redundant code for the same tasks ... so when I finally managed to finish a complex website with sliders, accordions, calendar, date selectors, drop-down menus, parallax, forms and looong, etc. each has its own code to select nodes, add/remove classes and looong, etc. I have a lot of repetitive code, for what? For a trend? yes it's true jQuery 1x is obsolete and fat due to the support of old browsers, but jQuery 3x is as slim as you need. The reality is that we need a library for common tasks (give it the name you want). For today jQuery allows me to do simple tasks on a regular website without additional efforts (ie a website like processwire.com, not a web application, or a project for Córdoba).. well.. if someone create that library, pleeeease use an API similar to PW/JQUERY.. it's so easy to use and learn for us, the non pro developers!!

Vanilllllllllla js for the win. Although for me its the right tool for the job. Jquery is mostly a sugar to make browsers play nice, and a toolkit of repeatable actions (fade, move, etc). Vue and React are MV* for two way data binding... so basically doing mostly a different job (altough like angular your find front end animation helpers too). Soooo, frameworks go out of fashion (remember when everyone was using Backbone?!), but vanilla won't and right tool for the job.

So, we should build the next PW admin without uikit framework too? Because we will no longer depend on jQuery but will depend on UIKit or any other library that we need to function properly. Really I don't understand which is the trending goal of eliminating jQuery like a disease?

If Jquery is removed i'd like to see plain vanilla js and no framework in between. Just like like there is no PHP framework in PW.

What is $latestNewsletter exactly? edit: sorry, wrong informaton. try this instead: $latestNewsletter->filename