owzim

First off, I love PW and I said that many times before. It's by far the best CMS option out there, that I know of anyway. That's why I want to push it in that agency =) The issues raised here are very interesting nonetheless and I hope I don't come off as a naysayer when provoking further thoughts on some of the posts in this thread. While this being totally true, this is no guarantee that it's actually forked and maintained like before, if for some reason Ryan decides to quit. Since all the other systems listed are Open Source too this is not actually an issue. Good point, but people barely know security issues before they pop up right? So there might be security issues in PW we don't know of yet. When the community gets bigger there are more people who are more likely to find bugs, which might be another point for that community size matters. Great points. Interestingly, that those CMSes (WP at least) are hacked quite often did not came off as a convincing point. It was only an interview after all and not primarily a discussion about CMSes =) Someone has to pay for that. It might be less expensive to use PW in the long run, but you need to convince clients that they need to use another system and the training costs money, OR even worse the clients think they invested so much time and money in training their employees that they feel the need to make it worth while. And I don't think that clients are necessarily unhappy with let's say the WordPress admin interface, so they don't know that it's not so great under the hood. Great points, thanks. So true, good point. That's a good idea, I might actually try and convert their company site in half a day =D ... okay, one day.

I recently had an interview at a Web Design agency and I presented ProcessWire as a viable alternative to their most used CMSes like Typo3, Drupal, WordPress and Modx. They said that some of their devs have used PW before and liked it very much. I promoted PWs ease of use, flexibility, less dev hassle, solid security and so on, but they said that it all comes down to what clients already know, and how established the CMS is: "Community size matters. How do I know that PW will be there in three years? It may be the hot thing now but might be gone tomorrow." I think that from a business perspective those are valid points. I might be working with them in the near future and I definitely want to push PW more. What might be striking arguments against the mentioned points? Greetings Christian

What I can see as problematic here is, that modules grow an flourish just because very early versions are shared from the beginning making them open to suggestions and bug reports, which is a very important aspect of open source. If you limit the audience just to the people who pay, modules may not become as awesome and user friendly, at least not in early stages. That's just a thought. In general I like the idea very much.

Overall very sleek. The Latest News Section looks a bit scattered though, is this intentional? Shot: http://d.pr/i/WTy1 Also, the "read more" buttons are positioned inconsistently. Some have space around them, some don't.

They still could be named FieldtypeThumbnails, InputfieldThumbnails and ProcessThumbnails ... if Thumbnails is the way to go.

Am I the only one who finds the naming in this module rather confusing? In ModulesManager/on PW Site: - it is called Thumbnails Module detail page: - after installing it, the title in Admin > Module says Images with cropping - the class is called ProcessCropImage - the description says Crop thumbnails in Modules list its components are listed as: - FieldType: Images with cropping - Inputfield: Images with cropping - Process: Image cropping tool So we have about 5 different names: Image cropping tool CropImage (FieldtypeCropImage/InputfieldCropImage/ProcessCropImage) Thumbnails Images with cropping Crop thumbnails Is there a reason behind this? I feel this should be more organized.

You might want to check the "Sort settings for children" in the Family-tab of the template which is assigned to the page that contains all the areas, the parent. Or you can manually set the sorting in your selector via code: http://processwire.com/api/selectors/ Under the section Sorting the results of a selector

OK if you really need the same iterators from the accordion, you might also iterate on your area page as well to get the same index as in the accordion: $i = 0; $iteratorInList = -1; // set the default -1 if not in list // "/areas/" being the url to the parent of your areas foreach ($pages->get("/areas/")->children as $area) { // find out if current page in loop is the same as current $page if($area == $page) { $iteratorInList = $i; break; } $i++; } echo $iteratorInList; Seems a bit cumbersome, but I don't know of a method like $somePage->index($list) ... similar to jQuery.

That might be a bug/unwanted behavior in core, don't know. But honestly: 999 pages in a pagination? Sounds highly user-unfriendly. I hope your'e just filing a bug here and don't really use so many pages in a pagination =)

Why not save the number or color on each page as data? echo $page->color; Or you can use $page->id for that too: .my-class-1234 { background-color: green; } .my-class-1235 { background-color: red; } in your accordion: <li class="my-class-<?php echo $child->id; ?>"><?php echo $child->title; ?></li> on your page: <body class="my-class-<?php echo $page->id; ?>"> </body> That makes you dependent on the id though, which is generated form the system, so maybe you can define your own identifier $page->myColorID; or something, and work with that.

Either manually iterate an iterator variable within the foreach loop: $i = 0; foreach ($somaeArray as $item) { // your code echo "my-class-$i"; $i++; } Or you can deal with a for loop, and you can access your items in the page array like so: $selectedItems = $pages->find("your-selector"); $len = count($selectedItems); // or $selectedItems->count(); for ($i=0; $i < $len; $i++) { // so something with $selectedItems->eq($i); echo "my-class-$i"; } Edit: adrian kind of beat me to it =)

As kongondo stated, PageFields are the way to go, they are very flexible. It looks like your subcategories are unique in each main category so you could build them in a page tree Categories - Disciplines - - Advertising - - Architecture - - ... - Locations - - Budapest - - Glasgow - - ... - Themes - - Animals - - Automotive - - ... If you want you subcats to be able to have multiple parents/maincats you might want to add the subcats via ASM select (an option for PageFields) in the maincat template rather than as child pages. As for how to be able to select the categories when using them here are some examples: http://processwire.com/talk/topic/4348-selectable-pages-mutual-relation/ and http://processwire.com/talk/topic/4344-autocomplete-input-for-page-select/

You can set up customs selectors or even PHP code for page fields. I don't think there's a selector for this case so you might want to add PHP code that collects all grand children and returns it in a new PageArray: $rtnPages = new PageArray(); foreach ($pages->get("/items/")->children as $categories) { $rtnPages->append($categories->children); } return $rtnPages; Or if your items in the categories have a certain template you can select by template: template=template-name

Wow this is a full fledged browser rendering to pdf, gonna try that out soon.

Nice site, although I don't think the bold font for the menu and headlines are too good of a fit. But I know it's not an easy task to do design work for "oriental" themes. The Shangri La hotel chain has some nice CI. Oh I remember having to deal with those prayer times back in 2009 when doing something for the Medina Mosque. It's very weird, and I learned that even Moslems can get confused by it =) and there are dozens of slightly different algorithms out there. I heard about one instance where printed calendars had to be redone because of some calculation differences.

I built the site with PW just for my convenience. The client does not want to make any major changes frequently, so the content is more or less static. The output and upload is scripted on my end, so it's just a matter of a single command line command =)

Hi, this my first site I built with ProcessWire. It's not hyper complex and it has its flaws I know =) http://www.kuban.de I should mention that PW is not running on the server but rather a static HTML output I generated from my local install. I am still managing any changes through PW and then generate the output again. I used Sitesucker for that (it's a Mac tool similar to httrack). This method is discussed here. Modules used: FieldtypeCropImage MarkupCustomPageList ModulesManager ProcessBatcher ProcessPageDelete

It's weird how stuff Ryan puts out there always seems to be pretty much rock solid from the beginning. Awesome stuff. Thanks Ryan, Antti and Avoine! Edit: how are the variable widths controlled? There have to be many different situations for those fields on one row. When d they get a new dedicated row if there too many popping up in one row (like the checkbox example with "Pool" and "Children welcome")?

It does not matter how large the initial filesize is because if the image is cropped, or edited in any other way, all the pixels go (of course uncompressed) into ram and 3000x2000 are a LOT of pixels. I had the same problem with the 100% progress bar, and the php_value memory_limit setting solved it. Edit: I still would consider training the clients to resize their images before uploading. I think if they work with content they cannot assume that any system eats any type or amount of data. You have to preprocess everything in some way, may it be text or images.

Has anyone fiddled around with one of Ryan's suggestions yet?

I am having trouble getting the different versions downloaded. On github there is a commit called "Bump version number to 2.3.3" so if i checkout that commit that's ok, but what about all the other minor version steps? I can't find them. I'd love to get 2.3.1 and 2.3.2 as well.

Unfortunately this did not work for me, the custom admin page throws the following exception (by PageRender): Invalid output file location or specified file does not exist. I also checked in in ProcessAdminCustomPages2.module via: file_exists($this->config->paths->templates . $this->page->render_file . ".php") It is there. Tried it with 2.3.3.3

I really like that I can visually compose templates and fields with all the widths and so on so the subtractive approach is the way to go for me at the moment, thanks diogo for the quick but useful code. netcarver and soma, I will definitely dig deeper into that approach as well since it's so nicely automated, thanks.

I am using a PW installation as a template for every future PW installation. So within that I create all kinds of fields and templates for many different use cases which might not be used later in a copy installation so I delete all unused. What would be a good way to delete them fast instead of clicking every single template and field and delete it in the delete tab?

Although I am not a fan of the colour scheme and I think the colours of the photos are a bit off (too saturated, too contrasty, skin tones look weird), the content is laid out in a very clean and very readable manner. Easy to navigate ... and it's responsive, yay! =) Good work. Edit: I think the wood texture looks like a cheap replica wood veneer you find on 70ies cafeteria tables =) I don't know why exactly though, maybe it's the wood colour or the straight cut off lines it's pressed into.