Leaderboard

ProcessWire now implements ALL of the jQuery traversal functions in the Page API. Existing ProcessWire versions already implemented most of them, but once we started updating parent() and parents() to support selectors, I figured we might as well be fully complete and consistent with the jQuery equivalents. Now we are. The following functions were added or updated: $page->parents([$selector]) -- Now you can specify a $selector and it will return parents that match your selector. $page->parent([$selector]) -- Now you can specify a $selector and it will return the closest matching parent. $page->closest($selector) -- Same as parent($selector) except that it considers the current page in addition to the parents. $page->parentsUntil($selector, [$filter]) -- Return all parents from current till the one matched by $selector, optionally filtering them afterwards by $filter (a selector string). Note that $selector may be a selector string, a Page, a path, or an ID. $page->next([$selector]) -- Now you can specify a $selector and it will return the closest matching next sibling. $page->nextAll([$selector]) -- Returns all siblings that come after this $page, optionally filtered by a $selector. $page->nextUntil($selector, [$filter]) -- Return all sibling pages after this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID. $page->prev([$selector]) -- Now you can specify a $selector and it will return the closest matching previous sibling. $page->prevAll([$selector]) -- Returns all siblings that come before this $page, optionally filtered by a $selector. $page->prevUntil($selector, [$filter]) -- Return all sibling pages before this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID. Arguments in [brackets] are optional. These functions duplicate the arguments and behavior of their jQuery counterparts. The exceptions are that parent(), next(), and prev() have a slightly different behavior: they will traverse to find the closest match (which I thought was a lot more useful in our context). In jQuery, they don't traverse beyond the direct parent/next/previous item in the DOM. As before, all the next and prev functions should be used cautiously when $page has a large amount of siblings. All these functions require loading all the pages they interact with, as comparisons are done in memory and not via SQL queries. All of them accept an optional last $siblings argument, which is a PageArray of siblings you want it to analyze (which is presumably a more limited set), and this is what you'd use if you need to scale to thousands of pages when using these functions. But if you aren't dealing with huge amounts of pages, then you don't need to consider this.

1.) I don't think there currently is any nation-specific PW site, maybe short of finland (and that's only because Antti (@apeisa) is a beast) 2.) Whether anybody is working on it, I'll leave that up to german boys --- + RANT: What the hell is that argument that "our clients heard about these before". Well, they are the agency, they should make the freakin' technical decisions! I will never understand this 'client asks for it, we bend forwards and backwards to do it' mentality… Especially when it comes to technical decisions.

$my_page->numChildren does also count hidden (maybe unpublished) pages, while $my_page->children does not include them by default. If you use count($my_page->children("include=hidden")), it's the same number Edit: Too late again

Just for the records: 1. I registered: processwire-cms.de 2. I got in contact with the guys behind processwire.de and asked them for their plans.

We have noticed that if discussion goes to that level (why pw is better than wp/drupal/modx/any other system) then we are already little late on the game (there are more everything with drupal, wp, sharepoint, anything really, you always lose when comparing on paper..). Angle should be "why we can understand your need best". After client and you both believe that it is great match, then technology will never be an issue. "I have never heard about that system, but if that is what is needed to best fulfill our needs, then go for it." Although I do enjoy personally chatting and comparing the strengths, it actually adds very little value for customer. Of course if project is clearly something specific from some of the areas where PW is not strong (intranet applications, e-commerce, community sites), then by all means be honest and open with that.

Oh, of course, the children are all unpublished. "Why couldn't you easily tell that they were unpublished by the strikethrough" you ask? Because I'm using a slightly modified version of @Soma's nice PageListImageLabel module that has images shown as dimmed when they are published but fully opaque when they are unpublished (for moderation of the images). Thanks @Wanze and everyone for the help. Oh, and of course special thanks to @Adamkiss for the "hug". Those guys are only slightly balder than I am

I've never been to Europe. Can I bring the family and crash with you guys? We'll make the "meat up" part of a larger vacation.

Greetings, Implementing a slideshow in ProcessWire is very intuitive. As long as you know the "standard" ways of including JQuery and CSS in your pages, and calling JQuery on a particular page, you are all set. There is just a bit of ProcessWire-specific syntax. I use BxSlider, Galleria, and FlexSlider in my sites. I find them very flexible and easy to use when implementing dynamic images. Below I outline the steps I use to get Galleria working. Step 1: Include the Associated JQuery and CSS Files The first step involves downloading the necessary files from the Galleria Web site and including them in your ProcessWire installation. In my example, I am using the basic Galleria CSS and JQuery, and I am using a Galleria theme, so I have three files altogether. 1. Place the CSS files here: /site/templates/styles 2. Place the Javascript files here: /site/templates/scripts 3. In your template, include the following in the <head> area (I include this in my head.inc file): <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/galleria.classic.css" /> <script type="text/javascript" src="<?php echo $config->urls->templates?>scripts/galleria-1.2.8.min.js"></script> <script type="text/javascript" src="<?php echo $config->urls->templates?>scripts/galleria.classic.min.js"></script> Step 2: Loop Through the Images in Your Template These instructions assume you have created an image upload field called "images." It also sets a size on the fly for the "large" gallery images and the "thumbnails." I run a test to assure that there are images. And I have linked the images to the content. You might do some of this differently. Just adapt your code. Add the following code (or something similar) where you want the slider to appear in your template: <?php /* Test to see if there are gallery images uploaded (number of images is > 0). If so, present a gallery. If not, leave this area blank. */ $image_num = count($page->images); if($image_num > 0) { ?> <div id="galleria_holder"> <div id="galleria"> <?php foreach ($page->images as $gall_image) { $large = $gall_image->size(640, 480); $thumb = $gall_image->size(200, 150); ?> <a href="<?php echo $large->url; ?>"><img src="<?php echo $thumb->url; ?>"</a> <?php } ?> </div> </div> Step 3: Fire the Galleria Script Directly below the code shown above, call the Galleria script and its options. Check the Galleria Web site for full instructions, but it is straight JQuery work at this point. The code below calls a Galleria theme, sets a "fadeslide" transition, and turns off the "counter" option (then closes the conditional statement opened in the snippet from Step 2): <script> Galleria.loadTheme('<?php echo $config->urls->templates?>scripts/galleria.classic.min.js'); Galleria.run('#galleria', { transition: 'fadeslide', showCounter: false }); </script> <?php } ?> There are some particular details for Galleria. But the three steps shown above are the same for just about any JQuery script I can think of. Thanks, Matthew

EDIT: This project has been put on ice - I don't work with ProcessWire in my day job anymore, so this project is looking for a new maintainer. Knowing that, you can decide whether it's worthwhile reading through 7 pages of posts EDIT: The source code has been dumped on GitHub - feel free to fork and have at it. There's one thing about ProcessWire that pains me, and I've brought this up before - it's the same problem I have with e.g. Drupal... Because the meta-data (Configuration, Fields and Templates) is stored inside the database, once you have a live site and a development site, moving changes from the development site to the live site is, well, not really possible. Repeating all the changes by hand on the live site is simply not an option I'm willing to consider. Telling the client to back off the site and give me a day or two to make the changes, and then moving the whole database after making and testing the changes on a development site, is really a pretty poor solution, too. I had heard some talk about a module in development, which would make it possible to import/export Fields and Templates? It sounds like that would mostly solve the problem. Ideally though, I'd really like a solution that records changes to Fields and Templates, and allows me to continuously integrate changes from one server to another. So I started hacking out a module, but I'm not sure if it's going to work at all, if it's even a good idea, or if it's worth the effort. I'm looking for feedback on the idea as such, more than the code I wrote, which isn't real pretty right now. Anyway, have a look: https://gist.github.com/b7269bb7bd814ecf54fb If you install this, create a "data" folder under the module's folder - migration files will be written there. Basic overview of the idea and code: The module hooks into Fields::load() and takes a "snapshot" of the current Field properties and settings on start-up. It also hooks into ProcessField::fieldSave() and when a field is saved, it compares it's properties and settings to the snapshot it took at startup - if changes were made, it writes the previous name and updated properties into a file. The same thing is not implemented for Templates yet, but would be. The migration-files are named like "YYYY-mm-dd-HH-mm-ss.json", so that they can be sorted and applied in order. Each file contains a JSON representation of a method-call - currently only updateField() which would repeat a previous set of changes and apply them to another installation of a site. (not implemented) So basically, the module would record changes to Fields and Templates, and would be able to repeat them. How those files get from one system to another is less of a concern - would be cool if servers could exchange migrations semi-automatically, using some kind of private key system, but initially, simply copying the files by hand would suffice. I'm more concerned about the whole idea of capturing changes and repeating them this way. Any thoughts? Is this approach wrong for some reason? Would this even work?

Hey guys of central europe and near Switzerland. Any interest in doing a conference/meeting in Switzerland, this year or any time in the near future? I was thinking about a location in Zurich. Event if it's just to meat and eat, drink and have some fun.

Couple of recent sites I've created: http://www.theartofdining.co.uk/ - Pop up restaurant http://samhofman.co.uk/ - still life photographer

http://aneventapart....daptive-content Long - just over an hour, but fascinating video presentation from An Event Apart. But much of it could be a description of why to use ProcessWire (although it's not about PW). Much of the presentation will resonate with PW users.

It depends on what admin user you want to grab, as you'd need to refer to them by name. But assuming the name is 'admin', you'd do this to send them an email: $admin = $users->get('admin'); mail($admin->email, 'Hi Admin!', 'This is a test'); You might also notice this in /site/config.php: /** * adminEmail: address to send optional fatal error notifications to. * */ $config->adminEmail = ''; If that is defined, you could use that for your purpose as well.

I'm with Nico on this one - I like the idea of local sites very much, but if we can approach it with subdomains we can standardise a look and feel much more easily as well as work more closely together on what we feel could be covered on the local sites. If we could pull together on features and content for this we could maybe even use the multisite module and translate some common content into various languages. We might also benefit from it looking more "official" this way - it would acknowledge that the dev team (ryan, but I'm thinking like a customer) cares about engaging with and supporting customers across the world. Just out of curiosity, how many German/French/Finnish etc CMS systems are there out there? I mean ones developed with English not as the native language? Also how many developed by English speaking countries where the devs have actually bothered translating parts of their official site or offering country-based portals? I'm extremely interested to see if this might be a relatively simple way to draw in a much larger user base by standing out from the crowd

I've seen processwire.ch is also already in hands of a swiss fotographer. Hmm Why?! I was also thinking to get processwire-cms.ch. Even if doing a redirect to you guys

What about: processwire-das-beste-opensource-cms-cmf-der-welt.de

Translation of the German text on said site for the non-German guys: Jeez. I mean, if you're gonna block a domain, just have the decency to put some content on there. What's wrong with a cat GIF? As for the German community site's name, I think “pw[something]” is too generic. This could lead to legal issues (yes, Germans love their legal issues). I don't see what's wrong with processwire-cms.de, but of course, it's your call.

hm, this relationship starts with the wrong foot...

Yay! That works - serves a 200 status and Google can now read it. Thank you.

You answered your question: $i=1; foreach($latest_portfolio as $item) { $thumb = $item->portfolio_image->size(270); echo '<div class="span3' . ($i % 3 === 0 ? ' last' : '') . '"><article class="item"><a href="' . $item->url . '"> <img src="' . $thumb->url . '" alt="' . $thumb->description . '" class="teaser"/></a></article></div>'; $i++; } edit: too slow... Wanze takes the prize

Yep, and that is little shame. I symlink with wire folder and translations work fine. Would love to symlink site modules too. But as long ad they come from github updating is not an issue. And of course always possible to create some server side scripts to keep modules up to date..

Thanks, but I already cleared the cache with no effect (only files related to ModuleManager in there either way). Then I changed /site/modules/FiledtypeCropImage/ from the symbolic link that it was to be the actual files and now it's working! And the scales felt from my eyes, too... For sure, a translation file called site--modules--fieldtypecropimage--fieldtypecropimage-module.json doesn't apply to a file physically stored somewhere else then /site/modules/FieldtypeCropimage/FieldtypeCropImage.module. Just didn't think about this thoroughly enough before. So, for everyone running into this problem, too: Don't try to translate a module that you just symbolically linked into the filesystem. It won't work! Thanks for all your help here!

Translation for core admin, we already have repos. To pack all 3rd party module translation into them too I think is not a good idea at all. Better keep them with the module they belong to.

Just intalled and added an translation for the inputfield module. Works fine without problems, the translation are shown as it should.

Well, I didn't meant "apps" in general (we have build multiple apps already: full featured event management, trusted election voting tool, simple discussions, e-commerce.. you name it ). What I meant is when the actual need is to have "app type of an intranet" (instead of "website type of intranet", mainly used to share information), with instant messaging, file sharing, projects & tasks, private settings, profiles etc... all doable with PW, but there is nothing out of the box and lot's of work ahead. If I had to build that kind of application, I would definitely do it with PW. But there are many great alternatives already solving the exactly same problem.

Antti please, PW is a terrific tool for Apps

I don't think about a german forum or something like this, because I really like the community here. I thought about a german website as a addition to processwire.com not a replacement. A site to present some facts and benefits about PW in german. Further a PW-network-section, in this section pw-professionals would be introduced with short interviews (why the are using PW, what was the their first pw-site etc). So you could tell a client: go to www.processwire.com this is the official website with great community, the api etc., but PW is relevant in Gemrany too, go to domainnanme.de and there you see some facts about the CMS and the community in ypur own language. Maybe a blog could with guest-articles could be nice, just to show, that PW has a active community.

I think it may have been discussed before, but some videos here on ProcessWire.com showing an easy conversion of a WordPress site might not be a bad idea. Since the basic elements of most Wordpress sites are the same it could just be as simple as a comparison of what you do in Wordpress as opposed to how you do it in ProcessWire. Off the top of my head, you would start with how to make a post in either system which is 99% of what they do on it, before showing them the technical possibilities by adding a custom field in 5 seconds in the admin, then adding it to the template and blowing their minds with the possibilities. What we really need is a series of videos like this comparing things I think as they don't know how easy it is unless you show them.

Delivering language packs through module download is one way to go. Other one is having github repo per language. Also when this will be decided, there should be possibility to mention translations (with credits for translators) in modules.processwire.com listing.

[removed spam image]

Sorry . Damn mobile reading i missed it. Ok but the answer to your problem is: You have to write children() as it's a method not a property. Some other API can be used both with and without so but in this case i think it doesnt. Maybe still something for Ryan to change in case it's this. Damn again, I shouldn't call from memory when having sleep loss. I think Wanze has a good point below

Awesome! Thanks Ryan for the description. Some work for the cheatsheet...

@tibs: Thanks a lot for pointing this out, I didn't see this before, but I think it's an elegant solution for an all-too-common problem and should work for a lot of use cases. It would definitely be worth the effort to develop this as a module of its own or integrate this into Thumbnail as an option, where you can choose which flavour of cropping you want for every field. Would be a lot of work though. @ryan: I'm completely aware that this is not coming into existence magically just because I want it. Just writing down my ideas here, and I hope to find the time for looking closer into this on my own. But I also wouldn't be offended if anyone likes the idea and gives it a try.

Hi everyone, this is my first post here, so let me start with a big thank you. These past few days I duplicated almost all the functionality of a site I've been working on for much longer in Drupal, and it's much leaner and nicer, and without 27 extra modules. I was looking for something similar that Marc is talking about. Drupal has a module called "imagefield focus", where you can specify a region that you want in all of your cropped versions, regardless of their size or aspect ratio. It also lets to specify another (bigger) region that you don't want to go outside of; it's good if the original image has a border that you want to get rid of. The awesome thing about this approach is that the API would remain the same, except $image->size(...) would now work with those boundaries. This, of course, requires the boundaries stored in the database, and also a timestamp to know when to update the already rendered images.

Thanks Joss and OrganisedFellow. I've been away on other projects for a while. Glad you found the study useful. BTW - this site will be up for a bit of a refresh around May this year. I'll post an update then and a bit more in retrospect.

No Problem for Pw. Instead of a module, you have to generate the markup for the slider in your template. For example, check the documentation section of your first link: http://dimsemenov.com/plugins/royal-slider/documentation/ Do all the steps as described (add js, css etc..). Then simply grab the Images / Text from the fields. <!-- STEP 2, see the docs from the link above --> <div class="royalSlider rsDefault"> <?php foreach ($page->images as $image) { echo "<div>"; echo "<img class='rsImg' src='{$image->url}' alt='{$image->description}'>"; echo "<p>{$image->description}</p>"; echo "</div>"; } ?> </div> The code above would create a slide for each Image with the description text below. As far as you only want to slide Image + Text, there's no need for a repeater. You can use a field of type Image which allows you already to store multiple images with descriptions

This is possible Create a field of type "FieldsetOpen". In your template, just sorround your fields you want to wrap in this fieldset with the fieldset created. //Example for fieldset with name "fieldset_advanced": fieldset_advanced date summary fieldset_advanced_END Btw there exists also a "FieldsetTabOpen", which displays the wrapped fields in a new Tab

I would happily pay a lot of money for a comercial module that solves this problem. I am sure a lot of other freelancers and agencies would too, once the benefits of the process are clearly explained. Maybe you could also combine it with a good backup solution - "painless deployment and backups - save time and headaches when developing and iterating rapidly changing client projects"

That clears it. Went for 'dev' option, planning mass-converting my existing sites to PW

This theme is officially now my favourite I did change the colour scheme though - attached is the modified version (basically all pinks are blues, and the blue-greys are greys - it works quite well). The colours I've changed were done in DreamWeaver so all the styles that were neat one-liners have been thrown onto separate lines, so consider the attached a version that works fine but needs tidying up by me at some point. EDIT: Sorry, forgot to mention that this is prior to the changes on the 4th of Jan. I will update it soon, so consider this a version to look at if you're curious Elegance Admin Theme - Blue v0.5.zip

Edit well if there not too many projects you could try and evaluate the dates and store them on runtime to sort by that value afterwards when you loop them out. $pa = $pages->find("template=project"); if(count($pa)){ foreach($pa as $p){ if(!$p->numChildren) continue; // no assignments // store a temporary value to the project page $p->tmp_date = $p->children("sort=-due_date")->first()->due_date; } // output the projects foreach($pa->sort("-tmp_date") as $p){ echo "<li>$p->title</li>"; if(!$p->numChildren) continue; foreach($p->children("sort=-due_date") as $a){ // output assignments } } } This will work well if you don't have thousands of pages. The module approach would be the more efficient and scaleable.

The one thing to bear in mind with using the version from the admin is something ryan mentioned ages ago in another thread - it might be better to use your own download in case the admin version ever changes. For example the current version is FancyBox v1 and there is a v2 version of Fancybox - whilst I can't imagine ryan changing it yet as the current version works fine, it could break your front-end work if it were to change. It's one of those things that probably won't happen or if it does it might not affect you, but still worth bearing in mind.

Just updated the demo a bit - details on the original post.

I'm glad you found ProcessWire! It definitely is a good alternative and, as you dig deeper, you'll find yourself liking the system more and more. This is a plus without a doubt, at least in my mind.

The two one would have to consider are: Page Fieldtype -- keeps track of an ID from the pages table, if you choose to use the "parent" as the criteria for selectable pages. It doesn't add anything to the pages table, it just keeps track of an ID already in there. Repeater Fieldtype -- This one actually generates pages as you mentioned (and it's the only I'm aware of that does). Any continuous integration tool would probably want to exclude these two, or at least the Repeater one, until version 2+. I think it fits the commercial option well. My plan is to add JSON import/export to templates and fields very soon (very much like what's in FormBuilder). But this is just a quicker way of doing it manually (copy/paste vs. doing the work), it doesn't have the scope of a fully automated deployment tool.

I recently tried and gave up - many field-types actually store things in the "pages" table, so if somebody created a new page of content on the site while you were working on a local copy, you'll have overlapping page IDs. In the end, I had to tell people to back off the site while I was working locally and wait for me to signal the green flag - then replicate all the changes by hand. Ideally, I would like a module that provides automated one-click deployment and version control for all metadata, which, fortunately, thanks to good clean data architecture in PW, can be done by just handling Templates and Fields. I wonder, would anybody be interested in this module as a commercial option?

News_Year.title=$currentyear I'm on a mobile but I think I got that right - if I understood you right in the first place . Hope this helps!

Another way to display all fields is to use the "MarkupPageArray plugin module, which is installed by default and adds a render() function to all fields that return a PageArray (as many functions in ProcessWire do)." # echo $page->render();

Umm $config->urls->root ?

I've been using http://ifttt.com for this.