Leaderboard

Another one finished (only german/swiss at the moment, english is in the works): http://www.helveting.com/ Responsive (also with responsive images + art direction via thumbnail module for the slider/header images) Form Builder for applications as always, the great thumbnail module from Apeisa Thx to Soma for the always used SimpleMarkupNavigation module and countless others ;-) Perhaps worth a mention: The locations overview, a combination of a repeater and Ryan's map marker fieldtype: http://www.helveting.com/about/organisation-und-standorte/ rendered with styled Google Maps Feedback welcome

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.

This might be obvious since MariaDB should be totally compatible with mySQL, but just wanted to say that everything seems to be working fine with running pw with it after doing some selector tests.

Technically speaking I've got nothing to add to above, but I couldn't resist commenting on one point here: alt text is not for "SEO guys." Please don't use it that way. Ever. The whole purpose of alt text is to provide meaningful alternative content for those who can't see your images -- using it to insert extra metadata for robots is very, very wrong. Sorry for the rant, but this is such a common usability fail that it's getting annoying; way too often alt texts are used either for SEO purposes ("hey, let's consider robots before humans!") or entirely useless metadata (a picture of a cat with alt text "a cat".. was that really useful for someone who can't see the image?)

Still remember this one ? Nice one from 2003 bumped on it again today on youtube and is still fueling my emotions from end 90's when wind of life was ok. Playing it while playing with pw. Feels good in both ways. Now listen to this one. Guess Blue Cantrell sampled from Dr. Dre in their song. Nice one too. https://www.youtube.com/watch?v=X_iuSoyvExo

yeah some music realy triggers memories!

Have you seen this post: http://processwire.com/talk/topic/417-extending-image-field/ It describes how you can extend it yourself to handle the extra fields.

url: www.site-name.com/processwire/

That's why I was quicker on the previous post !

I have had that issue with other forms (not PW). I am not sure of the way around it other than using javascript to disable the button once clicked - but I am not sure if that runs into other problems.

Seems like a bug. Could be related to this issue reported earlier -- looks like Ryan hasn't applied a fix for it yet.

Thanks guys for all the great feedback. I've been adding some new stuff and working on many details. I updated my first post with what is used. I've also added a fix for the overflow issue in pre code boxes: white-space: pre-wrap; /* css-3 */ white-space: -moz-pre-wrap; /* Mozilla, since 1999 */ white-space: -pre-wrap; /* Opera 4-6 */ white-space: -o-pre-wrap; /* Opera 7 */ word-wrap: break-word; Thanks for those who decided to follow my blog already, so I just need to write something interesting. But that makes it more fun when you know people are watching.

There so many ways and use cases. I think with creating your own ProcessPageAdd module like Ryan mentioned would be a way to go, though depends on the case and you might need to maintain it in case the core one has changes that need to be implemented in your copy too. To use existing ProcessPageAdd you can hook into execute or buildForm. The latter being better as it returns the form not rendered so you can manipulate it. The ProcessPageAdd module also stores the template ($this->template) in case the Template family settings is set to only one specific, but this property is protected so you can't read it from outside the module. But you can add your own checks to get the parent and check for the family settings of its template. $template->childTemplates. Then use this info to check if it's your template you want to make changes. If you get this far you can also add fields to the form you wish to. These may even existing fields you are using on your page you create, and they will get saved along with the page add form. Just as an example to do what I said above: $this->addHookAfter('ProcessPageAdd::buildForm', $this, 'hookProcessPageAdd'); public function hookProcessPageAdd(HookEvent $event){ $process = $event->object; $form = $event->return; // get the parent page if(isset($_POST['parent_id'])) { $this->parent_id = (int) $_POST['parent_id']; } else { $this->parent_id = isset($_GET['parent_id']) ? (int) $_GET['parent_id'] : 1; } $this->parent = $this->pages->get($this->parent_id); // get the template via the child templates // if only 1 defined if(count($this->parent->template->childTemplates) == 1) { $childTemplates = $this->parent->template->childTemplates; $this->template = $this->templates->get(reset($childTemplates)); } if($this->template == "post"){ // load an existing field and get its inputfield to add to the form // this will be save to the page if the created page has the field $f = $this->fields->get("date_published"); $inputfield = $f->getInputfield(new Page(),null); // add the field after the page name field $form->insertAfter($inputfield, $form->get("_pw_page_name")); // populate page name field with a timestamp $form->get("_pw_page_name")->attr("value", time()); } } So far so good. The page title field is global and is also used on the page add process, it's also required, so you can't ignore it. It would be possible to remove the title field from your template. To do this you have to make the "title" field not global (field advanced settings). Once removed it will not get added to newly created template, and also you can remove it from any template. BUT there's some drawback, since the title is not global anymore, it will never be shown anymore in the page add process also for other normal pages! This gets kinda tricky. You could remove the title field and after that make it global again, but then it will get again shown at the page add process even if the template has no title field anymore. ProcessWire doesn't know. Also when opening the template you removed the title field previously, it is added again to the fieldgroup, and you can't remove it. See? So maybe best bet would be to leave it alone and just remove it from the add page form in the hook, or just populate it with some value, and later use hooks to concat values on page save to set the title dynamic. $form->remove($form->get("title")); So with all this in mind you could add "firstname", "lastname" fields to the add form with ease. Then use a Pages::added and/or Pages::saveReady to populate the title after adding the page. Or you could also "hide" the title field on the template. When editing the template, click on the title field to open context editor, select for visibility "Hidden, not shown in the editor". This will "remove" the title field on the edit screen. But you can still populate it via API if needed.

It's unlikely a single module will provide everything everyone will need for a login/registration system, because everyone's interpretation of its requirements will be different every time. Will users use email or usernames? What other details do you need to capture about the user? What validation needs to happen on these extra fields? Do people need to validate their email addresses, or do accounts have to be approved manually? What security roles and settings need to be applied? Where do people log in? Is there going to be a "remember me" option? What happens if they forget their password? What if there's a third-party backend system that the authentication needs to tie in to? Those are just some of the considerations I can think of based on my experience of building similar bits of functionality in the past. With the frameworks and CMSs I've used, I can't remember very many of them them that have been flexible enough "out of the box" to do what I needed without having to hack where I shouldn't, or ended up with me writing my own methods to replace theirs. To pick an example. I mainly use CodeIgniter, and have done for a long time. One of the "ready-made" libraries for users is called Ion_Auth (or something like that). In every application I've written with CI, it has never been a good fit because the application demanded either much more or a lot less; or I didn't like the way it handled a certain part. The API is already there in ProcessWire, you just have to utilise it in your template files to suit the website being developed. There really isn't much to it, and because of that, any module that did try to cater for it would either only cater for a particular type of site; or it would be overly complex and force developers into its own way of working - rather than the other way round. In lots of other systems, you have to get modules and plugins for just about everything that isn't in a WYSIWYG box, because the core system is too inflexible to let you do "stuff" any other way. With ProcessWire, the API is completely open to use how you want to use it. One of the reasons I dislike Drumlapress is for the plugin-for-everything mentality. Need to split out some images in a carousel? Install plugin X. Want to put some images in a gallery page? Install another plugin Y; and never the two shall meet (because when they do, their javascripts conflict, and the back-ends are totally separate...). Several months later you might want to put some of those on a map. Oh, that will be a separate plugin Z that doesn't really work with X or Y. And then you update Drumlapress to the next version because of a major security flaw (again). Plugin X is fine, but plugin Y breaks because it's not compatible with the latest version. And then your website is broken.

it is true that the more sites you build with PW the better you get at using it and thinking in terms of a collaboration between yourself and the api, and the more you read the forum, view the source code of the profiles, modules etc, you are constantly improving and becoming less of a 'beginner', but that term also implies that PW is comparable to the big 3 (and that eventually when you are no longer a beginner you'll be able to achieve those things in the same time as you would in W/J/D), and as Ryan recently pointed out, it's really not, and probably will never be something that can be compared 1-to-1 with those fully interfaced options. The more you know about and work with PW, the more you come to realize that there really couldn't be a generic frontend user management 'module' since the needs of any such system would be unique to the business/application logic of that project. The productivity and simplicity that the clients get through having their site be 100% custom in terms of both the front and backend is really priceless, and that extra time it might take to build something custom as opposed to using a pre-built component/module/plugin pays off over and over again for years to come. I have built a lot of sites with Joomla and a few sites with Wordpress. In 90% of those sites (that are stuck on those CMS) the clients still regularly contact me to perform content management work, because as simple as they might seem to techies, they are incredibly confusing and complex for the average user especially those people who update their site only once in a long while. When i compare that to the processwire sites built for clients, the result is that none of them ever contact me for content management, they can do it themselves, none of them break their sites, or destroy the formatting or look of the pages through gross violations of the wysiwyg... so my response to your post would be of course, it would be great if someone could write those modules, but I think they would need to be subsidized... maybe start a kickstarter campaign for whichever one you think is most helpful?

It's possible for it not to work on an Apache server too, if unzip isn't installed (which would be unusual) or if exec() is disabled (more common). There's also a chance unzip just isn't in the executable path on your server. You might see if you can locate where unzip is on the server.. it would usually be /usr/bin/unzip or /usr/local/bin/unzip. If you can login via ssh, you might be able to find it by typing "which unzip". Anyway, once you know where it is, you can take this line from /site/config.php: /** * uploadUnzipCommand: shell command to unzip archives, used by WireUpload class. * * If unzip doesn't work, you may need to precede 'unzip' with a path. * */ $config->uploadUnzipCommand = 'unzip -j -qq -n /src/ -x __MACOSX .* -d /dst/'; and prepend it with the server path: $config->uploadUnzipCommand = '/usr/bin/unzip -j -qq -n /src/ -x __MACOSX .* -d /dst/';

Introduction Dear community. As some of you may know I've been busy creating a MVC Module for Processwire. I've finished quite a bit of it and I am now ready for a tutorial on a quick website to get you started! For this tutorial I am using a clean install of Processwire 2.3 and my Module 0.2.4 Get the module at Github http://github.com/hawiak/mvcmodule . Main focus of the module is to split logic from design without losing the flexibility of Processwire we all fell in love with. Alright lets get started. Installation Once you have the module downloaded we are going to install it, we need the MvcModule folder in the /site/modules folder. And we need the AppController in the /site/templates folder (You can find the AppController in the /site/templates folder) Once you've put the folder in there we are going to install the module, check for new modules and you'll see MvcModule Click on it and hit install to install the module. Once you've installed the module you'll see some configure settings and you'll notice a new tab on your admin. But click submit, dont forget this or all the paths WONT WORK! Setting up your home controller Ok we are ready to set up our first controller. To easily set up your template to enable MVC we are going to the MVC tab in your navbar. You'll notice a button saying " Create controller" Click on "Create controller" and for this tutorial we are going to use the home template, select the home and click "Create". If everything is correct you will see this: Now we are done in the process side of it and we'll get into the coding. Get your favourite code editor open and lets create our controller. Open the /site/templates/home.php file in your editor. Remove the code thats in there completely. And save it. For the module to work with the template file we need to create a class called HomeController and extend AppController. like so: <?php class HomeController extends AppController{ } Creating Views and layouts If you go to your websites homepage you'll see something along the lines of: Thats because by default you will need an Index method, a home method for your controller, so lets create one! <?php class HomeController extends AppController{ public function index(){ } } Lets try it again! Oops... Well it seems like we're missing a view, so lets create the view, we first need to create a folder with called Home (the same as the controller name but start with capital) And in that folder we'll create a file called index.tmpl Now of you run it you'll see that you are not quite done yet you'll see something like this: I promise after we create the layout we are done. So lets create a folder called layouts and a file called layout.php in there. Displaying data Now we're done with the setup and we can start coding, lets say you want to get the content fromt he field body on your page displayed? Well thats easy put this in your index method. $this->set('body', $this->page->body); What this does is that it sets a variable in the view we can use called body so all we need to do to display this is go to our view. And add {{body}} to the view. Now go and refresh your page! oh wait... nothing shows up...? Oh yes we use Twig template engine we need to add this to our layout.php {% block view %} {% endblock %} (Yes yes I know its complicated for just a simple task but trust me you'll love it later!) Refresh your page and check it out! You'll see that the text is displaying but the markup isn't really working, we need to use the |raw extension in order to make this work, so change the index.tmpl content to this {{ body|raw }} Use |raw for all the HTML markup, always. Styles, scripts and snippets Now this is quite boring, I know but lets start doing some interesting stuff, lets implement Bootstrap! go and download bootstrap at getbootstrap.com Once you've downloaded create a folder in /site/templates called "assets" the dist copy the bootstrap.min.css out of /dist/css to /site/templates/assets/styles and /dist/js/bootstrap.min.js to /site/templates/assets/scripts/ Now we want to use this, MvcModule has some great options for this! Change your HomeController to this <?php class HomeController extends AppController{ public $scripts = array( '1' => 'bootstrap.min.js'); public $styles = array( '1' => 'bootstrap.min.css'); public function index(){ $this->set('body', $this->page->body); } } Now go over to your layout and change the contents of your layout to this: <head> {{ this.render_headers()|raw }} </head> {% block view %} {% endblock %} You'll now see your style (If not try going to the MvcModule configure settings and remove the first / from /site/templates/assets) Now we forgot to include JQuery, so lets download jquery at jquery.com We need to put that in the /site/templates/assets/scripts And we need to put it in the array, you can just do that as follow: public $scripts = array( '2' => 'bootstrap.min.js', '1' => 'jquery.min.js'); The number in this array indecates the order on which the scripts will be loaded. Now you should see something like this! Now lets create a navbar with all the pages using the bootstrap navbar component. To do this we will create a snippet create a folder called snippets in /site/templates and a file called navbar.php Lets first create a variable with all the pages in the index method $this->set('menu', $this->pages->find('/')); Lets now create our snippet, lets just create this first in our snippet navbar.php <nav class="navbar navbar-default" role="navigation"> <div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1"> <ul class="nav navbar-nav"> <li class="active"><a href="#">Link</a></li> </ul> </div> </nav> We need to tell the controller to use this snippet we do that by using an array. Change your controller to the following: <?php class HomeController extends AppController{ public $scripts = array( '2' => 'bootstrap.min.js', '1' => 'jquery.min.js'); public $styles = array( '1' => 'bootstrap.min.css'); public $snippets = array( 'navbar' => 'navbar.php'); public function index(){ $this->set('body', $this->page->body); $this->set('menu', $this->pages->find('/')); } } And change your layout to this: <head> {{ this.render_headers()|raw }} </head> {% block navbar %} {% endblock %} {% block view %} {% endblock %} You see that I created a block here and called in Navbar. The snippets content (that we assigned to navbar => file_name) will be put in this block! So lets now use our variables and the Twig template engine to the fullest! Change the navbar.php snippet to: <nav class="navbar navbar-default" role="navigation"> <div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1"> <ul class="nav navbar-nav"> {% for item in menu %} <li class=""><a href="{{ item.url }}">{{ item.title }}</a></li> {% endfor %} </ul> </div> </nav> You see we use a for loop here and use the PageArray menu here and generate the menu here. You can use the variables in the view as well. Setting a title Lets set a title, this is fairly easy, lets define a variable in our controller that will be the same for every view in this controller public $title = "Home controller"; Now go to your layout.php and do add this to the head: <title>{%block title %}{% endblock %} {{ this.controller.title }}</title> Now as you can see we created a block, what this allows us to do is create the same block in the view like this: {% block title %}Index{% endblock %} And you will see that your title is "Index Home controller". This is because the title block replaced the title block in the layout file. Views Inside views you still have access to processwire objects and even to the MvcModule as you've seen with render_headers(). The view template used is Twig, check out more here http://twig.sensiolabs.org/doc/templates.html This is a basic setup for a website with MvcModule. I will extend this tutorial and update it whenever needed!

Here all all the parameters https://developers.google.com/youtube/player_parameters#Parameters

This one was easy to get fixed. Once I saw the 500 error page was from Apache and not PW, I knew it had to be something in the htaccess file. I've not had to use the "RewriteBase /" before, but knew there were some situations where it was necessary–glad we found one. Good to hear you are doing a rollout of a new PW site. Be sure to post in the Showcase when you launch. Your module idea sounds like a great one–I'll be glad to help when the time comes, just let me know.

Oh my gosh, that is fantastic news. Thanks so much for figuring it out. This will be my first production rollout of a PW site, with another one in the works. Planning to write a module for the next one which I will happily share once it's ready. its a simple vote up/down widget. Thanks again Ryan.

Thanks for the FTP access. I found out what the issue was. Your server needed this part of the .htaccess file uncommented: # RewriteBase / Once I uncommented that (by removing the '#') it started working. Please let me know if you run into any more issues.

Looking a little closer, I think the simplest solution will be for you to extend InputfieldImage.module, creating a new module. The module won't need much code in it. It'll just have to override two methods (outlined below). I've included some sample code in this message and it's written in the browser and untested. So you may have to adjust it and play around a bit to make it work. Unless you want to also create a new Fieldtype, you'll need to work within the data available to FieldtypeImage, and that means just a single 'description' field. You'll use that 'description' field to hold an encoded version of multiple fields. I would suggest using JSON (with PHP's json_encode() and json_decode()) or XML, whatever you prefer. But here's an [untested] example of the two methods you would override in your new module that extends InputfieldImage.module: <?php protected $descriptionTemplate = array( 'your_field1' => '', 'your_field2' => '', 'your_field3' => '', // or whatever you want ); protected function renderItemDescriptionField(Pagefile $pagefile, $id, $n) { $description = json_decode($pagefile->description, true); if(!$description) $description = $this->descriptionTemplate; foreach($description as $key => $value) { $description[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } $out = <<< _OUT <label for='your_field1_$id'>Your Field #1</label> <textarea id='your_field1_$id' name='your_field1_$id'>$description[your_field1]</textarea> <label for='your_field2_$id'>Your Field #2</label> <input type='text' name='your_field2_$id' id='your_field2_$id' value='$description[your_field2]' /> <label for='your_field3_$id'>Your Field #3</label> <input type='text' name='your_field3_$id' id='your_field3_$id' value='$description[your_field3]' /> _OUT; return $out; } Then you'll also need to override ___processInputFile with something like this (example): <?php protected function ___processInputFile(WireInputData $input, Pagefile $pagefile, $n) { $changed = parent::___processInputFile($input, $pagefile, $n); $id = $this->name . '_' . $pagefile->hash; $description = $this->descriptionTemplate; $description['your_field1'] = $input['your_field1_' . $id]; $description['your_field2'] = $input['your_field2_' . $id]; $description['your_field3'] = $input['your_field3_' . $id]; $description = json_encode($description); if($description != $pagefile->description) { $pagefile->description = $description; $changed = true; } return $changed; } Once you've created and installed your new module, you'll select it as the "Input field" in field's settings, for your image(s) field. You'll also want to make sure that you set it to "no" for entity encoding the description field, in the field's settings. The main drawback of this approach is that you'll need to decode the fields from the image's description field every time you want to access them. So if you are iterating through some images in your template, you'd do it like this: <?php foreach($page->images as $image) { // decode the description field to an array $description = json_decode($image->description, true); // if there's nothing there, then skip it if(!$description) continue; foreach($description as $key => $value) { // you decide if this is necessary for your intended use (usually I would say Yes) $description[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } echo "<p>Field 1: $description[your_field1]</p>"; echo "<p>Field 2: $description[your_field2]</p>"; echo "<p>Field 3: $description[your_field3]</p>"; } We can get around this drawback by implementing a hook to do this for you once a page has finished loading. However, if it's that important, I would suggest looking at creating a new Fieldtype instead, as that would be ultimately more efficient, and probably easy to do. If you want to take that approach, let me know because you won't need to do any of this encoding/decoding, instead we'll just have the Fieldtype's DB schema keep the fields instead. So with that approach, the corresponding Inputfield would be a little different.