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.

Reading your comments, Pete, this article comes to mind.

Someday I hope to have these functions more scalable so that they don't require being in-memory to perform their jobs. It's a tricky balance, having a large group of pages that can be sorted by anything, and then finding the current page's place within it, without being in memory. But we will get there.

Good idea Nico. I'm happy to setup subdomains as needed.

Lovely idea, Nico. Of course, the W-community still has other German sites since they're heavily organized (yes, Germans also love to join clubs and organizations!). But as kind of an official ”yes, PW also works in German and there are German people who know what they're doing and use it“ site, this would be perfect, especially since it scales. There could be fr.processwire.org, fi.processwire.org etc. And if someone would want to create an “inofficial” PW community site, they could still use a different domain for that.

There are quite a few ways to accomplish this already: // numeric id should remain same no matter what.. and if it doesn't, no other attribute could be trusted either $pages->get(1919); // like you pointed out yourself, config values are one option; you can set them in config.php or run-time $pages->get($config->teamPagesID); // you could also use your own custom field for this and define it global if you want it to always exist $pages->get('page_id=team'); // if the name of that page is very unlikely to change (and very likely to be unique), you could even find the page based on that $pages->get('name=team'); This is just my opinion, but I'm not confident that this would be beneficial enough to justify a core addition. I'd rather suggest that you turn it into a module; under the hood $pages->get() uses $pages->findOne() which in turn uses $pages->find() and since $pages->find() is hookable you could easily inject your own desired functionality there. This would, of course, require addition of that custom page_id field I mentioned above and perhaps another module / method to fill it in (and make sure that it's really unique) but that doesn't sound too complicated either. Edit: clarification about the uniqueness of name field added, thanks @Soma for pointing this out.

I don't personally use Facebook more than once a month or so (never could get into it). But I've always been proud of the fact that Facebook was, and is built on PHP. Back before Facebook was the world's busiest site, the "people complaining about PHP" strategy was to say that PHP couldn't scale or be used for big/major things... kind of like all PHP developers were just children playing. Even then it was kind of a silly thing to say (Digg and Yahoo were using it at pretty large scale), but you just don't see that argument made anymore. PHP has been tested at a larger scale than any other web programming language ever has.

I think we should do it the WordPress way (sorry for mention the w-name). We don't need processwire.de - we just could use http://de.processwire.org/ (or .com) as a beginning (like: http://de.wordpress.org/). This page doesn't have to include all of the pages processwire.com does. It just would be a "hello german user. Yes, ProcessWire has a german admin interface. You can downlad the bundle here." And if you download processwire on this site it may should contain a german profile already...

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.

Several times now, the following has happened to me: I place a page in the tree as "/team", and I have some templates for menus etc. that go and grab that specific page, to create a list of it's children. Another team member (someone who's working on content) comes in and moves that page from "/team" to, say, "/about/team" - the template that tries to list the children of the "/team" page are now broken and listing nothing at all. ProcessWire gets around this issue by placing the actual page IDs in a configuration file somewhere - I really don't like that approach, since those IDs are just auto-incrementing numeric keys with no particular meaning. I'd like to request a simple, small new feature: an optional, unique page ID attribute. This would work much like the ID-attribute in the DOM - where only one element with the same ID is allowed in the same document, only one page would be allowed to have the same ID on a site. And where in the DOM, you can find a particular element by it's ID, regardless of where in the document it's located, in ProcessWire, you'd be able to find a page by it's ID, regardless of where in the sitemap it's located. Thoughts? Edit: a different term would need to be used, since the numeric ID is already known as the "page ID" - so maybe "page key".

There are two issues with the normal bootstrap menu: 1. It doesn't hover 2. The "parent" is not linkable (it is too busy doing the dropdown) So, here is the solution: http://cameronspear.com/blog/twitter-bootstrap-dropdown-on-hover-plugin/ Basically, this script replaces the data-toggle with data-hover Without the data-toggle, the parent becomes clickable and with the data-hover it now drops down on hover!! Magic!

Hey, I have no issue with designing something Dumbed Down - I do it all the time. Actually, I have already half done it on my overall demo site (http://pwdemo1.stonywebsites.co.uk/) That already has a category system in place for products and some other useful bits. It is wonderfully dumb!

I don't think this is an either/or argument so much as "what are you designing today?" (Apologies to Mr Gates) If we take your villa site as an example, each set of images has a very specific ownership paper trail - they belong to a specific villa and therefore, quite logically, a specific page. Even if you then have a generic promotional page that re-uses some of those images, it is reusing them based on them belonging to a specific entry. An e-commerce shop is mostly the same case. However, if you take my Dog-Blog (http://www.pebblesthepuppy.co.uk - you are permitted to say "ahhh" when you get there), although initially the images are uploaded in relation to a specific post, I have a great need to re-use images in other posts, without wanting the association to the original post. Thankfully, if you delete a post, you don't lose the images in WP and the new WP media uploader makes access to images across the board much easier. Moving onto another type of site, a news-magazine style site, then many of the images you use would be from a general library because they would be reused on a regular basis. On a game site that I ran, I could use any particular screen shot ten or twelve times - in tutorials, promotions, press-releases, general illustration and so on. Your average business site is a bit of a mix. Although most pages are pretty much "static" (as in they are not related to a series of pages like a blog), the entire site might have elements from all the above. A blog, a product/services catalogue, staff profiles, portfolios. Any and all of those may want to steal from each other - a news item might want to show a product picture, a product might want to show a picture of the staff member that designed the product, a press release might want to repeat the nice opening picture of the industrial estate.... And so on. Just to make it more awkward, if the product changed spec, you will probably want to "replace" the image and have that effect everything - without having to FTP into the back end. All of these are quite legitimate uses of media. What I suspect we need (and I think this is part of that fine-tuning of any software that is needed to make it attractive to a broader market) is a plugin that allows how the images are used to be customised. So, if in one content type you want people to upload an original, then that is all they will be able to do. If on another your don't want that, but only to use something from an existing library/page, then you should be able to set that. Oh, and I think the Thumbnails functionality should be part of this rather than as a separate plugin. After that, it is a case of sensible management by the admin. If they restrict an image to just a page (that may risk being deleted) then that is their problem. If they would rather have "image library" pages so this is not an issue, then it is up to them to set their site up that way. Either way, I think we should keep the system where an image is part of a page and not have a separate, disassociated image system. After all, if you create a library around pages you can create categories, years, tags, all kinds of nice things - if it aint broke, dont fix it. But that does not mean you cant expand on it so, like the rest of ProcessWire, it allows the admin to create and run the kind of site they want in the way they want.

I think that these are all great ideas. Though I've always been of the opinion that an image should belong to whatever page it is used on. That comes from my own experiences with the sites I build, and these sites typically don't need to share specifically named individual assets on multiple pages. Actually, they share quite a lot, but in a different way. When they share assets, it's with a relationship like "pull the first image from these pages" rather than "show this specific person's photo from that page". ProcessWire works especially well with the "pull the first image from these pages" type of relationship. But the problem with "pull this specific person's photo from that page" relationship is that if the owning page deletes the image or the page, then the other page referencing it has lost it. This isn't usually a problem for me because the instances where I need to share an image in that way are pretty rare. Basically, the only instance I can think of is in TinyMCE when you want to use the same exact photo for placement in more than one page. It's a nice thing to be able to do on occasion, but it's problematic to scale because the more you do it, the more fragile things become. Is this type of image relationship something that people are doing a lot in ProcessWire? If so, is that really what they should be doing? I'm not sure… but if it is, we'd probably want to solve the inherent fragility of that type of relationship before building lots of features to facilitate selection of images from other pages.

I think it's a good feature to have. There are times when I use an ID get a $pages->get(123) and it always demands a comment to describe what the ID is. Whereas I much prefer "self describing" identifiers, like paths. But of course, it's possible for a path to change (for some sites). I also agree it's not something that's needed in the core (or at least turned on by default), where we are trying to keep things simple and not introduce more new concepts for people to keep track of. But for regular users of PW, I can see this being a useful module to have. It would be particularly easy to implement too... basically just the FieldtypeText with a mysql 'unique' index on the data column. If we were implementing this, it might be nice to have 'id' and 'class' attributes supported by the fieldtype, for familiarity and consistency with what people are using in html/css. Then people could retrieve pages with selectors like "attr.id=form-builder" or "attr.class=beta". Though the 'class' one would be a little harder to implement than the id one, and it has a lot of crossover with selection by template, page reference, etc., so definitely not as useful as id.

I think why I like the idea is it's "officially unofficial" with no worry about domain names. But yes other local sites are welcome, my thinking was that Nico's idea would be a good way to show relatively quickly that we care about every country and supporting everyone.

You could have various sort options. It depends who is using and why. A news type site that would pull images from all over the place would definitely want it categorised somehow (though they would possibly be better off with the idea that I started this post with) A blogger, however, may well want to see their most recent images first, and to hell with the categories. To make it even more complicated, you may want to add search by either file name or description. I suppose the file name search field would be autocomplete. You could make this overly complicated, but as long as all the options are in a discrete list/hidden tab, something, then it would not be a major problem..... possibly.

I found Lemonstand is a bit easier to understand from a templating point of view, but with any of these systems it's bewildering as Joss says - especially compared to the E-commerce module Antti has made where you build your site as normal with the visitor in mind and then simply add one field to a page to make it a product. I know that's a shorter version of how it actually works, but it is MUCH easier and you're focusing on getting it right rather than wasting time on learning another system and wrapping your head around yet another templating system.

Another variation to the module could be a "show all images" link. Rather than navigate to a particular page, this would just retrieve all images linked to any page, with the current page's images the first on the list. (the rest could be by date or alphanumerical or something. This would need to be paginated/ajaxified (or a mix) for sites that have a huge number of images.

Yes, I have to admit that I haven't quite understood Ryan's code fully - does he come from a planet with a more advanced civilisation than you and me? Also, for the profile I would be tempted to do a responsive template since that is more or less the default on WP now (and other systems). Just a very simple header, body, sidebar system. Not very difficult to make it so the sidebar is either left or right with a switch in a "settings" page. Also, images: http://processwire.com/talk/topic/2573-images-module-source-page/

For those interested. Requires the shop module installed, code not well documented and from the my first steps in PW time. So be honest with me templates.zip

That would be nice! Just thinking aloud here: ShopWire? Goes nicely with: BlogWire BusinessWire IntraWire NewsWire (oops, pun) FanWire and then the frameworks: BootWire FoundationWire etc

@ryan I'm taking another look at this, and running into a problem. It appears there is no way to enumerate Field settings? If I may suggest a small change in the Field class: /** * Get a Field setting or dynamic data property * */ public function get($key) { if($key == 'table') return $this->getTable(); else if($key == 'prevTable') return $this->prevTable; else if($key == 'prevFieldtype') return $this->prevFieldtype; else if(isset($this->settings[$key])) return $this->settings[$key]; else if($key == 'settings') return $this->settings; # <- ! return parent::get($key); } Or perhaps more explicit, and without the risk of colliding with a setting called 'settings', a method like getSettings() would do the trick, too. What do you think?

Thanks Ryan, both of these options are great. Thanks!

ooh - Bootstrap is really good for that sort of thing. I may go and play. (Er, after I do all the other things on my growing list of "playing with ProcessWire" items.)

Another post for you to move when you move your ones: Both the Germans and the French have been pretty active over the years developing stuff - going back a bit, I remember coming across a few interesting items for which there was no English version at all. Java has been particularly popular at verious stages. So yes, there is very definitely a market. It requires more than simply a translation, however. We used to do huge amounts of multi-lingual corporate work at the studios, and I was constantly reminded by voiceovers when translating "in my country, we would not have made this video like this in the first place." So, some thought should be put to both the presentation style and the "sell" so that it is truly aimed at a country and is not just another language version that, to be honest, can be seen as insulting. In English speaking countries we are amazingly insensitive to this sort of thing!

Hello, How about taking away the admin rights of anyone who moves a page in that manner? Just kidding, sort of... But it would solve the problem. Thanks, Matthew

What complicates this in other CMS, is the fact that (at large) they don't have a unified data-model for the metadata (templates/fields) - lots of extensions create their own tables. This is very rarely necessary (and shouldn't be) in PW, where the data-model was designed from the ground up to support the entire metadata-model. I think this would be much simpler to implement in PW than in any other CMS.

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.

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.

I made some changes to get rid of the 404 problem and changes some minor stuff to then work with LanguageLocalizedURL module too. Dave could you please take that code https://github.com/somatonic/MarkupSitemapXML/blob/master/MarkupSitemapXML.module and test if it solves your issue before pete accepts the pull request? Thanks

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!

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.

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.

There are a few ways to do it, none of them straightforward 1) Modx had a lot of extra forums for discussion in each language om their main forums. Whilst i can see the point, I also think it leads to less sharing. 2) Local sites per country. I think this might be the answer, bit if each has its own forums then you run the risk of fragmentation again. 3) Making the main Pricesswire site multilanguage - this is actually a great idea, but there is a LOT of content to translate. If you can hook it up to localised domains though that would be amazing! I like option 3, but option 2 is more easily achieved. If there were to be localised sites with forums then that's fine, but personally I think it would be best if support requests were somehow handled on these forums and that's when it gets a bit messy. And a huge amen to Adam's rant But I understand the difficulties in choosing to say no to that person if there is several months' work on the line too.

Awesome stuff, Ryan! Interestingly that's something I've always found annoying in jQuery - never understood why traversing only one level would be desirable. I guess it does have it's use cases, but I'm quite happy that you decided to alter their behavior for ProcessWire..

Was wondering if this is the start of using PW tree as a html dom tree?

This is great!! Need to get some sleep now

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

amazing!

I'm not sure I understand what you're trying to achieve, but let's try and fix a couple of little mistakes from the code . echo 'max n vake' . $maxn; There's no variable named $maxn, there should probably read $maxi. $field = $fields->get('$dati_auto[$i]'); You're using single quotes so PHP treats what's between them as a literal string and does not interpolate the variable. As there's nothing more than a variable there, you can leave the single quotes off. To make PHP interpolate the variable, use double quotes as you've done at the very next line. The $language variable shown there is initialized to some meaningful value somewhere as well, right? And yet another variable interpolation thing here: echo "<li><strong>$label:</strong> $page->$dati_auto[$i]</li>"; Should be: echo "<li><strong>$label:</strong> {$page->$dati_auto[$i]}</li>"; (Ah, Pete was faster, so no hurry anymore for me. I'll go on a little more then.) And of course you'd need fields called auto_marca, auto_tipo and auto_prezzo to exists in the template of this page for this to work in the first place. But I think you've covered that already. One more thing, and this is just a preference, not a mistake at all. I like to iterate over that kind of array like this: foreach($dati_auto as $field_name) { $field = $fields->get($field_name); // ... echo "... {$page->$field_name} ...";} But as I said, there's nothing wrong with the way you've done it . (Edit: Ngh.. The editor messed the code totally - had to fix them afterwards. I wanted to see if the post looks alright before posting it and used full editor for that (more options or whatever the button says there). Then submitted the post and code was all over the place...)

This: $field = $fields->get('$dati_auto[$i]'); Should be without single quotes, like this: $field = $fields->get($dati_auto[$i]); Otherwise you are treating it as a string.

I think the CMSCritic award definitely gave us a big boost. I'd expect it to drop a little in the short term (as it always does after something like that), but the long term trend will continue steadily upwards.

HI Leeston I am sure you will have fun here. Just watch out for code-based group hugs! Yell if you want to know anything - the support is not so much one-to-one but Many to one! Joss

Welcome to our small and cosy place leeaston. I'm sure you will enjoy the next weeks

You can't use any operator except '=' when querying path or url from the database (like when using $pages->find). This is because the path doesn't actually exist in the database, so there's nothing to perform comparisons on. It is generated at runtime based on a page combining its name with the names of its parents. It worked with '=' because we pulled a few tricks to convert a path into a big left join statement, in an attempt to match it. And this actually works very well. But it doesn't translate quite as well to other operators. I should have had the engine throw an exception when you used an operator it didn't support for that. Instead it just switched it to an '='. So I've updated it so that it now throws an exception instead. I've also added a new module to the core, called PagePaths. When you grab the latest dev branch, do a 'check for new modules' and you should see it. Once you install that, it goes and sets up a table with all the page paths and a means of querying them. This enables you to use any operator when querying path or url, including all the partial text matching ones like %=, *=, ~=, ^=, $=. As a side effect, this module also brings potential performance improvements to other queries, as it eliminates the need for the left join trick I mentioned above. (Though in my initial tests, it doesn't seem to be a measurable improvement). I will probably have this module installed by default for new installations of 2.3. But won't have it auto-install to existing installations. That's because it has to generate an index of all pages in your site--a potentially resource consuming process. For instance, Antti's 100k page site probably won't work with this, as it's no small task to go and build an index for 100k pages after the fact. But if you aren't running a massive site already, this module is one you probably want on most sites, so I went ahead and included it in the core.