Leaderboard

This is a little php tip that might come in useful for those who are new to this php stuff (like me) Repeater fields are wonderful in ProcessWire, but if, like me today, you are faced with a list of a hundred odd items, then they can become a little overwhelming to use. Sometimes all you want to do is put a list in a textarea and hope something wonderful will come of it. Well, Explode in php is just the wonderful thing you might want. In this example I am creating a simple list where each list item has three parts - a name, a type and a colour. Create a textarea field and add it to your template. Create a page and in the textarea add your list - something like this, perhaps? Ford Fiesta,1.3xl,red Morris Marina,GT,blue Hilman Hunter,1.6SE,green There are two delimiters here - a new line between each car entry (yes, those are all cars) and a comma between each detail of the car. On our template, we first grab our textarea and "explode" it to separate the lines into an array: $cars = explode("\n", $page->my_textarea); "\n" is the new line markup and we are identifying it within $page->my_textarea and then exploding at those points. We now need to loop through out array: foreach($cars as $car) { All familiar so far. However, we need to split up those comma delimited bits so we can deal with them separately. We will use explode again: $car = explode(',', $car); In this case we are identifying the comma within the string $car and exploding it. This has now created an array of bits that we can access with indexes. So here is a completed version: <?php $cars = explode("\n", $page->my_textarea); foreach($cars as $car) { $car = explode(',', $car); echo "<h3>{$car[0]}</h3>"; echo "<p>Car Model: {$car[1]}</p>"; echo "<p>Car Colour: {$car[2]}</p>"; echo "<hr>"; } ?> The indexes are within the square brackets and start from zero - though you can use them in any order, of course! And there you are - looping happily through your long list. I have just used the same principle to list 100 music tracks on my new site which I will showcase in a day or so. Obviously, you could have achieved the same thing with repeaters and had the luxury of being able to reorder them and edit them easily - but sometimes all you want is a silly list, and this method does silly lists very well. Joss PS: Thanks to Apeisa, because I stole this from his Thumbnails module!

Thanks for this, Joss. It's nice to have not only PW but also PHP tutorials here It should probably also be noted that an alternative method for handling CSV strings (which your list there seems to be, though admittedly a very simple one) is to use str_getcsv, which is available since PHP 5.3.0. In the context of your sample code it would look like this: <?php $cars = explode("\n", $page->my_textarea); foreach($cars as $car) { $car = str_getcsv($car); echo "<h3>{$car[0]}</h3>"; echo "<p>Car Model: {$car[1]}</p>"; echo "<p>Car Colour: {$car[2]}</p>"; echo "<hr>"; } There's not much difference between these two methods really, as far as I know even performance-wise they are pretty much equal. Still if there's even a small possibility that you'd need to handle more complex CSV content at some point, using str_getcsv makes sense -- that way you won't need to worry about things like commas inside quotes, escaped characters etc.

Just re-read your message, and just wanted to make this clear: I do not make assumptions about your design. When I ask questions, challenge your ideas, or propose alternatives, I'm merely testing the boat to see if it holds water - it's nothing personal, it's just the way my mind works. And most of the time, you are able to clarify your objectives or explain your choices to my satisfaction ... as Einstein said, "question everything" - this is how we arrive, not at perfection, but as you say, the best possible choices gives the context and goals. Please assume that I'm trying to help - if my tone suggests otherwise, I apologize, I'm not always eloquent with my words. I never got on the Drupal, Joomla or WordPress forums to try to help there - because I never saw any of those projects as being worth my time. This project is. So I hope you'll put up with me, even if I ask obnoxious or provocative questions at times. As Rafael Dohms just pointed out on Twitter: Discussion is evolution, whether you are right or wrong the exercise of discussing will teach you something new.

nevar.do this u.must dothis $q = $sanitizer->selectorValue($input->get->q); bfore selector u put.in

PW Images Manager (beta) Just a weird little screencast trying to show how it works. (out of date a little, tags now use a textfield for easy copy/paste) This module allows you to manage images from one central repository. You create a root page "/images/" where you can then add categories and images as pages. From there the new admin page created "ImagesManager" will show categories and images added in a ajax data table, from where you can see and search/filter all images, upload and create new categories and edit images too. Every image will also show an image tag generated to copy into a textarea. This tag looks like this: {image=/path/to/image/imagename/, width=200}The width=100 is the thumbnail size used to output the image.You can also have additional segment to contain classes: {image=/path/to/image/imagename/, width=100, class=align_left}Or you can enter the id directly: {image=1033, width=100}Once inserted into a textarea field it will get parsed when saved and loaded automaticly. It will store an abstract id tag in Database and convert it back to the image HTML tag. So after first save you'll see the image inserted in a Wysiwyg and be able to resize and place it as usual. Once it's inserted somewhere Images Manager will show a search link with the pages containing the image (you can configure the fields int the module setting). You can change the image or move it to a different category, it will still work and show the correct image. This also works with multi-language fields.You can still also use the regular insert image dialog in TinyMCE and chose image from those pages. And it will start keeping track of those as well (they're the same after all). You can use those central images pages also with page fields to reference them single or even whole categories, search them with API and do what you like. Images Manager will also parse the page render on front-end and replace any found image tags with the HTML code. It will also look for a description on the image and output it as alt tag. If you want to have multi-language description you can add a `image_description` TextLanguage field to the image page template and have images parser use them. Along with this module, you can also install the `PageListImageLabel` module to add thumbnails to the image pages in the tree. To get it working you need to have the basic setup: 1. Create new `image` field with input setting to 1 max image 2. Create new `image` template and add `title` and the `image` field created before 3. Create a 'image-category' template with only title and allow the `image` template and `image-category` as child pages under family settings. 4. Create a `image-root` template with only the title field for the root of the images tree. Allow only `image-category` as child page under family settings. 5. Create the root page with the `image-root` under the home page as "/images/" 6. Done. The structure of the image repository looks like this /images/ /cagetory1/ /imagesxy/ /category2/ /image2/ /image3/ Now you can use the ImagesManager to add categories and images. But you can also still use the page tree to add new stuff as usual. The root path, template names and fields are configurable in the module settings. How to install the module: - Download the contents of this repository and put the folder renamed as "ImagesManager" into your site/modules/ folder - Login in to ProcessWire and got to Modules page and click "Check for new modules". You should see a note that the two new module were found. Install the "ImagesManager" module. - A new admin page "ImagesManager" should appear in the top menu. - You may configure the option on the module screen to suit your needs. Download at github https://github.com/somatonic/ImagesManager Thanks and enjoy.

Looking at the screen it must be a multiple images field. In that case it's an array and you have to either change it to max 1 image int he field setting or chose the first from the array: <?php $image = $page->logo_image->first->size(287,80); echo "<img class='logo' src='{$image->url}' alt='{$image->description}' />"; ?> Ah didn't read careful.. This is also possible I think: <?php echo "<a href='{$config->urls->root}'><h1><img class='logo' src='{$page->logo_image->size(287,80)->url}' alt='{$image->description}' /></h1></a>";?>

Lol love that analogy. Either way you can end up with a problem. SInce finally you decide which one you think makes most sense. I understand if one wants or needs this feature and I added a option to enable hard lock. Pushed an update 1.0.1 to github now. - added option to enable hard lock - made alert message translatable https://github.com/somatonic/PageEditSoftLock

I was late at night finishing a new website. It's for a Portuguese poet/painter/musician that is not very known. The website uses some Flash, but PW is still taking care of some stuff. Any suggestions are welcome, since I didn't have lots of time to make this one. Hope you guys like it http://www.joaovidei...osartes.web.pt/

Nice work diogo! How did you handle those highres images while keeping the .swf file so small? They look fabulous on my Retina screen! btw. long lives flash!!!! Cheers

I use this:

You're in luck http://modules.processwire.com/modules/markup-htmlpurifier/

I would say that the blog profile is not the best place to start. It uses more advanced techniques and was designed to be a demonstration of them– These are techniques I don't even use in my own site development, but felt like we needed a profile that would appeal to those looking for a dedicated MVC strategy. The best place to start really is the basic profile that comes with ProcessWire. When you understand that, you really can build anything. If you are wanting to go further, you might like to look at the skyscrapers profile. But the important thing to remember is that there is no "right" way to build your site in PW. This is why even tutorials can be a mixed blessing when you are learning, because they reflect one approach that may not necessary be the right one for you. Beyond the basic profile, you just need to read $page, $pages, PageArray and about Template files. Ignore everything else, because you may never need it. Don't feel like you need to remember or understand everything on those pages. But read through them and make note of what's there. These pages cover 99% of what you will do in ProcessWire from the code side… and probably a lot you won't ever use too. Once you get going and developing stuff, you'll want to keep the Cheatsheet open, which has sections that cover what's on those links above more succinctly. In ProcessWire, you should be comfortable with HTML markup and CSS. But it's less important that you know PHP. You only need to learn a few basics. You really don't need to know any more than you need to know EE tags. Know how to get in and out of PHP from HTML markup. i.e. <?php ... ?> Know what a $variable is – just a place to store a value. Most ProcessWire API functions return a value. Know how to use an if() statement. In PW, you'd use an if() to test if something had a value you wanted to output. Know how to use a foreach(). In PW, you'd use a foreach() to cycle through a page's children, or the results of a $pages->find(...). Know how to output a value, whether: <?php echo $value; ?> or <?=$value?> …both do the same thing. Know how to use include() to include another file, i.e. "<?php include("./header.inc"); ?> I think that covers all you would have to know to do most things from the PHP side in ProcessWire. Can anyone think of anything major I'm missing? Lastly, when you are developing, enable debug mode in /site/config.php: $config->debug = true; This will ensure that you get helpful error messages rather than ambiguous ones.

Hi, for german native speaker i found this: http://lukasepple.de/blog/2012/08/grundlagen-processwire/#x - Thanks Lukas

I found myself searching for an smooth workflow to collaboratively work on a process wire project and had the challenge of including the mysql data into version control to keep it in sync with the rest of process wire. Here is a solution with git hooks, that Ben Kubertis came up with: http://ben.kulbertis...-and-git-hooks/ Step 1: When commiting you want to fetch the latest changes of the database. Edit the "pre-commit.sample" hook located in /YourRepoDirectory/.git/hooks/ #!/bin/sh mysqldump -u [db_user] -p[db_password] --skip-extended-insert [db_name] > /PathToYourRepo/database.sql cd /PathToYourRepo/ git add database.sql Enter your mysql login details and git repository paths and then save and rename it to "pre-commit" That way each time you commit, any changes of the db will be downloaded and kept under version control Please note: If you only have modified the database and didn't touch any other files, you will have to manually pull the database updates, since git commit needs "changed files" to successfully commit. Step 2: When you checkout or merge branches, then you always want to fire up the belonging database again. Create another two hooks named "post-merge" and "post-checkout" with the following content: mysql -u [db_user] -p[db_password] [db_name] < /PathToYourRepo/database.sql NOTE: !!! Please test this first on a dummy project, in order to not mess your database up !!! When working with MAMP you probably have to add the path to mysql and mysqldump as well; Simply put /Applications/MAMP/Library/bin/ in front of it

Table of contents Introducing the App and author Needs First version in PHP/MySQL without any Framework Why Processwire? App Version 1.0 Introducing the App and author Hi, my name is Luis and i´m a German based Web and Frontend Developer. I started 2010 with my own Internetbusiness and noticed at the very beginning of my business that it takes to much time to handle my accounting, invoices and clients. The main problem was that I needed for almost every task his own software solution, so the usual workflow in creating an invoice was something like open the CRM Software because the invoice software was good in creating invoices but bad in managing and searching clients, copy and paste the client into invoicing, create the invoice and handle it over to the accounting software. Not good at all... So I decided to create my own solution to fit my needs in the office management. Needs Invoicemanagement and creation Clientmanagement, very basic CRM Accounting Multi-User Simple financial stats about the Keyfacts of my business possibility to export the data for my tax consultant PHP / MySQL to work with it on intranet After pointing out my personal needs and writing down my usual workflow I started to develop the first version. First version in PHP/MySQL without any Framework In winter 2011/2012 I completed the very first version of my OMS (office management suite). The whole project was written in good old fashioned PHP from scratch. I´ve used this version till November 2012. Why Processwire? In mid 2012 I discovered Processwire and had no idea in how many ways this tool would change my life as webworker. After playing around with PW and developing the first little sites I had a little talk with my tax consultant, she said that my financial reports are pretty good and help to save money. (less time, smaller invoice from her) Why not publish the tool? Well, at this point my app was solely written for my needs, without possibilities for an Multi-User environment or for use in an companies Intranet. I finally decided to port the app to PW because of it´s flexibility, scalability and built-in user-roles. I had to dig deeper into PW at this point to see if I really could. Late 2012 I started porting the app in PW and was surprised how insanely fast developing could be. The whole database structure was ported into PW Pages, no SQL query is done by the app itself. It was possible to recreate the core functionality in about 2 weeks, implementing the Login and Multi-User functionality took another week. WebApp Version 1.0 https://youtu.be/PIgUMLZEcIU The app is now available for purchase @ www.misterui.de * also Processwire with an own eCommerce Script

Lets see if we can get a quick-start tutorial going here. We'll start with something really simple and then work up from there. Tell me when something makes sense and when it doesn't and we'll adjust as we go. My thought is that we'd make a tutorial that plays on the 'hello world' phrase and lists information about planets in the solar system, starting with Earth. To keep it simple, we'll assume that the basic site profile is installed, as that's what comes with ProcessWire (so there's no need to uninstall anything). But we won't start using any of it's files tat this stage. Instead, we'll start out by creating our own files. STEP 1 – Create a template file Create a new file called: /site/templates/planet.php, and copy+paste the following HTML into that file: <html> <head> <title>Earth</title> </head> <body> <h1>Earth</h1> <h2>Type: Happy planet, Age: Millions of years</h2> <p>Earth (or the Earth) is the third planet from the Sun, and the densest and fifth-largest of the eight planets in the Solar System. It is also the largest of the Solar System's four terrestrial planets. It is sometimes referred to as the World, the Blue Planet, or by its Latin name, Terra.</p> </body> </html> The above is just a plain HTML file with nothing specific to ProcessWire. We will use this as the starting point for our template, and we'll go back and modify it later. STEP 2 – Add a template to ProcessWire Login to ProcessWire admin and go to Setup > Templates. This page shows a list of templates currently in the system. Click the Add New Template button. On the next screen that appears, you'll see it found your "planet" template file. Check the box next to the planet template and click Add Template. You may ignore any other options that appear on this screen. STEP 3 – Creating a page using your template Your planet template is now in the system and ready to use, but it's not being used by any pages. So lets create a page that uses the planet template. In the ProcessWire admin, click Pages in the top navigation. This is a site map if your page structure. We want to create a new page under the homepage, so click the new link that appears to the right of the home page. The next screen has 3 inputs: title, name and template. Enter "Earth" for the title, and the name should populate automatically. For the template, select planet. Then click Save. Now you have created a new page using the template that you added. You are now in the page edit screen and you should see your title field populated with "Earth". Click the View link that appears on this page edit screen. You should see the output of the HTML from step 1. Click the back button in your browser to return to the edit screen. STEP 4 – Creating a new field Now you know how to create a template and a page using that template. You could create more pages using the same template if you wanted to. But that wouldn't be particularly useful – this template file is just a static HTML file. Lets make it dynamic by creating some fields and adding them to it. We are going to create 3 fields to represent the pieces of data that currently appear in our static template. These include the planet's type, age in years, and a brief summary. We will call these fields: planet_type, planet_age and planet_summary. In ProcessWire admin, click Setup > Fields. This screen shows a list of fields currently in the system, most of which are general purpose fields for the basic profile. For the purposes of this tutorial, we are going to ignore those and create our own. Click the Add New Field button. On the next screen, enter "planet_type" for the Name, select "text" as the Type, and enter "Planet Type" for the Label. Then click the Save Field button. Now that your field is saved, you are on the Field Edit screen. At this point, your field is created and ready to be added to your planet template. Optional: While editing your field, click the details tab where you'll see a select box for Text Formatters. Select "HTML Entity Encoder" – this ensures that characters like "<", ">" and "&" will be converted to HTML entities and not confused as HTML tags. While not required, it's a good practice for text fields like this. After you've done that, click the Save Field button. STEP 5 – Creating more new fields In step 4 we created the planet_type field. Now we want to create the planet_age and planet_summary fields. So in this step, you'll want to do the same thing for the remaining two fields: Create the planet_age field exactly like you created the planet_type field, but enter "Planet age in years" for the label. Create the planet_summary field exactly like you created the planet_type field, but chose "textarea" as the Type and enter "Planet summary" for the label. Note that a "textarea" field is just like a "text" field, except that it can contain multiple lines of text. STEP 6 – Adding new fields to your template Now that you've created 3 new fields, you need to add them to your planet template. In ProcessWire admin, click Setup > Templates > planet. You are now editing your planet template. In the Fields select box, choose planet_type, then planet_age, then planet_summary. You will see each added to the list. Cick the Save Template button. STEP 7 – Editing a page using your template Now that you have new fields added to your template, go back and edit the Earth page you created earlier and populate the new fields that are on it. In ProcessWire admin, click Pages at the top, then click the Earth page, and click the edit button that appears to the right of it. You are now editing the Earth page you created earlier. You should see the new fields you added, waiting for text. Enter "Terrestrial planet" for Planet Type Enter "4.54 billion" for Planet Age in Years Paste in the text below for Planet Summary and then click Save. STEP 8 – Outputting dynamic data in your template file While still in the page editor from step 7, click the "View" link to see your page. Note that it still says "Happy planet" for type (rather than "Terrestrial planet") and "Millions of years" rather than "4.54 billion years". That's because the page is still being rendered with just the static data in it. We need to update the template file so that it recognizes the fields we added and outputs the values of those fields. Edit /site/templates/planet.php and replace the static text in there with tags like this, replacing field_name with the name of the field: <?php echo $page->field_name; ?> If supported by your server, you may also use this shorter format which some people find easier to look at and faster to enter: <?=$page->field_name?> Here is the /site/templates/planet.php file updated to output the content of the page using tags like the above: <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <h2>Type: <?php echo $page->planet_type; ?>, Age: <?php echo $page->planet_age; ?> years</h2> <p><?php echo $page->planet_summary; ?></p> </body> </html> After making these changes, save your planet.php template file. Now view your Earth page again. You should see it properly outputting all of the content you entered on the page, including "Terrestrial planet" for Type and "4.54 billion years" for age. Any changes you make from this point forward should be reflected in the output. STEP 9 – Creating more pages, reusing your template For this last step, we'll create another page (for Jupiter) using the same template just to demonstrate how a template may be reused. In ProcessWire Admin, click Pages and then click the new link to the right of the home page. Enter "Jupiter" as the Title and select "planet" for the Template. Click Save. Now that you are editing the Jupiter page, enter "Gas giant" for Type, enter "4.5 billion" for Age in Years, and copy+paste the following for Planet Summary: Click the Publish button and then View the page. You should now see your planet template being used to output the information for Jupiter rather than Earth. CONCLUSION In the above, we covered the basics of how to develop in ProcessWire, including the following: Creating templates and their associated template files Creating basic text fields and adding them to templates Creating and editing pages that use your templates Outputting the values of fields in template files If all of this makes sense so far, I thought we'd follow up next with a tutorial to take this further: Adding and outputting photos for each planet Creating navigation that lists all the other planets that have pages in the system …and we'd keep building upon the tutorial from there. If you all think this tutorial is helpful, then perhaps this can be a draft for a real tutorial we'll put on the site, so all of your help is appreciated in making this as good as it can be.

Hi! I think answer onto this question could be useful for all PW newbies with little PHP experience like myself... Let's imagine the following "typical" scenario: We have 2 user types of logged-in users: - user-type-1 - user-type-2 Each user type may have any number of actual users. The difference btw these two types is in view access to pages: - page-type-1 can be viewed only by users from user-type-1 - page-type-2 can be viewed only by users from user-type-2 - page-type-3 can be viewed both by users from user-type-1 and user-type-2 - page-type-4 can be viewed only by one user independently on its type (let's say that it is sensitive profile info page. Or individual mailbox page.) Also we have unauthorized users (not logged-in) that should have view access to sign-up, sign-in and general info pages. Looks like PW has all needed to enable scenario above, as key ingredients are in place: - API ($user, $session) - pw access management (defining users, roles, permissions) - pw template properties (defining roles that can access pages) But how to put it together and make work is a challenge for newbie like me...) Please can someone help? I'd even suggest to make kind of sample project with step-by-step tutorial as this should be a topic of common interest...I believe.

diogo, alanfluff - thanks so much! It's so easy - I love PW more and more!

thanks Soma - btw have you considered a flattr account... i 'flattred' a few of your modules...

Put some logging right before that find, save time and $q at least. When you get that exception look what you have on for that time on your log. Might give us some clue.

You can use a git-based workflow and deploy to the live site with git-ftp: https://github.com/resmo/git-ftp The only thing I didn't figured out yet is how to automatically load the updated db afterwards into the live mysql database. For now I always update manually after pushing. And another interesting part would be to find a way to git ignore the admin credentials. But keep in mind, this kind of workflow only works for simple setups, since when your processwire project is getting more complex and the database is updating itself, because of comments, blog_post, new accounts etc. you don't want to mess with the live data. In that case better have an "pull" than "push" workflow.

Hi valan, welcome! The user-types that you refer are the roles. You vcan create as many roles as you want and assign them to users individually. Roles in itself don't do nothing, but you can define what they will do in the admin (via template access) or in your code, by using the API: if($user->hasRole($role)){ // do something } Unauthorized users would be the default guest user. You can redirect them to the sign in page by defining access on the templates or by putting something like this in your template: if($user->isGuest()){ $session->redirect($loginUrl) }; As for the individual profile pages, you can check them like this: // assuming that the profile page of each user has the same name as the user if($user->name != $page->name)){ $session->redirect($loginUrl) };

Joss, this is not fado at all... Mariza is good, but not the only one SiNNuT, the ironic thing about that link, is that they did it for mocking at others but their portfolio is not much better

I can confirm it works ok on production, at least that's where I'm using it. Thanks Soma!

I think it's ok to use on production, after all it just downloads and replaces the module. Same as you would do it manually. So with or without ModulesManager you first want to update modules in a dev envoirenment, and then push it to production if it's ok. So to asnwer your question: Just replace the module folder with the new version. Unless the module states something that you have to deinstall and reinstall cause there could be something changed that needs to be installed. Otherwise most of the updates are just replacements save.

Works easiest with modules manager: download from http://modules.processwire.com/modules/modules-manager/ install and then go to setup -> modules manager and from there you can download install and or update modules right from within pw, works like a charm!

Well I'm using the GitHub mac app because I don't have any idea how to use git via terminal

add this in header $(document).ready(function() { $('#calendar').fullCalendar({ header: { left: 'prev,next today', center: 'title', right: 'month,agendaWeek,agendaDay' }, editable: false, events: "json-code.php", eventRender: function(event, element, view ) { if (view.name === "agendaDay") { element.find('.fc-event-title').append("<br/>" + event.description); } }, eventDrop: function(event, delta) { alert(event.title + ' was moved ' + delta + ' days\n' + '(should probably update your database)'); }, loading: function(bool) { if (bool) $('#loading').show(); else $('#loading').hide(); } }); $oldTable.remove(); this in json-code.php function pagesToJSON(PageArray $events) { $json = array(); foreach($events as $event) { $json[] = pageToArray($event); } return json_encode($json); } function pageToArray(Page $event) { $data = array( 'id' => $event->id, 'title' => $event->title, 'start' => date("Y-m-d H:i:s",$event->date_start), 'end' => date("Y-m-d H:i:s",$event->date_end), 'url' => "$event->url", // event ID is the url segment 'description' => "$event->summary", 'allDay' => false, ); return $data; } // end else $calendarPosts=$wire->pages->get('/events/')->children(); echo pagesToJSON($calendarPosts); end in page where you want the calendar, <div class="tab-pane" id="calendary"> <div id='loading' style='display:none'>loading...</div> <div id='calendar' class='calendar-page'></div> </div>

As the title says, it would be nice to be able to simply change complexity requirements for the administration password. To enable/disable numbers/case/special characters requirements when changing it, etc.

Thanks Teppo - I didn't know about that one. In fact, I think you could go as far as doing: <?php $cars = str_getcsv($page->my_textarea, "\n"); foreach($cars as $car) { $car = str_getcsv($car); echo "<h3>{$car[0]}</h3>"; echo "<p>Car Model: {$car[1]}</p>"; echo "<p>Car Colour: {$car[2]}</p>"; echo "<hr>"; } ​I haven't tried this though

Hi and welcome! <title> <? if($page->alt_title) { echo $page->alt_title; } else { echo $page->title; }; ?> </title> I like the short version of this: <title><?php echo $page->get('alt_title|title');?></title> You may let PW do the work for you

Hi, Welcome to the forums. You might need to setup an extra field, for example: alt_title - for your HTML titles <title><? echo $page->alt_title; ?></title> If your alt_title field is empty - you might not need it on every page - you can just output the page title instead: <title> <? if($page->alt_title) { echo $page->alt_title; } else { echo $page->title; }; ?> </title> I hope I've understood your question. Regards Marty

And yes, also good to use "get" so it's not emulating "request" request.not do get or do post their.is no request u.find only what u bring in already know that.witch u need

Ya, in that case Macrura's solution is a good one. To sort at the end you could do like this: $images->import($images2)->sort("title");

@Grays, do not feel alone. I too am new to ProcessWire and still trying to put things together. Although I have been working with WordPress for a few years now and have spent many hours trying to hack the default ways of it, I still consider myself very green when it comes to php. I have went through each tutorial on here and read them twice. I then just started building in my local environment, I built 4 simple demo sites as reference libraries in 24 hours. I also am trying to just learn the in's and out's of the framework. I am looking forward to working/learning with it and will keep an eye out for your questions as I am sure I will have the similar ones. With that said, my opinion is to just dig in and build.

I actually wrote a serious one line reply along the lines of "WTF?". Then I deleted it once my brain engaged

... I think the forking and merging concept is a great approach that can be extended to various areas of life other than only coding. ... If only you could fork (certain parts) of someone else's life....now that would be great

Also wanted to say Grays that if you've liked EE in the past, chances are you are in the right place. I never liked the big three but I was a big fan of EE. In the end I've found that PW is like the good bits of EE, improved and with none of the downsides. The concept of being free to design first, knowing that the tool won't get in the way is something you'll be glad of every day And yes, I'm the annoying guy Horst mentions

Marty, that is good dream to have (it would be superb feature). Soma: you are a machine.

Bravo! This'll open the flood gates to folk who expect this functionality in whatever CMS they use. "Somehow connect the image manager to a standard image field" <- An uber image field I rarely stick images into a wysiwyg editor and I have dreams where the standard image field can either accept an upload or link to another image on another page.

Soma, this is awesome! One minor suggestion: Instead of copying the image code by hand perhaps it is possible to copy it on click with Javascript? One major improvement: Somehow connect the image manager to a standard image field, so you can also insert existing images to it and / or mix it with single ones. Like I suggested here: http://processwire.com/talk/topic/1188-image-inputfield-like-in-tinymce/#entry10701 I know that we would need a way of symlinking to other images than the ones in the assets/files folder. But you are creative ;-) Great work!

I think only way to know how to improve documentation and make the PW more friendly for beginners is that you new guys keep asking questions. So nothing to worry about. Good example of that is latest docs Ryan wrote about image field. "Multiple images vs single image" issue has come up numerous times up on forums and now it is clearly written right from the beginning of that page.

Whenever I see the static keyword, I cringe, and I automatically start scrutinizing my code to try to understand why I'm using it - the more I do that, the more I find that investigating your own motives for using statics usually (if not always) reveals a design flaw. It sounds to me like the Module concept really has several different things sort of huddled into one class. The fact that the class itself has a life-cycle that begins before it's even constructed, is one indicator - the class itself has an area of responsibility that begins before it even exists. Another indicator is the configurable options that affect the object's life-cycle - a static/singleton module tends to work more like an application-wide, shared service component of some kind, while other modules such as Fields are accessed through the same container (wire('modules')->xyz) where now the container suddenly works more like a factory than a service-broker. All of these differences could be modeled more explicitly using interfaces and polymorphism, as opposed to static methods and configurable options that affect the behavior of framework components and life-cycles of module objects. I would suggest rethinking this architecture for a future major release. For example, a module, conceptually, is a singleton - it consists of one set of files implementing classes, both of which are by definition singletons, hence, every module is going to have one singleton object providing information/metadata about the module itself. It would be natural to refer to the base-class for that object as the "Module". By making that it's only responsibility, you can eliminate the need for statics, and the Module class itself becomes much simpler and more lightweight. Modules that implement a module-wide configuration screen could provide the configuration model/form via an interface, e.g. a ConfigurableModule interface with a getModuleConfiguration() method, returning a dedicated configuration object of a type that implements an abstract ModuleConfiguration base-class. This eliminates the need for those static methods, and enables better composition, e.g. the freedom to extend different configuration base-classes for more specific purposes, etc. - it also isolates the responsibility of configuration and the configuration-form, enabling the code to load independently of the module itself. Similarly, modules that implement InputFields, which are not singletons, could implement another interface, e.g. FactoryModule, with a method createInstance() that returns an InputField or something else with a non-singleton lifecycle. This provides more separation and eliminates the need to load the instance-types before they're needed - and those instance-types can now deal exclusively with their area of responsibility. This also clearly separates service singletons from component instances, and gives those types a distinct lifecycle - by introducing the same separation in the framework API, this becomes more obvious to the consumer as well, e.g. wire('modules')->FancyInput refers to the FancyInput Module singleton, whereas e.g. wire('factory')->create('FancyInput') clearly is expected to create a new instance of a component provided by the module. And so on along those lines. I hope you're not opposed to making architectural changes in major releases in the future? Many architectures of this type (Drupal and WordPress to name two) are set in stone, and even major releases don't tend to break backwards compatibility, but nothing ever really improves. Drupal was actually nice when it came out, it had some good ideas at the core - but time ran away from it, because the selling point "lots of modules" is hard to argue with, and breaking backwards compatibility (in a major way) can feel like starting over. In my opinion, if you make substantial improvements to an architecture, it's worth breaking backwards compatibility. We should not reject new ideas because they're not compatible with our current world view or legacy components - if we do, we can't make never make any real progress. Anyways, </rant>

It's static so that all configurable modules can share a common interface. Some modules do stuff when they are instantiated, like hook things, queue CSS or JS files, or other things that aren't related to configuring a module (and may even be a problem if present when configuring a module). So we need the ability to know what it takes to configure a module without actually instantiating it. The only module type that would be instantiated at the same time as configuration would be an autoload module. If you are dealing with an autoload module, or you are willing to manage your own configurable vs. executable state, then there is an easy pattern you can follow. This assumes you have two configuration variables in your class, 'foo' and 'bar'. class MyFooBar implements Module, ConfigurableModule { public static function getModuleInfo() { /* you know what's here */ } public function __construct() { // set your default values for config variables $this->set('foo', ''); $this->set('bar', 0); } public function init() { // note that PW populates the actual values for your config vars, 'foo' and 'bar' // before this init() function is called, but after __construct is called. That's why // we set the defaults in __construct. Once you get to this init(), your config is // now populated, and likewise available for this non-static function below: } public function getConfig() { // you can name this function whatever you want, since it's not part of any interface // this is the stuff you would usually have in your static getModuleConfigInputfields // see how we can pull the values from $this->foo rather than $data['foo']; $inputfields = new InputfieldWrapper(); $f = $this->modules->get('InputfieldText'); $f->attr('name', 'foo'); $f->attr('value', $this->foo); $f->label = 'Foo'; $inputfields->add($f); $f = $this->modules->get('InputfieldInteger'); $f->attr('name', 'bar'); $f->attr('value', $this->bar); $f->label = 'Bar'; $inputfields->add($f); return $inputfields; } public static function getModuleConfigInputfields(array $data) { // note we don't actually need $data in this pattern $module = wire('modules')->get('MyFooBar'); return $module->getConfig(); } }

@nik, perhaps Pete can add a "love this" button

I suggest not extending the User class, and instead plugin to it with a module class UserExtended extends WireData implements Module { public static function getModuleInfo() { /* return your array here */ } public function init() { $this->addHook('User::sendThankYou', $this, 'sendThankYou'); public function sendThankYou($event) { /* do something */ } } The above would add a sendThankYou method to all User instances. Your sendThankYou method can gain access to the $user the method was called on like this: $user = $event->object; Your sendThankYou method can also have one or more arguments if you want it to: $arg = $event->arguments[0]; If you want your sendThankYou method to return a value, do it like this: $event->return = 'value you want to return'; Looks like Antti beat me to it.