Leaderboard

Introducing MetroWire, a little theme I've been working on and using in personal projects for which was once inspired by "metro" styling and to which now I can't think of a better name for. DOWNLOAD http://modules.processwire.com/modules/metro-wire/'>Modules Directory Listing SCREENS!! Login Page Tree Templates Page Customise the colors! (for those of you familiar with less. Change the "@adminAccent" colour variable in "templates-admin/styles/less/vars.less" and compile to customise the main colour to whatever you like!) Hopefully at some point I can integrate the compiling and even give users the ability to choose their colour... fun! Hope you guys enjoy this, thanks for taking a look if you do! I also did a Tweak to the AdminBar to match my theme more closely (hopefully Apeisa doesn't mind), and did some naming changes to solve a conflict I had on a project that used Bootstrap AdminBar-TWEAK.zip

Our next site created with Processwire is online: www.jobcenter-heidenheim.de You could describe it as a department of the agency for employment here in Germany. This site is often visited to find out about the business hours and how to contact your special counterpart. Another important factor for the client was the use of their "Leitbild"- and as you can see, they're used all over the page and the "WIR"(we) is written in the special font. Beside the front page, have a look to "Ansprechpartner" . Every person you can find here is a single page in PW. I've attached a screenshot from the backend.

Time to start my DeLorean and steal few modules from Soma again

Hi Sunny, There's nothing built-in but it's all achievable and there are already some examples on the forums. Which I'll try and track down for you. You can start by extending the built-in "user" template. If you go to templates and then filters->show_system_templates. Like that you can add images and other things to the built in "user". You could equally add new members as new pages as well as setting them as a new user, this may be a better way to go long term. You will need to create front-end forms to allow people to register/edit/login. It is reasonably straight-forward to add new pages from the front-end in PW. You can find more info here: Custom logins: http://processwire.c...7-custom-login/ Creating new pages with API: http://processwire.c...-pages-via-api/ Also there's loads of people on here, including me who'd be happy to go through it all with you step-by-step but definitely check out Ryan's Form-Builder module too EDIT: Removed code as Soma's right, it's probably best to go step-by-step and end up with a lot neater code! As Pete says, there'll be people here to help you at each step but once you break it down, it's all very achievable and ten times easier the second time around.

Hey, I just thought it might be helpful to have a guide for your module's presentation: The Title The title of a module is an important part of it. It should kind of make the main function of a module understandable after the first reading. So there are some guidelines for naming a module: (via http://processwire.com/api/modules/) Here is a more extended list of some "module prefixes" and a short description for each: (via http://processwire.c...-module-naming/) The Description A good description is another important part of your module's presentation. Here is a short list of sections you could (or maybe should) include in it: General: The main function of your module How to use: A description of how to use your module which maybe includes some details the user won't see directly. Installation: If there is something special about the installation of your module you should add this to your description. Screenshots/-casts: It's awesome if you would take a picture of your module (if it changes or adds something the user is able to see). Or maybe a screencast if you like to. (Great example: http://processwire.c...ncy-admin-mode/) Links At the end of your post you should add some links like where the user can download the plugin and if you've added your module to the module section you should post the link here too. Module Section If you've posted your module already to the modules section you can easily copy it's contents there and use them for your post here or - of course - the other way around. I hope this post was helpful to you. Greets, Nico

Fancy Admin Mode Just had a little funwith fancybox iframes, and created a little module that opens all admin links (topnav links, edit, view, new, copy actions) except "Pages" screen and "Site", "Search" in a FancyBox, so you'll never leave the page tree. It even works with inherit editing child pages. Download: https://github.com/s.../FancyAdminMode Little screencast to se it in action:

Thanks but I am very happy with sublime text 2.

I drove a DeLorean once - it was like trying to navigate an aerodynamic bucket. And yes, Soma does seem to work on an "I will read your mind first and then I will tell you what you are going to think" sort of principle. He should be writing on the wiki .... (hint)

If one had a big enough security hole in the site where someone could actually execute SQL queries, then that's something that probably needs to be fixed quickly. Seems like trying to hide the table names is a good way to let a security issue drag on and perpetuate. I'd also worry that having such a feature in place would make developers assume they weren't fully responsible for their own security and could half-ass some code because "the random table names will protect me." Then again, if I was running WordPress or Joomla, I'd probably want all the security through obscurity I could get. I doubt the problem is the CMSs themselves, but the plethora of insecure plugins and themes. I suspect the masking of table names is in response to an existing problem with those. Still, it seems like this approach does foster an ecosystem of insecurity. If that wasn't a security "feature" then the bad plugins would get cast aside a lot sooner and the whole ecosystem would probably be more secure in general.

I remember being really pleased when moving from EE to PW that I didn't have to recreate every field for each template

I think it's a good idea, especially for people (like me) who want to port some WordPress sites to ProcessWire. It might encourage WP people to try something new.

For the record, I have a friend who works at Ellis. They've just fixed the trailing slash issue on the CI documentation.

Ryan, I think it would be enough to add something like this below the cropping switch in ImageSizer if you want to implement this feature. // setCropping(array(.3, .4)) // = centered at x=30% y=40% ; if (is_array($this->cropping)) { $w1 = ($gdWidth - $targetWidth) * $this->cropping[0]; $h1 = ($gdHeight - $targetHeight) * $this->cropping[1]; }

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.

Since it appears that each post can have only one category, you could easily solve this by making your actual site tree represent the /posts/category-name/post-name/ structure. If the one-category-per-post status will remain for the future, then this would be the best approach. But if you want to stick with your current structure then here are a couple options: Option 1: For your /posts/ page template, turn on URL segments like Adam mentioned. But since you want the category to be included in the URL, that's going to be your first URL segment (not the post_name). it sounds like you want the post_name to be the second URL segment. So something like this should work: if($input->urlSegment1 && $input->urlSegment2) { // display the post $postName = $sanitizer->pageName($input->urlSegment2); $post = $page->child("name=$postName"); if(!$post->id) throw new Wire404Exception(); echo $post->render(); } else if($input->urlSegment1) { // display posts in category, or a 404 if you don't want it } else { // display regular content for your /posts/ page } If there is potential for post and category name collisions, you might want to precede the category part of your URLs with something like "cat-[category name]" for URLs like /posts/cat-widgets/post-name/. Option 2: If the goal is to avoid 404s, then I would take a different approach: accept the new URLs as they are in ProcessWire and perform redirects when one of the old URLs is hit. This would be more efficient than option 1, and you'd benefit from the newer shorter URLs. You'd do this in a similar manner to above, enabling URL segments for your posts template. But you'd take a different action: if($input->urlSegment1 && $input->urlSegment2) { // URL has /category-name/post-name/ $postName = $sanitizer->pageName($input->urlSegment2); $post = $page->child("name=$postName"); if(!$post->id) throw new Wire404Exception(); $session->redirect($post->url); } else if($input->urlSegment1) { // URL has /category-name/ $categoryName = $sanitizer->pageName($input->urlSegment1); $category = $pages->get("/categories/$categoryName/"); if(!$category->id) throw new Wire404Exception(); $session->redirect($category->url); } // if this point is reached, display regular content for your /posts/ page

@diogo: "I'm a graphic designer with very basic knowledge of PHP" You're far too modest!

Protip: Leave the ending php tag out and it wont happen again.

I get shiver seeing this code, no offence onjegolders, but code like this maybe better put on gist or any other code snippet site. But it's an nice example. However if you want to dive more into pressing the jus out of PW you might look at some examples building simple forms with API in the front end. I built some front-end tools like this and enjoy it. http://processwire.c...orms-using-api/ Also wanted to mention you'd better of searching with google on processwire.com "site:processwire.com keyword" Also here's some thread about user generated content I posted an example of front-end image upload. http://processwire.c...ges/#entry20835 And there's actually many ways to archive the thing, so might want to first play around and dive around a little.

Welcome Sunny It really is pretty easy to build these things in ProcessWire as onjegolders says so if you have a go at it based on the examples above and let us know if you get stuck there will almost certainly be someone here to help you out with advice and examples.

I'm not sure I got your question right, but that doesn't seem very unefficient to me. The first two lines could be replaced by this though: $find = $pages->find("has_parent=1134, template=subcategory"); So no need to get the ancestor first but go straight to find any page it's parent or grandparent of. Maybe this was what you were after?

Sorry to enter this conversation (as I am no pro), but wouldn't it be simplest just to set it to 22 digits instead of 21, which seems to work everywhere? (I may not fully understand the conversation, though

Hi, This is a complete server configuration block for NGiNX communicating with php-fpm. There are a few things that will require customisation: server_name root access_log and error_log fastcgi_pass - socket or TCP specification configuration blocks relating to 40x and 50x error handling Note the use of fastcgi_param HTTP_MOD_REWRITE On; which quiets an installer error about requiring mod_rewrite. You might also want to copy htaccess.txt to .htaccess in the ProcessWire top-level directory. server { listen 80 default_server; server_name localhost localhost.localdomain; index index.php index.html; root /var/www/html; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log notice; default_type application/x-php; ### SECURITY - Protect crucial files location ~ /\. { deny all; } location ~ /(COPYRIGHT|LICENSE|README|htaccess)\.txt { deny all; } location ~ ^/site(-[^/]+)?/assets/(.*\.php|backups|cache|config|install|logs|sessions) { deny all; } location ~ ^/site(-[^/]+)?/install { deny all; } location ~ ^/(site(-[^/]+)?|wire)/(config(-dev)?|index\.config)\.php { deny all; } location ~ ^/((site(-[^/]+)?|wire)/modules|wire/core)/.*\.(inc|module|php|tpl) { deny all; } location ~ ^/(site(-[^/]+)?|wire)/templates(-admin)?/.*\.(inc|html?|php|tpl) { deny all; } ### GLOBAL REWRITE location / { try_files $uri $uri/ /index.php?it=$uri&$args; } # pass the PHP scripts to FastCGI server on local socket # location ~ .+\.php((/|\?).*)?$ { fastcgi_pass unix:/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param HTTP_MOD_REWRITE On; include fastcgi_params; } # redirect server error pages to the static page /40x.html # error_page 404 /404.html; location = /40x.html { root /usr/share/nginx/html; } # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } } In the php-fpm configuration you need to specify unix socket or TCP connection parameters and possibly the chdir setting. These are distribution-dependent values and you will need to determine the correct values for your scenario. My configuration is as follows: ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port' - to listen on a TCP socket to a specific address on ; a specific port; ; 'port' - to listen on a TCP socket to all addresses on a ; specific port; ; '/path/to/unix/socket' - to listen on a unix socket. ; Note: This value is mandatory. ;listen = 127.0.0.1:9000 listen = /run/php-fpm/php-fpm.sock ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0666 listen.owner = nginx listen.group = nginx listen.mode = 0660 ; Chdir to this directory at the start. This value must be an absolute path. ; Default Value: current directory or / when chroot chdir = /var/www/html Please note that I researched these configurations and the preceeding security configuration from original documentation. I did not rely on howtos available on the Internet. Each has been carefully implemented and undergone significant testing before going into production. Regards, Neil Darlow

I was just about to say "that sounds good, go for it". But then I decided to give it one more test, just a quick one. Yeah right, like one of those ever existed in the middle of the night. So now, a couple of hours and a few installed PHP versions later, I'm about to lose my mind. I've tried all the PHP versions I was able to find pre-packaged (for that Ubuntu 10.04) and the only one I got working was the very latest 5.4.9. Both 5.3.6 and 5.3.10 (!) failed for me. Well, these results combined with the previous ones and I was about to say the problem was introduced somewhere between 5.3.10 and 5.3.14. But. A handy tool at http://3v4l.org/ comes in to "rescue" (allows to run a piece of PHP script in 80+ different PHP versions). I ran that script given in my previous post, just to get results like this: After comparing all the results with each other, the only conclusion I'm able to come to is that there actually is no problem with a plain PHP. The problem does exists, but only when there's Suhosin-Patch around. I'm just not able to find out the exact pattern. I was able to test with three different versions of PHP with Suhosin-Patch: 5.3.2 (failed), 5.3.15 (ok), 5.4.9 (ok). So this few hours didn't give that much new information after all . And besides PHP version there's actually another parameter now: Suhosin-Patch version. I did come up with a simple test though. If the next line run from the shell gives a result of "*0", it's run on a problematic combination of PHP and Suhosin: php -r 'echo crypt("test", "$2a$11$12345")."\n";' Then run these to get the version information for comparison: php --version php -r 'phpinfo();' | grep Suhosin Got to go and get some sleep now. I think this will haunt me all night though...

Ok the while is over. I just committed an update to 1.1.5 to support alternative markup for specified templates. https://github.com/s...default-options Added 3 new options: "xtemplate" => "folder|placeholder", // specify one or more templates "xitem_tpl" => "<span>{title}</span>", // default markup for page with this template "xitem_current_tpl" => "<span>{title}</span>" echo $nav->render(array( 'max_levels'=>2, 'selector'=>"limit=10", 'xtemplates' => 'placeholder|folder' ));

turn url segments on your category pages, and then something like this code (browser written, untested): <?php $post_name = $input->urlSegment(1); $post = $pages->get("/posts/{$post_name}"); if ($post->id) { // render post } else { throw new Wire404Exception(); }

I Lucas, I do this in my tutorial. http://wiki.processwire.com/index.php/Basic_Website_Tutorial It shows you how to create the fields, template and page, and then how to integrate that into your site. On a site I am working on at the moment, I have even included things like banner background colours, blocks, meta data, and tons of SEO useful stuff .

Yes, create a New Template called "optionspage" create New Fields named like the Option you want. Assign Those Fields to the New Template. Create a New Page and assign the created Template to it. There you go.

Another example.. build from ProcessHello and really fresh: https://gist.github.com/4289451

When you enable url segments on the home template it will also render, ehm...non-existing pages from the docs: So we only allow urlSegment with the value "contact" and throw 404 when we try to go to any other non-existent page e.g. www.mysite.com/hahanothinghere/

Can we also get one that comes with my next client project all set up? Thanks.