Leaderboard

Hi, here is one of our recent processwire sites. Since I am really terrible at talking about what and why we did things -- the main reason why our own website is, well, not-so-content-heavy , just have a look at the page and ask stuff if you are interested and I'll try to answer. http://www.krfrm.de The Kulturregion is a group of towns and regions in the RheinMain area around and including the city of Frankfurt, and they orchestrate some common cultural events that are part of a greater topic, like "gardening culture" or "industrial heritage" with guided walks or concerts or talks and so on. The old website didn't allow the editors, who already worked content-wise for the brochures and info leaflets, to add stuff themselves, so the site was not very actual. We were tasked with the responsive webdesign and development, based on ideas and visuals of the graphic designer and collaboratively refined with working prototypes. the budget was super-tight, the time frame from first contact to launch was six months. the site will continously be expanded with new features based on the editors and visitors input. We are very happy with the decision to use processwire, which turned out to be a great tool for the different aspects of the site: FRONTEND: since pw is completly markup agnostic, we could tailor the code using susy-grid and a sass/grunt build process to our needs and the changing art direction (in which we luckily had something to say as well) BACKEND: during the development we had several spec-changes regarding the structur and content. pw's way of sticking together fields in templates could cover quickly every new or changed request EXTERNAL DATA: using pw's api, it was very easy to import all the events' data as then editable pages, categories etc. categorization and relations to projects, searchability over dates - it took some headscratching and good thinking about the structure, but once in place, it was very flexible. and expandable, which is a important thing since this site will grow with each new "project" (the larger theme for events) that will be added. All in all we a very happy with the result, which hopefully will always be work in progress

Sometimes you have clients who will login to the admin, and they perhaps only need to access a few areas of the site, such as: a product or blog list (ListerPro) site settings formbuilder entries specific front end pages documentation helpdesk backup interface Server health or server status (for example site5 has a page for every server to see it's status) Link to a bookmark (page tree bookmark for example) - this is awesome by the way Run a special action like clear a wirecache or other custom caching Add a billing or late payment notice Add an alert about upcoming server maintenance The Problem: How can you collate all of these diverse links and messages into 1 page, as fast and easy as possible, make it hassle-free to add stuff to it, maybe some messages, change the order of the links etc. In some systems this is called the Dashboard. You can make one in a few minutes using: 1.) Admin Custom Pages 2.) ready.php in your site folder Steps: Install ACP create a file inside templates for your dashboard (e.g. _ac_dashboard.php). Create your dashboard page below the admin branch of the page tree, assign it to ACP, and set the template to use to the one you created. This example will display a table of quicklinks. Contents of the dasboard file: <?php wire('modules')->get('MarkupAdminDataTable'); ?> <h3>Title of site here</h3> <div id='ProcessFieldList'> <table id='AdminDataTable1' class='AdminDataTable AdminDataList AdminDataTableResponsive AdminDataTableSortable'> <thead> <tr> <th>Item</th> <th>Comment</th> </tr> </thead> <tbody> <tr> <td><a href='<?php echo $config->urls->admin?>blog/'>Blog</a></td> <td>Filterable/Searchable listing of blog posts.</td> </tr> <tr> <td><a href='<?php echo $config->urls->admin?>news/'>News</a></td> <td>Filterable/Searchable listing of news items.</td> </tr> <tr> <td><a href='<?php echo $config->urls->admin?>projects/'>Projects</a></td> <td>Filterable/Searchable listing of projects.</td> </tr> <tr> <td><a href='<?php echo $config->urls->admin?>page/'>Page Tree</a></td> <td>A hierarchical listing of the pages in your site.</td> </tr> <tr> <td><a href='<?php echo $config->urls->admin?>settings/'>Site Settings</a></td> <td>Global site settings</td> </tr> </tbody> </table> <script>AdminDataTable.initTable($('#AdminDataTable1'));</script> </div><!--/#ProcessFieldList--> You only need this if you want to redirect logins to the dashboard: add to ready.php (where 1234 is the ID of your dashboard page): if($page->template=="admin" && $page->id == 2) $session->redirect($pages->get(1234)->url);

SimpleForms Alpha bumped to 0.7.0, with a few chages. Firstly, SimpleForms is now ready for translation. If anyone is willing to translate the module, please go ahead - your contributions are most welcome. Side note: there isn't much to translate at this point, and some messages may change as I go along. Next, template stylesheets are now automatically prepended to each HTML template if found. The way in which this works is simple. If you have a CSS file with the same name as the form being worked with, that stylesheet will be prepended to every HTML template for that form. Of course, if you're not using HTML templates (these are indeed optional), then stylesheets will simply not work. I am considering the possibility of being able to define for each template whether or not it should have the form stylesheet prepended - some templates will not require such a stylesheet. (Input here is also most welcome.) I've also made a few changes (additions, rather) with regards to using forms without AJAX. A few new methods have been added for the rendering of errors. Before, you would simply wrap $simpleForms->fieldError('name') inside a <div data-simpleforms-fielderror="name"/>. The problem that this brings about is that if no error is present, and you have added padding to the error block, it would always be visible. Now, you can use a renderer-method or a has-method to assist. Either of the below will work: <!-- Render the default field error markup --> <!-- Result: <div data-sf-fielderror="name">This field is required.</div> <?= $simpleForms->renderFieldError('name'); ?> <!-- Or render it yourself, if you want to style the div. --> <!-- The data-sf-fielderror is completely optional if you wish to not use AJAX. --> <?php if ($simpleForms->hasFieldError('name'): ?> <div data-sf-fielderror="name" ><?= $simpleForms->fieldError('name'); ?></div> <?php endif; ?> The same applies for $simpleForms->formError(), where you can use hasFormError() and renderFormError(); Note: This change is only for those who specifically choose not to use AJAX, and does not support the dual-approach, where AJAX is enabled, but the visitor does not have JS enabled. If you want to use AJAX (always recommended), then you should always render the error blocks, even if they're empty. Remember that they are used by the front-end module, which hides them when they are not needed, including when the page is loaded. You'll also notice from the above example that the data attributes have been renamed. Instead of the full data-simpleforms-*, simply use data-sf-*. Next on the todo-list: Two major things coming up are support for multi-language form messages (form and field errors, success message) as well as module configuration, which entails being able to set module-wide defaults that affect all forms. @teppo: Thanks for the mention on ProcessWire Weekly today - much appreciated, as always.

Hi everyone! With Batcher you can batch-edit and create Pages in the Pw Admin. If you install this module, you get a new Page "Batcher" under Setup. Modules page: http://modules.processwire.com/modules/process-batcher/ Github: https://github.com/wanze/ProcessBatcher Editing How does it work? Search your pages with a selector. You can check if you want to include also hidden/unpublished pages with the filters. Select the pages you want to execute an action (the action only gets executed on "checked" pages). Select the action and if necessary, additional data like the new parent or the new template. Execute. Supported actions: Publish/Unpublish Pages Hide/Unhide Pages Lock/Unlock Pages Trash Pages Delete Pages Change Parent Change Template Batcher does the following permission checkings for the current user: Don't display pages that are not editable Remove Actions if the user doesn't have the permissions (page-delete, page-move, page-template, page-lock) Important notes: When changing a template, data in fields of the old template which are not assigned to the new template gets deleted. When changing the parent, the template of the new parent must accept the pages template as children. This is a setting in the template under "family". Creating How does it work? Select a parent where your new pages will be added as children Add as many pages as you want by clicking "add Page" Click "Create Pages" You must enter a title and choose a template. The name is optional: If left empty, Pw will generate this for you. Includes permission checking and Family template restrictions. This means in detail: The selected parent must accept children and their template The pages template must accept the parents template User needs the permission to add children to the selected parents template User needs the permission to create Pages for the chosen Template Batch-creating tips The chosen template and the statuses are always cloned from the last row. So if you need to add 30 pages with the same template, define it first and the click "add Page" - it'll make your life easier ;-) You can drag & drop the table rows should you want to change the order. The dragging looks ugly but it works. For the lazy dogs and keybord hackers among us, you can add a new row by pressing "ctrl+n". This works (at least in firefox) only if no input has focus. After adding a new row, the title input gets the focus. By pressing 3 times tab you arrive at the published-checkbox, here the short-cut works. Restrict Batcher for a user to only allow editing or creating Create permissions "batcher-edit" and/or "batcher-add". As soon those exists, the module checks if the current user has the permissions. If you only need batch creating, check out the following module by Soma: http://processwire.com/talk/topic/2138-process-tools-create-pages-wip/ Cheers

Google today announced it's competitor to Facebooks "Instant Articles": "AMP"(Accelerared Mobile Pages)HTML. Based on open source technologies (Basically it's a set of Web Components and a JS-Framework that loads and caches resources) it seems very promising. As far as I understand media is cached, served and proxied by google (and some tech partners). Btw: processwire as a system could benefit from/partner with it, too: https://www.ampproject.org/faq/#accelerated-mobile-pages-9 I'm really looking forward to playing around with it. Anyone else already fired up his editor and started fiddling around?

Edit: The title of this post has been renamed to use the word "processor" instead of "builder" - this is not a form-building module. I'm currently putting together a simple developer-centric form processor for one of my projects, and have decided that I'd like to release it as a module as soon as it's stable enough. The idea is to separate it from the backend, and use per-form configuration files and templates instead. I could well implement a backend solution for this, but my preference is for it to be developer-centric. For me, this makes it easier to use and, of course, develop. Here's how it currently works: developer specifies forms and their particulars in a JSON file stored in the module's directory. The file includes dictations such as the name of the form, the fields it uses (along with their sanitization/validation rules), template information, and a set of emails to send when the form is being processed. An example of such configuration is: { "contact": { "name": "Contact Form", "fields": { "name": { "sanitize": "text", "rules": { "required": "Please enter your name." } }, "email": { "sanitize": "email", "rules": { "required": "We need to know your email address so we can get back to you.", "email": "That doesn't look like a valid email address." } }, "company": { "sanitize": "text", "rules": { "min(4)": "That's a tad short for a company name." } }, "contact": { "sanitize": "text", "rules": { "int": "Please enter only the digits of your phone number (no spaces or other punctuation)." } }, "message": { "sanitize": "entities1|textarea", "textField": true, "rules": { "required": "Please enter your enquiry/message.", "min(250)": "Please enter at least {$0} (but no more than 2000) characters.", "max(2000)": "You have reached the {$0} character limit. Please shorten your message." } } }, "info": { "fromName": "The ABC Accounting Team", "tel": "(011) 100 1234", "altTel": "(011) 100 5678" }, "emails": { "autoReply": { "template": "auto-reply", "to": "{input.name} <{input.email}>", "from": "ABC Accounting <noreply@abc.accounting>", "subject": "Enquiry/Message Submitted - Thanks!" } } } } As seen in the 'emails' key, templates can be defined for each email. These templates can be plain/HTML/both, and accept information regarding form input, the 'info' key, and a custom stylesheet, which is created as a file, but imported directly into the HTML version of the template. The module will also come with a jQuery module to assist in processing the form. Frontend is up to the developer/designer. Currently, the directory structure of the module is: root - forms.config.json / templates / form-name - template-name.html - template-name.css - template-name.txt I'm now thinking that it would be better to change the structure to this: root / form-name / templates - template-name.html - template-name.css - template-name.txt - config.json That is: each form will have its own folder containing configuration and templates. So I'm starting this thread to ask the following: Firstly, what do you think of this idea, and do you think you would make use of this module? Of the two structures above, which one would you prefer? Would you want the ability to make use of attachments in your emails (such as a logo)? (If I'm not mistaken, we'd then need to require WireMailSmtp or WireMailSwiftMailer...) As a side note, it's worth mentioning that this module is really intended to be used on small- to medium-sized sites that require multiple forms where developers are not in a position to obtain Ryan's excellent FormBuilder. Any input here is most welcome. (And yes, as gathered by my signature, the module is called SimpleForms. If you have a name suggestion, please feel free...)

I'm currently developing about 4 websites in ProcessWire as I've moved all my bespoke development away from WordPress. I'm so happy I've found ProcessWire and I've been recommending it to all my developer friends. Seriously @Ryan, you are a very smart man. Thank you for bringing us such a great CMS/CMF and releasing it for free. --- Jump-Inc is the first site that I have released using ProcessWire, I'm very keen on staying active the the PW community and I will be sharing which sites I have completed using PW. http://jump-inc.uk/ Jump-Inc is a trampoline park opening in the UK, I have used the responsive framework UiKit and for the parallax slider I have used Revolution Slider. I have used @Soma 's ColorPicker module for the gradient picker. Keep up the great work Soma, I love the fact that you can define a selectable colour pallet. Thanks again ProcessWire and the people who contribute to the project.

YAML support would be cool!

Would anyone be interested in YAML support (as opposed/in addition to JSON) for the form config?

Yes, that's exactly what I ended up doing. I just didn't realize that was an option until pwired provided the link to the other thread.

That looks intentional.

One small thing: http://jump-inc.uk/book-now/ See the small height difference in the purple bar - Chrome OSX

I don't think there is anything simple to diff database vs the dump; (additionaly, if you do the diff dump only, you'd then have to diff database versus set of dumps… yeah.)

Great stuff this... great stuff indeed. One question, would it be possible to pick a specific value from the matrix? So on a certain page, I would like to spit out the value at row 2, column C, without having to loop the whole pricetable to find that specific value. My current implementation is quite inefficient: foreach ($accommodation->pricetable AS $p) { if ($p->row == $weekPage->id && $p->column == $pricePage->id) { echo $p->value; } } Thanks for a great module!

$prev = $page->prev->id ? $page->prev : $page->siblings->last(); $next = $page->next->id ? $page->next : $page->siblings->first();

Thanks for these modules. When I try using the Stripe module, I get the following error: Fatal error: Exception: Method PaymentStripe::embed does not exist or is not callable in this context I can see at the end of the module code the default for the switch is calling this. It appears as though it's here that determines the "step" and should reload with the appropriate get variable in the URL. I'm not sure how to go about making this work. Any help would be appreciated. Thanks. Scratch all that. I was forgetting to call the charge url with ?step=process. Rookie mistake. Works great!

So true! He's possibly a before hook on topic::render

Maybe a bit late but locking this thread down because it has gotten to the stage where it doesn't contribute anything worthwhile and it's just silly and all over the place.

Hey guys, we published a new website made with PW. Anja is a German artist. We designed an exhibition catalog for her previously, and now she asked us to create her website. Here it is: http://anjawiebelt.com/ The site is extremely simple, and PW didn't have to do anything too heavy, besides some calculations for displaying the dates in the right order. Most of the work was on the frontend and went into creating the customised slideshow — see also the responsive version. See also on our website for more details http://ed-works.com/projects/anjawiebelt.com/ If you see any issue, please tell

Hi @ArtArmstrong - thanks for your efforts with this and for sharing here. Just in case you missed it, the PW core now has FieldtypeOptions (http://processwire.com/blog/posts/new-options-fieldtype-processwire-2.5.17/) which is an enhanced version of FieldtypeSelect which works with InputfieldRadios, InputfieldChecboxes, InputfieldSelect, InputfieldAsmSelect, etc. Perhaps there is still an advantage to your module - I'd be curious to hear more. Thanks again!

Hi Congomonster, you have to change the fieldname. in your case scf_fullName in e.g. scf_Nachname. Be carefull. the prefix scf_ is important. And you also have to change the values ( input - Tag ) in your form. But here you go without the prefix! Don´t forget to adapt the fieldnames in your modulconfiguration. also without the prefix.

Part II: Using a Profields Table [Note: this part requires you to own ProFields] 1.) Setup a field of type table for settings, I call it settings_table. It will have 2 columns, setting and value 2.) add it to your template (example would be if you had a settings template). 3.) Add some settings.. | site_title | My Great Site | |------------|-------------------------| | phone | (666) 777-8888 | |------------|-------------------------| | slogan | Tulips Rule | |------------|-------------------------| | facebook | http://www.facebook.com | 3.) Place this code in your _init.php or wherever you have global stuff.. replace the page number with the appropriate page number: $settings_table = $pages->get(1020)->settings_table; foreach($settings_table as $row) { ${$row->setting} = $row->value; } now you can do this: echo $site_title echo $phone echo $slogan echo $facebook - - - ...and one might wonder, what is to prevent a client from inadvertently changing the setting name or even deleting a critical setting and consequently breaking their site? with some jQuery, and the help of admin custom files (courtesy of martijn-geerts) you can disable any existing setting name from being edited. or deleted; add this to your AdminCustomFiles/ProcessPageEdit.js file: $(function(){ $('li.Inputfield_settings_table tr').each(function(){ setting = $(this).find('input[name*="_setting"]'); value = $(this).find('input[name*="_value"]').val(); icon = $(this).find('i.InputfieldTableRowDeleteLink'); if(value) { setting.addClass("disabled").attr('readonly', true); icon.removeClass("InputfieldTableRowDeleteLink fa-trash-o").addClass("fa-lock"); } }); }); this does assume that the table is named settings_table, the setting column is named "setting" and the value column is named "value". you can also add this to your AdminCustomFiles/ProcessPageEdit.css li.Inputfield_settings_table tr input.disabled { background-color: #e8e5e5 !important; color: #949494!important; } Here is a screenshot of this in action: Edit: added instructions to protect the settings names, prevent deletion, and change the color to differentiate the field status.

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

Sounds great, I look forward to seeing it. As promised, here's a full example of a simple contact form. This is bare bones, but safe. I've left out spam prevention measures, which I'll be happy to follow-up with if you'd like. Below is an entire template file. I figured it was simpler to show this way rather than splitting into multiple files. Though when forms get really large, I tend to split them in multiple files (and include them). But for smaller forms, I do it like the example below. /site/templates/contact.php <?php $sent = false; $error = ''; $emailTo = 'nikola@company.com'; // or pull from PW page field // sanitize form values or create empty $form = array( 'fullname' => $sanitizer->text($input->post->fullname), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), ); // check if the form was submitted if($input->post->submit) { // determine if any fields were ommitted or didn't validate foreach($form as $key => $value) { if(empty($value)) $error = "<p class='error'>Please check that you have completed all fields.</p>"; } // if no errors, email the form results if(!$error) { $msg = "Full name: $form[fullname]\n" . "Email: $form[email]\n" . "Comments: $form[comments]"; mail($emailTo, "Contact Form", $message, "From: $form[email]"); // populate body with success message, or pull it from another PW field $page->body = "<h2>Thank you, your message has been sent.</h2>"; $sent = true; } } if(!$sent) { // sanitize values for placement in markup foreach($form as $key => $value) { $form[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } // append form to body copy $page->body .= <<< _OUT $error <form action="./" method="post"> <p> <label for="fullname">Your Name</label><br /> <input type="text" id="fullname" name="fullname" value="$form[fullname]" /> </p> <p> <label for="email">Your Email</label><br /> <input type="email" name="email" id="email" value="$form[email]" /> </p> <p> <label for="comments">Comments</label><br /> <textarea id="comments" name="comments">$form[comments]</textarea> </p> <p><input type="submit" name="submit" value="Submit" /></p> </form> _OUT; } // include site's main template which outputs everything include("./main.php");