Leaderboard

It is a good question and one that gets asked rather a lot, one way or another. It is all too easy to write down long lists of clever functionality, or to write crafted documentation and tutorials, or to put together neat little sales lines that package it up in an easy to understand bundle. But, ultimately, any tool is defined best by the type of people who use it and by the community that grows around it. Well, today I realised the perfect answer to my question. THIS is ProcessWire: Thanks Diogo - Christmas landed early in my post box this year!

How about ip_type.title?

I'm pretty sure that those things can be done already. Styling the Pagetree can be done with a CustomModule like here: https://processwire.com/talk/topic/5609-display-a-template-icon-base-on-date-field/ And to get a list of all pages by certain criterias (template, parent, empty fields etc.) can be done with Find / Lister:

Suppose I better drink some before I debug this template on my next ProcessWire Website...

Just a simple contact form including spam protection. Optional support for Twig (TemplateTwigReplace) as template engine. --- Please have a look at the readme on github! If you upgrade from version 0.0.9 and below, there are some extra steps to be taken. The Guides Installation Module Settings Spam Protection Usage Logging Upgrade Notes

Like most newbies (I suspect) I am now exploring different Modules. To be honest some of them leave me wondering "how and when would I use this?" I bet most of you have favorites, a few oft deployed modules, that you reach for most of the time. I wonder if the most used modules would be the same for most of you? Anyways, I am interested (maybe others as well) in learning what modules you guys reach for most of the time... Thanks!

FormHelper The redesigned FormHelper extends the InputfieldForm object with additional features. Features The FormHelper module extends the PW form object and simplifies the form handling. create basic PW form object with submit button add form field value handling and sanitizing take care about form submit / error state and processing CKEditor pwImagePlugin field, jsConfig, load form admin styles FormHelperExtra is a submodule to handle additional features. create a form object with fields based on Template, Page, Form objects or field data array form file upload handling (temp page uploads, creation of a hidden storage page) Usage Documentation / examples Repository PW module repo GIT repo ToDo / Issues Issues

See these examples: http://processwire.com/api/variables/pages/ https://processwire.com/talk/topic/1153-adding-images-to-a-page-via-the-api/ https://processwire.com/talk/topic/1153-adding-images-to-a-page-via-the-api/?p=10334 https://processwire.com/talk/topic/206-renaming-uploaded-files-from-tmp-name/#entry1371

Not wanting to assume the OP's expertise in PW, I think it is important to clarify that this should only ever be 'on' while developing and never on a production/live install

Hi! Try using $page->template->name instead.

It seems that the issue was with how I got the arguments. I replaced $page = $event->object; $options = $event->arguments(0); with $page = $event->arguments[0]; $options = $event->arguments[1]; and then it worked as required ... Using the anonymous function is also part of the documentations somewhere and explicitly shown as an alternative for newer versions of PW / PHP.

Not tested, but try this: $page = wire('page'); $out .= $item->id == $page->id || $page->parents()->has($item) ? "<li class='current'>" : "<li>";

Target the div.post instead. Each post is wrapped in a <div class='post'>.....</div>

There is start? $posts = $pages->find('template=news, sort=-created, start=80, limit=40');

I meant that during installation my module could add code to the config.php file similar to the topic you linked to to do something there before PW's session starts.

Hint: https://processwire.com/talk/topic/142-make-session-start-in-session-overridable-from-a-module/#entry1002

Kewl Joss! How would you say it tastes? Acidic? Nutty? Managed to try it with your French press? Does it work well with that? It's exciting to get coffee from different regions, more so when sent from a friend!

Thanks for your help totoff and Bernhard!

Hi Guys! If any of you are looking for a monospaced font you might want to check this out: http://www.myfonts.com/fonts/jan-fromm/camingo-code/ You get a free and nice looking monospaced font in regular, italic, bold and bold italic. All in Desktop and Webfont. Useful for those of you thinking of putting up some ProcessWire snippets on your website Cheers P.S. For any typography buffs.... this is, for a week or so more... a great deal: http://www.myfonts.com/fonts/latinotype/texta/

Hi gebeer It is designed to work for either back, or front, or both. It's up to you. The main flaw in your testing is using incognito mode. That is a totally separate browser session, with different cookies. So there is no way that logging in with persist, in one browser window will work as you expect it to with incognito. The better way to test it is to delete the ProcessWire session cookie. This will log you out. But then LoginPersist will see the persist cookie is present, and log you back in. The module is designed to remove the persistent cookie when the user actively chooses to log out. The idea behind it is to allow the user to have a persistent login state until they choose to log out. To remain logged in with this, simply do not log out.

if(strpos($q, " ") !== false) $q = str_replace(" ", "|", $q); $result = $pages->find("template=basic-page, title|body%=$q");

so here is what i would like to point out about it... firstly, tabs as Raymond said pops out on a grey background, which is different to basic and reno admin theme in basic/reno theme it looks to me that changing tabs is only going to change first input field, because after each input field there is a horizontal line. Although, i am not sure it is really needed. i think that it is better to make input labels a little bigger, and description (if any) slightly smaller. Paper in material design nicely stands out and buttons that are outside of paper should suggest that it is save to change tabs without loosing what you have written in inputs, i.e. it is not going to load another page color of active input field would be light blue. I noticed that in basic theme and reno theme active inputs doesn't change border color. blue would be also color of links pink color is for active menu items/ tabs. it shows you where you are now i didn't use icons in menu but it can be added. However, I don't like font awesome ... maybe some custom icons could be made. another thing is that save button, which is primary button, should stand out. So it is made bigger and with a shadow. I dont know why but in basic theme and reno theme top save button is on right side and bottom save button is on left side. I think both should be on right side.

Are you trying to be funny? Actually is is Comic Avec, not sans.....

Welcome joer80, If you want to look at the query log on the admin side, just turn on debug mode by editing the /site/config.php file and changing $config->debug = false; to $config->debug = true; and saving the file. After that you get a load of debug information at the bottom of every admin page and it includes a list of the queries. With regard to query count: MySQL has a pretty good query cache so just going by the query count might not show the whole picture with regard to where something might be bottlenecked. When accessing the DB and running my own queries directly from modules I've never had to open a connection so either PW does it for you behind the scenes or you get to re-use what it already has open (I'm guessing the later but I haven't stepped through the code to confirm.) Here's an example query from a module I'm working on now... $t = $this->db->query("SHOW CREATE TABLE `$table`"); But you can just do... $t = $db->query("SHOW CREATE TABLE `$table`"); ...from a template file. More details.

Hi joer80 and welcome to PW! You can get a count and list of all queries on a page like this: $queries = $database->getQueryLog(); echo '<p>Number queries: ' . count($queries) . '</p>'; foreach($queries as $query){ echo '<p>'.$query.'</p>'; } Just put that somewhere in your home template. I have to run out the door, but someone should chime in with how to use your own SQL easily. There are posts about it here. Google search is much more effective than the forum's built in one. Good luck!

You may do this by a module like that: public function init() { $this->addHookAfter('ProcessPageListRender::getPageLabel', $this, 'addPageListLabelItems'); } public function addPageListLabelItems($event) { $page = $event->arguments('page'); // then you do your conditionals and your styling, like for example: if($page->myField >= $myMinValue && $page->myField <= $myMaxValue) { // add your styling here } // or like that: if('architekt'==$page->template) { // add the styling here $styleItem = $page->ortarchitekt == '' ? ' <span class="jhpPageListItemEmpty"><strong style="color:white">kein Ort eingetragen</strong></span> ' : ''; // now add the new style item to the existing output $event->return = $event->return . $styleItem; } } This way I get outputs like that: EDIT: Ah, have found it: here is a module from Soma: http://modules.processwire.com/modules/page-list-image-label/ that adds a Thumbnail to the list. That was the startingpoint for my customized PagetreeList. If you are not (yet) familiar with modules please have a look to the HelloWorld-Module or ask here for further assistance

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.

Should be fairly easy to add session support. if($input->post->pass) $session->pass = $input->post->pass; if($page->album_password && $session->pass !== $page->album_password) { $page->body = $input->post->pass ? '<h3>Invalid Password</h3>' : ''; $page->body .= file_get_contents("./inc/login-form.inc"); include("./basic-page.php"); } else { include("./album.inc"); }