Leaderboard

Hi everyone! I just wanted to give a quick sign of life. The time of Christmas vacation is finally reached and I can finally invest time in open source project again. Thanks a lot for your input. In the next days there will finally be an update for the AppApi module. I would then like to provide you with a development state for testing before a new master version is released. Let us list the feature-requests: Error when importing database dump: Cannot add foreign key constraint (by @thomasaull) Multi Language and ProCache do not work Weird HTTP status responses (by @David Lumm, thanks for PR ?) [Feature] Add multiple levels to routing config (by @David Lumm, thanks for PR ?) Optional extended logging like @benbyf said earlier. Created Issue #10 on Github so I don't forget it. I will look into the other bugs and issues discussed here as well. Did I leave something out? Thank you for your help and stay tuned for the next updates!

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 ?

... not a module request but I'd love to have a snippet of code to access and expose Repeater Matrix Fields inside the docs :)

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.

Well, hello somebody! Look at what I've stumbled upon ?. Tailwind Starter Kit A beautiful extension for TailwindCSS. Tailwind Starter Kit is Free and Open Source. It does not change or add any CSS to the already one from TailwindCSS. It features multiple HTML elements and it comes with dynamic components for ReactJS, Vue and Angular. Yes and vanilla JS as well! (currently, 16 dynamic components.). License: MIT GitHub: https://github.com/creativetimofficial/tailwind-starter-kit Site + Demos: https://www.creative-tim.com/learning-lab/tailwind-starter-kit/ A tutorial on YouTube. I haven't dug in deep yet (e.g. purge/tree shaking, etc). @Jonathan Lahijani. What do you think? ?

Here is a quick guide to using the comments system. We start from the simplest usage, and get down into more configuration options further in the post. Making use of the Comments fieldtype 1. Make sure that Comments fieldtype (FieldtypeComments) is installed from the Admin > Modules menu. 2. Now go to Admin > Setup > Fields and create a new field. Select "Comments" as the fieldtype and give it whatever name you wish (I usually call it just "comments", and code snippets here assume it's called that). 3. On the next screen, you'll have several options to configure the comments field. Make sure that you enter a Notification email. This is the email address that gets notified when new comments are submitted. Currently it is the only way you will know when new comments are posted (short of checking the admin page yourself), so using this is important. 4. Now edit the template where you want your comments to appear. Enter this: <?php echo $page->comments->render(); 5. Likewise, in your template, enter this where you want the comments entry form to appear: <?php echo $page->comments->renderForm(); 6. Your comments are now ready to use. Note that any templates that use comments for posting should not use Template caching unless you configure the comments to post to another template/page. You'll see an option for this in the renderForm() options shown further down on this post. Adding the Akismet Spam Filter I highly recommend that you use the Akismet spam filter with your comments. To do so, you'll need an Akismet or Wordpress API key (http://en.wordpress.com/api-keys/). Once you have it, click to Admin > Modules > Akismet (CommentFilterAkismet). Enter your API key in the space provided and Save. Then go to Setup > Fields > and edit the comments field you added. Check the box for "Use Akismet". You'll also see a field that says how many days it will keep spam before deleting it. I usually set this at 1 or 2 days, just in case Akismet identifies something as spam that isn't (though it's yet to happen!). Hit Save, and your comments are now hooked into Akismet. Styling the Comments See the file attached to this message (at the bottom). It is a starting point for styling the comments. It's just pulled from the comments styling at processwire.com, so it should be seen as an optional starting point rather than as a ready-to-go stylesheet. Or, you may prefer to start from scratch on styling the comments, depending on your need. OPTIONAL: Customizing the Comments Output You may want to change some of the basics of the comments output. You can do this by passing arguments to the functions you called above to render the comments list and comments form. Included below are examples with all options. You may specify any one or more of the options -- only specify the ones you want to change: <?php // comments list with all options specified (these are the defaults) echo $page->comments->render(array( 'headline' => '<h3>Comments</h3>', 'commentHeader' => 'Posted by {cite} on {created}', 'dateFormat' => 'm/d/y g:ia', 'encoding' => 'UTF-8', 'admin' => false, // shows unapproved comments if true )); // comments form with all options specified (these are the defaults) echo $page->comments->renderForm(array( 'headline' => "<h3>Post Comment</h3>", 'successMessage' => "<p class='success'>Thank you, your submission has been saved.</p>", 'errorMessage' => "<p class='error'>Your submission was not saved due to one or more errors. Please check that you have completed all fields before submitting again.</p>", 'processInput' => true, 'encoding' => 'UTF-8', 'attrs' => array( 'id' => 'CommentForm', 'action' => './', 'method' => 'post', 'class' => '', 'rows' => 5, 'cols' => 50, ), 'labels' => array( 'cite' => 'Your Name', 'email' => 'Your E-Mail', 'text' => 'Comments', 'submit' => 'Submit', ), // the name of a field that must be set (and have any non-blank value), typically set in Javascript to keep out spammers // to use it, YOU must set this with a <input hidden> field from your own javascript, somewhere in the form 'requireSecurityField' => '', // not used by default )); Lets say that you just wanted to change the headlines for the comments list and comments form. You'd do this: <?php echo $page->comments->render(array( 'headline' => '<h2>Read Comments</h2>', )); echo $page->comments->renderForm(array( 'headline' => '<h2>Join The Discussion</h2>', )); OPTIONAL: Generating your own output If you wanted to generate your own output (rather than use the built in render() methods), you can iterate the $page->comments field: <?php foreach($page->comments as $comment) { if($comment->status < 1) continue; // skip unapproved or spam comments $cite = htmlentities($comment->cite); // make sure output is entity encoded $text = htmlentities($comment->text); $date = date('m/d/y g:ia', $comment->created); // format the date echo "<p><strong>Posted by $cite on $date</strong><br />$text</p>"; } You can likewise do the same for the comment form. But I don't want to get too far into this level yet since this is supposed to be a quick guide. Whats on the Comments roadmap? In my mind the biggest missing part is a central place to manage all your comments. Currently you manage them on a page-by-page basis, consistent with where the comment was posted. This is fine for simple uses, but becomes more challenging on larger sites, where you have to rely upon the notification emails to let you know where comments are posted. I would like to expand this so that comments can optionally be managed in a central place. In addition, I would like to make them as easily API accessible as pages. The comments are also not hooked into the user system. Every time you post, you are essentially posting as a guest. While the comments fieldtype will recognize your email address if you have posted an approved comment before, I would like to make it recognize the user system, and also recognize other user systems (like Twitter, Facebook and Gravatar). There is more needed too, like comments pagination and support for basic markup (comments can only contain text at present). If your needs are relatively simple, the Comments fieldtype is a good way to go. If your needs are more advanced, systems like Disqus and Intense Debate are excellent options to consider. The only issue I would have with those options is that they are javascript-based by default, so comments don't become part of your site's indexable content (to search engines like Google). comments.css.zip

I just wanted to add some more thoughts to @Robin S and @Pete's comments. Flexibility is the key thing here. Imagine setting everything up for a template using a combo field, only to discover you need an image (or other unsupported fieldtype) in the middle of the combo's subfields. This is particularly important once the site has content - all of a sudden it becomes a nightmare to fix. This is one of the reasons I haven't ever used the Textareas Profield and I can see being just as wary about using the combo field for the same reason - you just never know how requirements will change over time. Being able to quickly tweak the content types and layouts in templates is why PW is so awesome in the first place.

@ryan You should add UIKIT Theme to the list of requirements. As I just discovered, Reno doesn't agree with Combo, unfortunately. While it can be installed, field creation doesn't work.

I guess to back up my thoughts with a scenario might be useful - your example for addresses is simple enough, but I have a scenario where I've got a directory type site where each entry has maybe 40 fields and it's specific to that template for that type of item being listed. At the moment I'm using 40 different fields and it seems a waste, but some of the fields are repeaters or files and I'd love to switch to combo field as long as I could order the fields logically how I want in the template as Robin has suggested. Otherwise, to echo what's already been said, the only way around it seems to be multiple combo fields with the repeaters/other fields in between which feels a bit hacky.

+1 for being able to place the fields anywhere in the template with other non-combo fields in between. And if they don't have to all be loaded all at once into memory or that can be configurable (I think that was something mentioned on last week's update) all the better. Those two changes would actually enable me to switch from using custom tables for some situations where the number of fields is simply far too large to combo fields.

Last week’s post was about the new ProFields Combo field and it seemed like there was a lot of interest. Thank you for that, it really got me motivated to finish it and release it sooner rather than later. I am very excited about the Combo field and worked on it most of this week, hoping that I may be able to have the Beta version ready for release in the ProFields board by this time next week. This is a little more break than I like to take from the core, but the focused development time means it gets done a lot sooner, and likewise in a stable release state a lot sooner. Since I don’t have core updates to walk through this week, I thought I’d focus on some Q&A about the Combo fields. Below are questions that were asked either here in the forums or in the blog post. Please feel free to reply with any other questions that come up too. There are definitely cases where this type of arrangement Combo provides would provide some nice performance gains. And there are other cases where they might reduce it. Consider that fields on a page in ProcessWire are dynamically loaded when you access them. So when you access anything from a Combo field, all of the data in the Combo field loads at once (1 query). So if you’ve got 10 fields in a Combo field, and you are going to be using much of that data in the request, then you’ve just made some nice performance gains, at least relative to having those 10 fields split into dedicated/separate ProcessWire fields. On the other hand, perhaps you are rendering a list of pages, and you only need one or two fields of data from the Combo field. In that case, it’s less efficient than regular ProcessWire fields because you’ve loaded a bunch of data in memory that isn’t going to get used. So I would say Combo fields are great for data that you use when rendering a full Page, but not as great for cases where you are rendering lists or summaries of pages (where you might not be using much of that data). In the blog post I mentioned that Combo fields store data in individual DB columns, but also keep a separate index so that all of the combo data can be searched together. If that’s what you are referring to, I would say the primary downside of this storage method is that it takes up more space. It adds convenience and efficiency for searching, but at the cost of consuming more disk space [in the database]. This is something that may be beneficial to some and less so to others, and it may end up being an optional thing too. The index is similar to a JSON encoded version of all the fields. But it’s something that I think is worthwhile for another reason: backups. Like the Table field, the Combo field maintains a unique DB schema consistent with your selection of fields. Every time you save a Field, it checks the schema and determines whether to add columns, drop columns, or modify existing columns (and likewise for indexes). The JSON encoded version of the data is immune from data loss as a result of schema changes, so I see it as potentially useful as a way to backtrack, should it ever be needed. As for your question about other fields in ProcessWire, Combo stores it exactly the same way as other fields, with the only difference being that it keeps a separate combined index of data; and is able to because the core Fieldtype architecture enables it to do so. Why not use the same duplication approach with other fields? I can't think of any core fields where this type of storage duplication would be beneficial in the way that it is with Combo. Outside of the core, the approach might be worthwhile in ProFields Table though. Yes! Combo fields work in Repeater and RepeaterMatrix fields. Since Combo fields are not a repeatable type, they play nicely with repeatable types. They might look similar but they are also completely different. A page fieldset (FieldtypeFieldsetPage) is technically a single repeater item, but presented in a non-repeatable way. It’s a convenient way to make a group of fields that you could reuse across any number of templates. And in that respect it’s quite similar to Combo, at least in appearance. But that appearance is where the similarities end. Fields in a FieldsetPage are still individual ProcessWire fields defined on a template, and the Fieldset itself is an independent Page (an individual repeater item behind the scenes). So if you’ve got a FieldsetPage with 10 fields in it, then it’s still consuming the resources of 10 ProcessWire fields, plus 1-2 additional pages for structure. The goal of ProFields is to reduce the number of fields necessary to answer a particular need, and that is not the goal of FieldsetPage. If a Combo field can answer your need, it can do so a lot more efficiently than a FieldsetPage can. On the flip side, since FieldsetPage uses regular ProcessWire fields, it can support more types than Combo can. Nevertheless, once Combo is available, I would most often choose it over a FieldsetPage except in cases where I needed a type of field that only FieldsetPage could support. Yes, any field within a Combo field can be queried individually in selectors using the field.subfield syntax. For example: $pages->find(“combo.first_name=Ralph”); It’s just like querying a Page reference field on pages in ProcessWire. So far, my experience is that it can do all of the same things, and supports all of the same operators; whether querying text, numbers, Page references, selectable options, etc. There are technical differences behind the scenes though. All the data in a Combo field for a page is represented by a row in a database table, so matching some types of values (like multi-Page references) has to use indexes rather than lookup tables. This is similar to the approach taken in the Table field. Per last week's post, Combo fields can do one thing that other fields in ProcessWire can’t though. Because it keeps an index of combined data, you can perform text matching on all of the subfields in a combo field together, just by omitting the “subfield” from the selector. An example is that $pages->find(“combo~=Ralph”); would find the word “Ralph” in any of the fields in the Combo, rather than just the first_name field. So not only is it easy to do, but it can do that more quickly and efficiently than other fields in PW. Thanks for reading and have a great weekend!

@ryan one of the exemplary things about you is your ability to communicate. Writing clearly is important. You do a masterful job of it.

Hi Ryan, When I read about the combo field, it almost seems like a jury-rigged version of a standard MySQL data table with column definitions. When I first came to ProcessWire, I had to get used to its splitting of the fields into separate tables. I'm not an expert DBA kind of person on advanced MySQL queries and indexing and things like complex join SQL statements, but how would you compare the traditional SQL approach of complex queries to both the standard ProcessWire method and the new Combo fields? My question might be too broad; not sure. Peter

@adrian It's definitely possible, and maybe we'll add the option for that. For this first version though it loads all the data in the field in the same way that other PW fields do. But you are right that it would likely be relatively simple to have it load them dynamically.

Hard to give a comparison because I've not used the other services but we switched to Cloudways about 18 months ago and they've worked well for us ( much faster than the previous hosting company we used). You get to pick server providers with no need to separate accounts with them so all the billing is in the same place. The control panel does pretty much everything we need to and you can let clients have access to their server if you trust them. We've not had to contact support for anything serious but when we have spoken to them they were responsive and seem to know what they're doing. I suspect most of my Christmas holiday is going to be spent shifting sites from our old provider over to them...

For anyone who is interested in integrating tailwind inside a processwire project here is a little walktrough based on my workflow. This little guide is based on Tailwind 1.9.6 (latest before 2.0 release) because some PostCSS library I use are still not compatible with 2.0 version (not a big deal, really). You can find the necessary files here. - Place package.json, tailwind.config.js, postcss.config.js inside your template folder. - Create a "pcss" folder, and make a structure like this: pcss ├── inc │ ├── colors.pcss │ ├── fonts.pcss │ ├── media_queries │ │ ├── lg.pcss │ │ ├── md.pcss │ │ ├── sm.pcss │ │ └── xl.pcss │ └── sitewide.pcss └── kickstart.pcss Now you got everything to get started, let's have a look at the files: package.json Inside "package.json" you have different dependencies I've installed to mimick my "old" scss workflow (importing, nesting, etc..), the important part however is the script section: "start": "npx tailwindcss build pcss/kickstart.pcss -o css/dist.css", "watch": "npx postcss pcss/kickstart.pcss -o css/dist.css --watch", "build": "cross-env NODE_ENV=production npx postcss pcss/kickstart.pcss -o css/dist.css" "start" is the bootstrap script you have to run at first, to let node compile tailwind as a whole. Do it at the beginning of the project or everytime you make some changes to "tailwind.config.js" Change the name of your pcss files accordingly (I've used pcss as an extension, but css would work perfectly fine) "watch" is the next script you have to run in order to have live reload of your stylesheets. "build" is the script you have to invoke once you are ready to deploy to production (you need to specify your purge rules inside postcss.config.js, keep reading.) tailwind.config.js Here you can specify your tailwind configurations, read the docs here. One thing to notice inside mine is that I've set purge: false because I prefer to configure the purge part inside a dedicated file, which is: postcss.config.js This file is responsible to handle postcss options, and purge is one of them. The paths you declare inside the content array are the ones whom will be scanned and purged eventually. Mine could be different than yours, so pay attention. The whitelistPattern array is useful when you want to exclude some classes from the purge phase, below I'm excluding the ones whom starts with "fff-". ... content: [ './*.php', './inc/*.php', './fields/*/*.php' // etc. ], whitelistPatterns: [ // Pattern to exclude during extraction /^(fff-)/ ], ... The other settings are pretty explanatory (cssnano is used in production for minification). As a final note you'll notice that every pcss file I use starts (and ends) with: /* purgecss start ignore */ css... /* purgecss end ignore */ Those tell purgecss to ignore completely the file, since I know I want to retain every rule/class I write in there. If you got everything setup correctly you can start having fun ? Run: npm install then: npm run start and finally: npm run watch Hope this little "guide" could enlighten in using Tailwind ?

Hi @Sebi I added the log to app-api (will create a PR somepoint soon), I wondered if you wanted a log message on each request and maybe a setting in the modules settings to turn on or off, or maybe something more granular? My use case is going to require lots of log messages in the api files but having a generic log message on each request I though might be nice. Also wondered if it was worth making a second log for failed (exception) based log messages? so successful requests get logged to one and exceptions to the other..... any thoughts would be cool