Leaderboard

I have just finished the first draft of a new tutorial on the wiki. http://wiki.processwire.com/index.php/Basic_Website_Tutorial I know it needs tightening a bit and possibly some more screenshots, but my main concern at this stage is whether it works technically; in other words, if someone follows it, will they actually end up with the finished site? The aim of this tutorial is to go further than the Planets small project walk through. It starts post installation by cleaning a few things out, adding a couple of modules and so on. It then creates a site structure from scratch, creates a site settings system (site title, banner, meta keywords and so on) and populates the new site structure with the results. Finally, it creates a new article template with new fields and adds the page. The idea was that I could cover in basic detail: How Template Files relate to Templates Creating various field types (including images) Getting information from the current page and another page (using $page and $pages) Talking about a few other concepts like how information is stored Demonstrating the power of not having a templating system by default And lots of other bits and pieces. This tutorial produces a demo site that is ready to accept other tutorials - slideshow, news system, etc - without having to start from scratch again. The site design does not use a framework, and is simple and clean but familiar - could be the basis for many site types. Anyway, initially I am just looking for comments on the technical side. So, if anyone has time, can they try it and see if they actually end up with a site, or have I forgotten anything? Bearing in mind that I am very new to PW, I could easily have got things wrong somewhere. Once I am happy that it actually works and that I haven't said anything in it that is technically wrong, then I will go through the writing with a fine tooth comb. Thanks in advance to any guinea pigs out there! Joss

Greetings, The question of documentation has come up in a few different places here, as it is vital to the success of this terrific application. I really like the existing documentation, which is very effective at helping people get up to speed on ProcessWire. At the same time, I've been putting together my own personal documentation on ProcessWire, mostly to remind myself of steps. It is turning into something that might be useful to others... The way my material is shaping up, I believe, is complementary to the existing documentation. It's naturally arranging itself as a series of "examples" of using ProcessWire, or specific "How To..." entries. Then inside each entry I am free to branch into references of whatever parts of the API are relevant for that examle or "How To" entry. For whatever reason, this approach seems more appropriate to ProcessWire. Just my opinion, but I think the best framework documentation is for CodeIgniter. That one goes class-by-class. What it lacks, I believe, is a thorough set of example uses. I'm planning to put together a Web site that will house these examples and "How To" entries, and I will make reference to the existing API. I'd also like this to coordinate with other documentation projects that other members are working on. How does this sound? Thanks, Matthew

Hey Soma, after reading again and this time more thoroughly through everything you wrote and linked to I have the feeling I made a bit too much of a problem out of it, because you're totally right with that everything is already possible. The code you posted really helped here, thanks again! To solve the problem with saving was also pretty easy: just doing a untrackChange('value') in my hook after Inputfield::processInput was everything needed (see here).

There's no option for that. Sure API sounds good. A quick glance at ProcessTemplate.module shows how it's done. With this code in a template and call it once. $tmpl = $templates->get("basic-page"); $editor_role = $roles->get("editor"); $editRoles = $tmpl->get("editRoles"); // currently set roles $value = array(); // assign already set roles foreach($editRoles as $v) $value[(int)$v] = (int)$v; // add new role to it $value[(int)$editor_role->id] = (int)$editor_role->id; // set editRoles property and save $tmpl->set("editRoles",$value); $tmpl->save();

Hello, As I mentioned in my first post, I definitely see CodeIgniter as a model for documentation. The other framework that I have been using for some projects is Laravel, and it also has terrific documentation (http://laravel.com/docs). Still, I think both CodeIgniter and Laravel do not have enough illustrative examples of how the code is used for day-to-day real tasks. That's what I want to base my documentation on. I've already written several pages for my project, and I have high hopes for it. My longer-term goal is for it to link up with the work others are doing -- for example Joss's material. I'm putting together actual documentation pages now, and also a scheme for the way the whole thing works. I'll present it soon. ProcessWire is such an amazing tool, it elevates your whole idea of what's possible. That in turn is making me want to create documentation that is also amazing. Thanks, Matthew

http://www.pebblesthepuppy.co.uk weni, widi, weewee I came, I saw .... I did something unspeakable on the carpet...

Yep, and speaks a good Latin also

Warning: Still a work-in-progress. Still has quite a lot to be done. At Tom Reno's request I started work on a module that allows you to setup various watches on fields in your PW installation. You get to choose a field and can then specify when a change to the watched field should trigger a notification email to various interested parties. Pictures might help, so here we go... I intend adding a further restriction so fields in certain templates can be watched.

Edit 2013-01-09: This module is deprecated - see the next gen version here: http://processwire.com/talk/topic/2515-module-aftersaveactions/ - - - After following the discussion on multiple save buttons and default action after page save I decided to give it a try. The result (or an early version of it to beat Soma ) is a module called PageEditRedirects. The module, inspired by this post in particular (and another module by adamkiss), adds four options to choose from when saving a page: stay in editor (default) go to the page list add a new sibling page view the edited page The options are always collapsed and the chosen option is saved into a cookie so that each user's preference will be remembered. Probably should add a checkbox "Remember this setting" (unchecked by default) so that a one-time use of another option doesn't get sticky. Module can be downloaded from https://github.com/n...geEditRedirects and wont be available from the modules directory just yet (because of the required PW 2.3). So, consider the module just an alpha version or a proof of concept as it hasn't been tested nearly at all (need to check it doesn't break Antti's Adminbar for example). Edits: * Added link to an early post on the subject. * Added a little more explanation on what the module does and doesn't do. * Removed the note on needed core changes (Ryan did those already).

Would that go in the Root Canal of your website .....?

What is probably needed is a permissions map where you can look at all permissions belonging to a group or a single user. So, you could show permissions for a group for templates - then either change permissions individually or select the entire lot (or multi select some of them) and change the permissions. Probably hell to programme, but as PW sites get more adventurous and larger, possibly very useful.

Hi Matthew, this shouldn't have anythind to do with the module itself, but you might try the following: Delete everything related to the module from your /site/modules folder. Use PHPMyAdmin or something similiar to look in the "modules" table of the database. Delete the entries named "TextareaCounter" or "TextAreaCounter". Delete all files starting with "Modules." from your /site/assets/cache folder (ah, forgot this at first post...) Install again as usual. I haven't tested this in any way, but his hopefully helps. Edit: Sorry to cause you problems with the rename, I just thought it would make more sense with the lowercase "a"...

Greetings, I like this site. Dr. Shackleton seems like a friendly fellow, despite his name. The site presents a warm and organized feel. (From the photo, it appears the doctor either works late or comes in very early). Joss: I think joshuag must have removed the phrase? Maybe a better one would be "site crowned by ProcessWire" Thanks, Matthew

Hi everyone, I just worked on this a little and added client- and server-side validation. It would be great to get some feedback on this, so if anyone has some time to do testing, please check it out here: https://github.com/boundaryfunctions/TextareaCounter If there are no crucial bugs coming up for you, I'm going to submit this to the module repo soon.

Hey Everyone, Based on this sample, I must... 1. Try Bootstrap 2. Purchase Form Builder I'm still investigating frameworks (Foundation is my current favorite), but it seems that Bootsrap again and again gets the most attention. Thanks, Matthew

HI ziusurda When you are looking through the Database itself, one thing worth noting is because each field you create in the Admin (Setup > Fields) has its own table, the data stored is very clean. This makes it very easy to deal with in your Template File in the /site/templates/ directory of your installation. Any stylisation is up to you. It is also worth noting that the DB structure allows every field to be reusable. They are not permanently associated to one particular template, but can be associated with many. So, you may create an article_meta_keywords field that you want to use in lots of different templates since it is a very common element. When you create a template in the backend, you can add whatever fields you like from the drop down list, so this is not only possible, but very useful! I have just written a full tutorial that explains some of these issues. It sounds like you may not need to do the entire thing, but reading it through might put some of this into context. http://wiki.processwire.com/index.php/Basic_Website_Tutorial I am still cleaning it up, but a lot of the info is there! Please let me know if there is anything in it you find confusing - I will sort it out. Joss

Okay, that was just an excuse to get back at me about my dog!! Claudio, thanks a million for doing that. I can now go through and fine tune. Yeah, I hesitated using the term. I have been struggling with the term "template" a bit - not that its the wrong term but it applies in so many ways in PW: It is the files that are responsible for the display It is the process of grouping fields It it the controller that dictates how the page creation system works (limiting what children/parents can do, for instance) And it is the more philosophical idea of a particular content idea. When you chat, it is fine. But from the writing point of view, where the ideas need to be clear and well differentiated, it is a bit of a headache. I will be going through the article again this morning, so I will be looking at those issues and try and clarify it. Thanks to both of you! Joss

Hi ashrai! Welcome to the forums! There is a tutorial about adding images here http://processwire.c...k-start/images/ (it's admittedly a bit hidden because it's considered "in progress") Make sure you understand the difference between single images fields (Maximum files allowed = 1, in the field options), and multiple images fields. On the first one $page->field returns an object, and on the former it returns an array. On the single image you return the url simply like this: echo $page->image_field->url; And on the multiple, you return the several urls like this: foreach($page->images_field as $image){ echo $image->url . "<br>"; // this will print one url per line } Well, all this is explained in that tutorial I linked to.

Yes, it looks much better with more icons then with the lonely "f" The pictures in the slider are also infinitely better now without distortion. Nice!

One way is to make the whole thing into a process module. Take a look at Ryan's example (https://github.com/ryancramerdesign/ProcessHello), that's where I got started.

Okay, shot through the General Support (30 pages) I found a few that were moved topics, 5 others where the poster had answered their own question and one that I answered for fun. (See Diogo's post above) The ones where they had answered their own questions were from experienced users. I did not find ANY in General from new users that were unanswered. Oh, there was one. It was "post your questions here" from some bloke called Ryan back in December 2010. I wonder what happened to him? Probably went off and used Joomla.... That is a pretty good record! One very impressed Joss

Thanks for pointing this out, I did read what Ryan said about this and also I know, that I'm not the first one missing this. That's just why I'm writing: it just seemed like there wasn't any clear plans and I wanted to stress that I would appreciate to see this in core a lot. Oh, this is really helpful, must have overlooked it... sorry. I'm still going to play around with Fieldtype::___savePageField(), looks like the right place to try this at the moment. Just need to conjure up some more time first... edit@interrobang: I just read your answer after posting, really helpful though. I already read about the regex support in the dev branch. Didn't try it already, but it is certainly a very nice addition. Still, what I was going for was more targeted on something else, namely a good structure in the API to hook custom validation with all bells and whistles in simple modules. Especially that bit about "saving when it doesn't validate" is something I want to get around. This is something that works the other way around in most other frameworks/cms/cmf I know so far by default and it always made sense to me.

Good one soma! I think it would be enough to have it enabled only for logged in superusers.

+1 for this; and I as well wanted to package ChromePHP into a module... You beat me to it, will install this ASAP

Good job Soma! I like the way you're thinking - I had a module with just slightly less functionality coming up, this week even . But now I don't need to find time to finish it as you've already done things bigger and better. One thing I'd like to see is a little if-statement to disable this when $this->config->debug is false. That would prevent internal structures being displayed at production stage if (when!) debug-mode has been properly disabled.

First of all, Soma, this looks VERY nice! Will install it right now One thing that might be worth mentioning is that since Windows doesn't have getrusage() implemented (correct me if I'm wrong) this might cause some problems in Win-environment. Might be worth checking if it's available first and possibly even providing an alternative solution?

This is a joke not?