Leaderboard

deer.sinnut i saw u have no avioter i feel bad so.maded one.

http://modules.processwire.com/modules/form-save-reminder/ Your welcome!

I love pyramids!

here.u go mr gazley

I'm absolutely happy ! It's nice to have such an active and friendly community.

Ryan, have you thought about having file field for attachments?

Something nice: http://fontello.com/ assemble your own icon webfont.

I wanted to give you a little preview of a new module I've been working on recently: the Form Builder module. This module lets you create simple-to-complex forms and place them in your site without any need for development. In this video we show how we can create, publish and test a simple contact form in less than 5 minutes. Then we take a quick look at a more complex form (already produced). I recommend viewing the full screen + HD 720p version so that you can see it more clearly than in this small forum embed. (note: there's no sound, so no need to adjust your volume) More about the Form Builder The Form Builder has many options for the developer to customize output and create their own themes, markup, etc. But the goal here was to build something that could enable you (or your client) to publish a form in less than 5 minutes, so that's the focus of this video. This tool is literally easy enough for your clients to create and manage their own forms. Or from a developers perspective, it takes something that used to consume hours and makes it happen in minutes. Form results save in the database and optionally can be CC'd to you by email. Result entries and be viewed, filtered by date, and even edited in the admin. You can export results to a spreadsheet as well. I'm working on the ability to export to pages, though that isn't quite ready yet. How the Form Builder will be licensed This module will be individually licensed on a per-site basis for a small license fee. It will also be available for free personal use to established forum members. Basically, I want to see if I can substitute some of my client work to focus on ProcessWire instead. And in order to do that, I need to have an income (I have a family to support). So I thought that building a special tool like this would be a way to make a go of it. A lot of you have asked to make donations to the ProcessWire project, and while we still won't be able to take donations, you will be able to support the ProcessWire project by purchasing and using the Form Builder in your own client projects. So a lot of motivation for this module came from wanting to provide something really special for all that had wanted to support ProcessWire. After a few months of work, I'm pretty happy with how this module has turned out -- it's already saved me tons of time in my client projects. So I'm thinking and hoping you guys will really like it too. I look forward to your feedback.

I've been working on making repeatable fields for ProcessWire for a couple weeks and actually now have it nearly ready. I need to do some more testing before releasing it, but wanted to give you a little preview. (please view the full screen version for better quality) Accessing repeatable fields from the API is super-easy. They are fully searchable/selectable with the API just as easily as with any other fields. So if you wanted to find all pages that had a buildings field with a floors value of 50 or more, you'd do this, for example: $pages->find("buildings.floors>=50"); Lets say you are on the page with a 'buildings' field and you want to print out all the building names and number of floors. It works exactly the same as page references: foreach($page->buildings as $p) { echo "<p>{$p->building_name}</p> has {$p->floors} floors.</p>"; }

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.

I was supposed to have jury duty today, and they didn't need me. Since I'd already rescheduled today's client work, I decided it was a good time to finally get a start on the PW modules directory. Here it is: http://modules.processwire.com I just added that DNS host so may not be active everywhere yet. There are only a few of my own modules and a couple admin themes in there at present. I need your help populating it (see below). This is just a start, and I've only had a day to work on it. I've got plenty more planned for it and appreciate any feedback you have. How to add your modules For those that have created modules, admin themes or language packs, I need your help populating the directory. When you get to the directory, you can click "Add New Module" in the sidebar and it will take you to a screen where you can add it. You assign an email and password with each module you add so that you can return to make updates as often as you'd like. When you add a module, it puts it in a pending state just so that I can keep out the spam. It emails me when you add a new one, so I'll approve any modules you add asap. Though you view your own module page and continue to make as many edits as you want to regardless of whether it's approved. Nikola and Soma: I put in one each of your admin themes for testing purposes. I've associated these with your email accounts. To modify your admin theme pages in the modules directory, click "edit" on it and scroll to the bottom in "Authentication" and click the link to retrieve your password. Enter your email address and it'll send it to you.

I think you can simply deinstall Session Login Throttle module.

Anything in TinyMCE text is pretty much raw HTML, so I've tried not to introduce any other factors into that in order to ensure the portability of the content. However, the PageLinkAbstractor module (soon to be replaced by LinkMonitor) does convert them to/from page ID references, so that links don't get broken when you move a site to another subdir or move an individual page. The disadvantage of PageLinkAbstractor/LinkMonitor is that because the link data is then abstracted, your content is no longer portable. If you ever uninstall the module, any links it has abstracted will then be broken. There's also a small amount of overhead associated with converting links to/from abstractions on the fly, but I think it's a worthwhile compromise for most. You might also want to look at the PagePathHistory module (included with the PW core). This keeps track of page moves and maintains redirects when a page is accessed at an old URL.

Thats's very similar to what I usually do. I usually just have a $selector variable and then keep appending to that one: $selector = "parent=catalogo/productos/, limit=50, id>1"; if($area_alias) $selector .= ", catalog_product_area=$area_page"; if($tipo_name) $selector .= ", catalog_product_type=$type_page"; $matches = $pages->find($selector); Not that this is preferable to what you are doing, just an alternate way of the same thing.

Thanks to Ryan and Macrura73. I decided to tackle it myself using a bit of jquery. The client relies on us for updates so dynamism was not important. We inherited the site from another company and I am more familiar with Wordpress. Thanks again. Topic Closed...

Words can't describe how much my bullshit 'o meter goes bananas . Semi-intellectual drama. Really, where do they come up with this stuff.

sorry, it just worked... I dont want anybody to waste their time with this. It all works, it was a strange display issue. Magically solved! You can delete this...

Just solved it. Was rather simple: if($area_alias){ $area_page_string = "catalog_product_area=$area_page,";}else{$area_page_string="";} if($tipo_name){ $type_page_string = "catalog_product_type=$type_page,";}else{$type_page_string="";} $matches = $pages->find("parent=/catalogo/produtos/,".$area_page_string.$type_page_string." limit=50, id!=1"); Thanks!

Once we've got the ability to publish to pages (coming soon), this might be a good use case for the Form Builder. However, I did something very similar here (http://modules.processwire.com/add/) and opted to go the route of making my own form and creating/updating pages using the API. It's easy enough to do in ProcessWire, and maximizes the control you have over it. I see the Form Builder is something ideal for collecting data. But when your needs are as much about application/user logic and publishing, as they are about the form itself, then this is not as much of a use case for the form builder. I'd hard for me to imagine a web host that wouldn't have a workable PHP mail() function... I've never come across a case where it didn't work as it should. But also know you are right about this, and there are hosts out there that for whatever reason can't send mail (which seems like a seriously disabled hosting service). So I think it's a good idea to add an alternative way fo sending mail. Though should also mention that the Form Builder saves everything in it's database, and the email part is optional. But I will put this on my list, to support alternatives on the email side. The Form Builder doesn't use Fieldtypes, just Inputfields. All Inputfields are supported by the Form Builder, except for: File, Image, Repeater, Password, PageListSelect, PageListSelectMultiple, PageAutocomplete, TinyMCE. The Page inputfield IS supported (as of yesterday) with Select, SelectMultiple, Checkboxes, Radios, and AsmSelect. These four inputs can also be used on their own (where you specify the options, like you saw in the video). It depends. You have control over the wrapper markup around the inputs. You don't have markup control of the inputs themselves. Even though you have control over the wrapper markup, it's going to be preferable for most not to change it. That's because the auto-generated nature of it means that it can provide you with theming support, collapsible fields, fieldset groups, column width, and inline error messages. If you provide your own markup, you may lose some or all of these capabilities. This is something I'm also very interested in adding, but probably won't be in the initial release version. However, we will have the ability to carbon-copy post the data to another URL, so this will enable much integration potential. For instance, I'm using this aspect to integrate with Salesforce.

Great sites Joshua. I have to admit though I'd be a little afraid of a dentist named "Shackleton":

I think that selling point may apply to CMSs that have their API as part of the template engine (Expression Engine?). Most CMSs that use template engines don't have a particularly nice or simple PHP API, and so the template engine is not just a template engine… it's the public API too. In those systems, it's not really even a question because you have to use the template engine if you want to use the system without being an expert on its code. PHP itself makes a good template engine. In our case, trying to go beyond that doesn't present any real time-saving opportunities. I want to focus efforts on the things that will save designers/developers the most time. The template engine is an unnecessary layer that consumes overhead and doesn't deliver any real benefits for us. Whereas things like the find selectors in PW are delivering significant time savings relative to the alternative. I think you might be able to realistically compare the difference of using a single selector string to using a query array (to the same function, like $pages->find). That would be a little closer comparison of template engine vs. native PHP (and maybe what you originally meant?). I probably wouldn't have originally bothered with selector strings if it weren't for the 'operator' part of them, which can't be succinctly represented in a PHP array (unless our only operator were "="). As the needs expanded to include things like OR fields/values, AND fields/values, negative expressions, and more, PHP (or any language) would have left us with a ugly, long and complex query (whether out of arrays or objects). Then we'd be asking "why not just use an SQL query?". I'm sure you will too, most of us will at some point. The query engine is not a full-on replacement for database queries. But it is meant to cover the vast majority of common needs. But there are occasions where you may still want to go in and do a query yourself. Though for me, those occasions are pretty rare.

These are icons sets collected through webresourcesdepot.com: http://typicons.com/ http://iconmonstr.com/ http://brankic1979.com/icons/ http://www.jigsoaricons.com/ http://blog.twg.ca/2009/09/free-iphone-toolbar-icons/ http://www.iconshock.com/android-icons/?prd=affcomm63789 http://www.smashingmagazine.com/2011/12/29/freebie-free-vector-web-icons-91-icons/ http://365psd.com/day/2-209/ http://salleedesign.com/resources/mimi-glyphs/ http://www.justbenicestudio.com/studio/websymbols/ http://www.designshock.com/google-plus-interface-icons/ http://picons.me/download-social.php http://www.yay.se/resources/android-native-icons http://blog.roamdesign.co.uk/?p=272

Because i use Twitter Bootstrap for some things i'm working on i really like the icon font Font Awesome for web related icons. I guess it can also be used outside of a Bootstrap.

What I would do is set up a page called Client Area or something like that, and then for each child page immediately below that use a Page fieldtype that allows you to select the user that can access that page. This way, in the Client Area page itself you can restrict it to only show pages for a specific logged-in user and stick the rest of their content under the relevant page. I would have a custom login form on the Client Area page that then simply redirects them to the right child page on successful login. It would also have some logic so that they can't jus force their way into another user's content. It does depend a bit on the structure you want to give for each user but the sky's the limit with ProcessWire. I can't go into more detail as I'm typing this on my phone, but that is one option that would be relatively straightforward if someone else comes along and fills in some of the blanks (I'm sure someone will, they're good like that).

I've been using a lot of icon fonts lately, http://fontello.com/ is just perfect for that. Other than that, I've always adored Paul Robert Lloyd's social media icons, also because of the amount of services it covers. A lot of social icons sets look great but only have icons for a few services. Not this one.

This is totally something you could do with PW. Actually managing permissions can be pretty easy depending on how you want to set up your site. Have you looked at this: http://processwire.com/api/user-access/ You have a lot of options. Sometimes I set permissions in the backend for different people to have access to edit different sections of the website... sometimes I create interfaces in the frontend that allow different groups to add/manage content. I could help with some examples... need to know a bit more about your project. But IMO PW would be my first choice for this type of functionality.

good.icoon s for space travals http://www.iconarchi...confactory.html icoons for animalls http://www.freedesig...al-silhouettes/

Ryan, This is incredible! Looks amazingly well thought out and super intuitive. I can't even begin to tell you how much I will use this — we have dozens and dozens of forms, and get requests for new ones all the time. I'd press the *like* button 100 times if I could.

Hi everyone, I have a question. I'm not legal savvy, so I need a straight answer from someone who knows. I'm currently creating an admin theme for a web application on top of processwire. The thing is, the theme will come from a commercial template for which I bought a developer license. The license states I can do with it whatever I want, sell it, use it multiple times in many projects, wreck it, whatever. The question now is, when I'm done creating the template, could I release it to the public legally? Or would I be the only one able to use it? I hope you guys are having a great day. Thanks.

I've tried to add a module but after submitting I've got a 404...

OK, after lots of research, this video has made my mind up for me Think the PW community needs to hire him

Awesome! Yeah first! Now going to look at video.... Edit: Looks really great! Thank you for this preview! For sure very useful. Now my question. Would it be any way possible to have to be able define multiple "block" templates (with different fields each) for the repeater field? Then when adding a new item, it would ask for the block template to select first. Pretty much the same as it is now, just with variable templates. I can imagine it would require something complete different concept/codewise. It's just what I kinda "expected" from (the) repeatable page element, so I don't have to use child pages anymore. It can be very handy to be able to define "blocks" that can be chosen from, to build a page. TItle, Video, Text-Image, Linklist, Text. Do you see a good way to add such "variable blocks" feature to PW through a module, much similar like this one? Maybe they're also just invisible childpages that are editable and sortable via the parent page's block field. Just blah blah, I don't really know what all need to be considered. Have you implemented this repeater using hidden pages?