Leaderboard

This latest version of ProcessWire on the dev branch adds a new Inputfield module called “Toggle” that is an alternative to the existing Checkbox Inputfield. It also adds a nicer way to make column width adjustments to your fields when editing a template. This post covers all the details with screenshots and a short video: https://processwire.com/blog/posts/pw-3.0.139/

Hello everyone, while building an app-interface for a page, I developed some changes and improvements to this module, which I made available as a pull request. But @thomasaull and I are not quite sure if it makes sense to transfer these basic changes into the main module as well. Therefore we would like to hear your opinion: What do you think of the new module version? Which features would be useful for you? I have developed several new features that allow the administration of Api accesses via the ProcessWire backend. I also revised the authentication and added a new Double-JWT option that works with long-lasting refresh and short-lived access-tokens. New Features: New menu item "Restapi" in the ProcessWire menu under "setup Management of Api accesses (applications) outsourced to the new menu item Apikeys now authorize api-access Creation of multiple applications with different auth types possible Double-JWT Authentication, renewable tokens token-sessions can be viewed and deleted in the backend Improved exception handling: Each endpoint can throw exceptions, which are then output with the appropriate HTTP status header and message.

This is why I think we need a field aliases feature. I have a working module that allows the use of field aliases anywhere in template files and in /site/ready.php and /site/init.php, but issues with the File Compiler need to be fixed before the module can be released.

--- Please use RockFinder3 ---

After my post yesterday I realized that there is actually more I do. At first I thought I don't think that much about naming but then I looked into a recent project and found several patterns that seem to be part of my workflow for a while now but I never saw that as a naming convention to be honest. It's more my laziness. I hate searching around so I group templates and fields in some cases to make things easier for me - I guess. Templates for data that will never result in a viewable URL/page get the prefix data, for example: dataPerson dataWebsite dataProject dataProduct Then there are templates that result in real pages/URLs which get the prefix content, for example: contentPage contentPost contentEvent contentGallery Then there are templates for pages that result in real pages/URLs but don't contain real content on their own which get the prefix list, for example: listBlog listMovies listRecipes listTeams There are some more templates types but I'll skip them here as they are too much based on my workflow and projects - sometimes. "Yeah... but what do you do if a data template needs to be changed and a page should become viewable?" Well... I rename it, create or rename the .php file, do the things that are necessary to get the task done and I'm ready to go. While developing a project this can happen - but not that often actually. It's more often the case later on when the website owner decides to push more content into Google's index. As it is a client request I'm totally happy with it and can invoice my work. In terms of field names I go the way @teppo already mentioned but with a little twist at the end. I name the fields depending on their purpose. headline subline summary excerpt intro bodycopy images heroImage heroVideo videoYoutube videoVimeo urlFacebook urlTwitter urlLinkedin nameFirst nameLast nameFull You can see that I try to group fields by their name structure. Instead of firstName and lastName I reverse the order and these fields stay together in my list of fields. That makes life much easier in case I need to look up something or want to find out if there is already a field I can use. But... is this really a naming convention? I don't think so.

I don't want to dismiss this issue, but I also think that people sometimes overthink the whole field naming thing a bit. When you're creating a new field ... Decide if this field is something you can reuse elsewhere. Things like "images" or "summary" are obvious candidates, and then there are the likes of "color", "width", and "background_color" that are likely to fit into this category as well. If you can see further use for the field (or rather the data it represents), go with a generic name. If the field is very specific to the use case (based on it's purpose, context, or settings / formatting rules etc.) don't try to get too creative with the "always reuse" idea. If it's a field that's specifically designed to hold google_analytics_id, just name it accordingly. Reusing fields is the best practice, but reusing fields for something they're not meant to do (and/or where they'll make no sense at all) will just mess up your information architecture – not to mention the issues it'll cause once you realise that in a particular use case you actually need to tweak some field setting that cannot be changed in template context. (Note: I'm aware that you can nowadays make a lot of stuff changeable in template context. In my experience it doesn't necessarily mean that they work as expected, and even then it can result in a whole new layer of complexity. Personally I try to avoid that.) 50+ fields is plenty, but especially if it's a moderately big project, in my opinion it's nothing to be worried about. ... oh, and one more thing: sometimes I see folks create loads of "duplicate" fields such as email_1, email_2, email_3, etc. That's one one easy place to optimise: use one of the repeatable fiield types, ProFields table, etc. Table is particularly great because it can handle large amounts of data in an efficient manner ?

I found the commit where that line was added, and the issue that it was related to: Commit: https://github.com/ryancramerdesign/ProcessWire/commit/8d126246772633be773d72f5262acdf14f4c1e31#diff-bbe4731226c86c286f0e4e95a4756eda Issue: https://github.com/ryancramerdesign/ProcessWire/issues/1942 One question that comes to mind is whether a clone should be considered a "moved" page (have a parentPrevious property set), since the original page still exists. If it were considered new instead of moved, I think the line in question would not apply. It still seems like there is a lot of overhead here for a move operation. But I still need to study the issue report linked above more closely.

Hope you guys are having a great week. I'll keep this week's update short since everything I'm working on is in-progress rather than ready to post. But I can tell you about a few things you'll likely see in next week's post: First is that I've got multi-page/paginated form support just about ready to release in FormBuilder. What this means is that you can take forms (especially long forms) and break them up into multiple paginations. This makes for multi-part forms that are more digestible and easy to use for users. The end of each pagination has "Next" and "Prev" buttons for navigation between them. FormBuilder validates each pagination independently as it is submitted so that any errors are taken care of as the user proceeds rather than all at the end. And these are true paginated forms, rather than a JS manipulation of existing forms. More on this next week. I'm also working here on a new Inputfield module called InputfieldToggle. It's an alternative to the core InputfieldCheckbox and the intention here is to make it a selectable alternative for FieldtypeCheckbox fields. Unlike InputfieldCheckbox, it is presented as two radio buttons for "on" and "off" states. (It's also possible to have a "no selection" state distinct from the "no" state, where supported). It comes predefined with several toggle types (Yes/No, On/Off, True/False, Enabled/Disabled), along with the ability to specify your own (multi-language too of course). Like a checkbox, because it is a toggle, it holds a value of either true (1) or false (0). There is also null for no selection. While this is a relatively simple Inputfield, it answers a common need (at least in my experience) and often can provide a better experience than a standard checkbox, depending on the input need. Not to mention, it's a lot more efficient than using an Options or Page field to accomplish the same thing. In addition to sites and apps running in ProcessWire, I think this particular Inputfield has a lot of potential use in the core and its administrative forms, so I might include it in the core, though not yet certain. I'm already using it quite a bit in forms I'm developing for clients in FormBuilder, where in many cases I find it a better fit than InputfieldCheckbox. Lastly, there are some nice UI enhancements just about ready for manipulating column widths of fields in ProcessWire. It makes it a much simpler and quicker job than it currently is, so I'll have more on that next week too. Have a great weekend!

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

Thanks for informing us! I do not have too much spare time either but I will take a closer look and see how much effort is needed to bring it at least up-to-date (the module also has issues with the UIkit admin theme). In the meantime, if anyone else is planning to do something similar, then don't be afraid to share your thoughts and/or work ?

I'm just considering, if I should rather hook Pages::saved than ProcessPageEdit::processInput. The advantage is that I can get information about which fields have changed. So I can send the e-mail notification only if some important fields have changed. It seems that I can still access the "notify" value of my checkbox - it is contained by the "changes" parameter exactly if it differs from the default.

Hi all, Apologies for the radio silence. The version I have is far too customized at this point. I added a bunch of functionality that was specific to my needs at work. I should have been extending it instead, but I never got back to it. I’ve taken a new job recently, and I’m not working with ProcessWire on daily basis. Unfortunately, that means I don’t have any time to maintain the Activity Log module. If anyone wants to run with it, please feel free.

After a quick look into some projects I took more care about files: assets (/site/templates/assets) brand brand-company-logo.ext brand-company-og-image.ext favicon.ico (just a backup - the .ico always sits in the document root) favicon.png ... fonts plex proxima icons* (icons often end in my .css files - a ProCache option, therefore names don't matter here) whatever-123123.svg the-file-912321.svg was-named-or-4572.svg helps-me-to.svg find-the-icon.svg i-need.svg vendor jquery jquery-3.x.x.js slick z (storing things I don't need anymore without deleting them - just in case) * icons are in 99% of all cases just decoration elements so I use them very often as backgrounds and not as images. Every image that's not content on its own or part of the content will not end in an <img .../> tag. In case of gallery arrows I try to use text links/span-elements and re-style them with CSS. The icon itself will be in my CSS most of the time.

Can you share your actual snippet so we can see if the issue is coming from somewhere else while you're building your filter string.

This answer. Perfect. What about template and field names within PW? Thoughts?

@netcarver Glad to here it works for you ? it is such a hacky module. I don't think the Tfa class was coded with security keys in mind ? but so far so good. let me know if you discover any bugs/issues using it. I know of at least one bug that you shouldn't come across too often (if you login to an account with Tfa but don't use the key and then try to login with a 2nd account it will fail as it will still have a different challenge set for the session. it self-fixes when you try a 2nd time, I cant think of an easy solution to this problem though as it was done that way on purpose to get around the buildAuthForm function being called twice and resulting in a bad challenge on every attempt)

:-)

And that $filter comes from where? From a select option (thread title) value? You should try to solve this puzzle with Tracy Debugger. See what value exactly is taken from the select option and what is actually passed to find(). Perhaps you need to do something like using unformatted value, or PW is somehow doing sanitation and wipes out some characters. Just wild guesses, but maybe TD will show you what happens, and where.

That's where a good IDE is a big help. Whenever you rename stuff (files or variables etc.) it cleans up for you and searches for usages everywhere in your project.

Yes, that's planned.

As the name would suggest, it's triggered when the input values in the Page Edit form are processed. ? There aren't really any circumstances when page data will not be saved when the Page Edit form is submitted, apart from a fatal PHP error due to some mistake in your code. The situations where a page save might be attempted but not actually occur are outlined in this code, but these are only likely to happen when a page is being saved via the API. Are you thinking of warnings caused by empty required fields? Because page data is still saved in that case. But if you don't want an email to be sent if there are empty required fields you can check to see if there are any form errors: // Return early if there are any form errors if(count($form->getErrors()) return;

What do you mean? ? If you only have this: instead of Then of course you'll get much more results. Omit the limit parameter to really see how many results you'd get. But in any case, it's not logical that you get ALL properties listed (e.g. even property types 1 or 3). Care to explain a bit better?

If you're not harnessing the backend from ProcessWire I'd personally tend to not use ProcessWire. While it's entirely possible to do so (maybe also search for prev. discussions on the topic) there are some parts, which in my opinion discourage that kind of usage: Lack of proper testing capabilities. There are topics on how to do TDD with processwire, but the options on managing db state or handling requests in tests are not there. If you need to manage a lot of diverse data the autoloading of every template/field on each request can become a bottleneck. Working around it by reusing more fields/templates can work, but isn't great either. The selector engine for pages is great for light to medium complex stuff, but complex selections and especially aggregations need custom SQL or third party solutions like RockFinder. Also if you're not careful it's tempting to fall into n+1 query problems with fields / relationships being lazy loaded by default. Transactions are hardly used by the core, so if you want/need to prevent partial updates from happening you need to ensure that on your own by wrapping stuff into transactions. Not to say ProcessWire isn't otherwise a nice system, but those are the things I'd urge anyone to evaluate before using ProcessWire in a web application project.

I just wanted to share what I've just discovered after looking at Dragan's "CMS evaluation / checklist / usability (only in german for now)" article, even if I can't read german currently. https://animejs.com https://github.com/juliangarnier/anime

Hello, here is example from one of my projects and don't know if that can help you. That example show AVG of 4.6, and below is copy/paste how I get that. I believe that only what you need is to set "use stars", and this call: $page->comments->renderStars(true, array('schema'=>'microdata','partials'=>true)); Or more details, where I use that: <?php if($page->comments->count):?> <div class="star-rating"> <div class="rating-counter"> <a href="#listing-reviews"> <?php echo $page->comments->renderStars(true, array('schema'=>'microdata','partials'=>true));?> </a> </div> </div> <?php endif;?> If that is interesting, here is and Comments configuration to use Font Awesome icons. CommentStars::setDefault('star', '<i class="fa fa-star"></i>'); //<= star item using fontawesome icon Regards.

Hi Beate, Congrats on the migration also this is how it goes, First you need to go the your Fields and see the name of the fields that hold the comments, then all you need to do is to $fields->find("comment_field_selector,sort=date,limit=AMOUNT_OF_COMMENT");