Leaderboard

I'm sure someone may already have posted this somewhere but I've only just come across it myself: http://www.opera.com/developer/tools/mobile/ Very handy as I only have an iPhone to test mobile sites on, plus this will test some tablet sizes too

Nice sites Glad to see you've used lots of fields too - makes me feel a bit easier about having done it myself too even though I already know it's fine to do so as long as the template code is sensible (I always worry my code isn't as streamlined as it should be at times, but I'm just happy when it works).

Hey chaps I've implemented the syntax-highlighting extension, not that it works automatically unfortunately. You can get an idea of how it works by editing the wiki page SiNNuT created and look at the tags wrapping the code. I probably went overboard adding the line numbers to some of the one-liner bits of code, but thought it best to leave it in for now until people have a look at it.

Here's an update on the blog profile. It now supports themes. The first theme I've made for it is based on Nikola's Futura admin theme: http://processwire.com/blogtest/?theme=futura I've also made a ProcessWire theme, but I think it still needs work (a little too girly right now): http://processwire.com/blogtest/?theme=processwire I'll probably put in one or two more themes for the distribution version. You can select the theme from the homepage. It's just a page reference field where it lets you select from pages using the "theme" template. The "theme" template is nothing more than a files field with all of the theme's assets in it. Typically this would be a CSS file(s), JS file(s), and images or font files (if used). I also had color pickers for defining the themes colors, but backtracked on that. I want themes to be self contained so that can create a new "theme" page, drag a ZIP file into the page, and be done with it. Once color pickers get involved, it becomes much less portable. Though I may still provide the option for overriding theme colors, but I have a feeling most people would prefer to just edit the included CSS file and then drag it back in. This version also is better optimized for mobile use. In addition to converting the top navigation to a <select> in mobile views, it now moves the search box and any other navigation to the bottom. That way people on mobile should still see the primary page headline and some of the copy without having to scroll.

We'll use this thread to discuss PW 2.3 features as they are being worked on. I've just added one of the first components. This is the "Page Path History" module. It's now in the PW core as a beta module (uninstalled by default). If you are interested in helping to test, just install the module from Admin > Modules > Page > Page Path History (after doing 'Check for new Modules'). The Page Path History module keeps track of the previous URLs for any pages that have been moved or renamed. It then sets up automatic redirects (301, permanent) to ensure the old URLs redirect to the new ones. This is best demonstrated by a few examples: Lets say you had the page /about/contact/ and you moved it to /contact/. With the Page Path History module installed, anyone accessing /about/contact/ will get redirected to /contact/. You had a page called /our-products/ and you renamed it to be /products/. Any accesses to /our-products/ will now get redirected to /products/. Those are simple examples, but this module can handle more complex situations too: Lets say you had the page /our-products/furniture/whoopie-cushion/ and you did like in the previous example and renamed /our-products/ to be /products/. The /our-products/furniture/whoopie-cushion/ URL will now redirect to /products/furniture/whoopie-cushion/ Later on you decide to rename /products/ to just /inventory/. All the /our-products/ and /products/ URLs will continue to work with redirects. You decide that whoopie-cushion really belongs in /services/ rather than /inventory/, so you drag it to /services/whoopie-cushion/. It's old URL in /inventory/furniture/whoopie-cushion/ redirects to it's new URL. TL;DR (am I doing this right) -- you can move or rename any pages and all the old URLs will redirect to the new, automated behind the scenes, without any thinking on your part.

I'm working on a site redesign and migration from MODx to PW for a foundation that organizes cycling races. The site itself is fairly simple and the content not that much. Talking about the site we figured it would be pretty neat if there was an easy way for us to manage the cyclingraces and its participants from the PW back-end. Some numbers: - For now it's two to four Races a year but this could grow - A typical Race is ridden in Teams. Dependend on the type of Race Teams consist of 3 or 6 Riders. There usually are between 25 and 40 Teams and between 120 and 180 Riders. - Participating Teams are numbered (1,2,3..) each rider gets a startnumber (1-6, 7-12, 13-18..) At any given time a Rider belongs to one team, but ofcourse can belong to many over the course of the years. Sometime before the race teammanagers start to email or even snailmail provisionary lineups. So the typical use is this (via PW backend): A foundation member adds a Race and all it's info. He can also add the participating teams with their corresponding line-ups. On the front-end all of this info is displayed and up to date. Later on it would be really nice if a team manager could login to a page on the frontend where they can manage their line-up themselves. Simplified, and maybe not correct at some points, this would look something like this in a more traditional db schema (see pic below) I thought about adding Teams as children of a Race and the Riders as repeaters but although this works quite nicely from a ui perspective this isn't the way to go. I not looking for a definitive answer but if someone could give some tips or thoughts on how they would approach this it would be great.

There's no simpler way. However I would write: $children = $pages->get($fields->select_architect->parent_id)->children;

Hello, I am in the early evaluation stage for PW. Coming from the Drupal 7 world and not being a software developer but coming from the design-side, these are my main goals for a new project: design ...is everything: The normal webpages need to be as flexible as possible to design whereas is ok in the community area to have a more standard layout. PW is PERFECT for me, Drupal has limits (even with modules), a main reason for my unhappiness (and yes, I know how to make my own templates) Organization:I am making a brochure style Webpage, PW is perfect here. (Drupal plays it's role when having millions of pages, which needs different organizations, like automatic menus, Taxonomy, views. Developing speed. Drupal needs 10000000+ clicks for installation. And for every new project the same mess again. PW can be adapted easily. Membership fun (forums, galleries, friending): Drupal is good, PW has nothing like that E-Commerce: Drupal has unfinished stuff, PW nothing. I don't blame PW for its limitation with membership management and E-Commerce. Those limitation is also a strenght and beauty because PW is not feature-overloaded and easy to handle. (A reason for me to have arrived here!) And there are pefect solutions for that existing already, like the IP_Board and Magento. I am now thinking of combining the specialists in it's fields like PW and IP_Board to have the best of both worlds that would by far more manageable than Drupal with its modules. What about using the fine grained Bulletin Board membership membership management and use this to access users to PW content (and editors and admins to the PW backend). Isn't it easier to write a "bridge" module than adding membership features to PW and trying to re-invent the wheel? The IP_Board has a strong API for authentification. (This site is also using the IP_Board.) Which means that users register and login to the board to have access to PW privileges also (through synchronizing the user base or bypassing the PW auth). That would be perfectly bypassing the PW limit of not having a fine grained frontend user (users level1,2,3) and backend users (editors, admins). (I a same way e-commerce functionality could be added with another auth-"bridge".) Is there something in PW (a module?) I have overlooked that does this already? Otherwise I would like to post this here as a starting point for ideas and discussion. Thanks for reading all this. I am very curious about your opinions. Cheers Carl from Berlin

Great post! PW is a lot different than Drupal in this regard, but no less flexible. Between page references, structure, the API, and markup under your control, I think you can take PW further than you can Drupal. Another aspect of PW that I wanted to mention that is easy to miss: PW supports unlimited granular permissions. You can simply add new permissions in the admin (Admin > Access > Permissions). Then edit any roles you want to have those permissions and check the appropriate boxes. From that point, you can use those permissions in the API however you want. For instance, if you'd created a permission called "sugar-in-coffee" then you could check if the current user has that permission by using the API: if($user->hasPermission("sugar-in-coffee")) { // do something } Something else you may find handy is if you want to provide additional access without a user having to login. Lets say you are performing some check with the IP.Board API to determine if a user of a certain level is logged in there, and you want them to have upgraded permissions in PW at the same time. Create a role that has the permissions you want. Then you can assign that role to guest when you detect they should have additional access: if($user_is_logged_in_ipboard) { // or however you perform this check $user->addRole('member'); // where 'member' is the role you added // now user has more access } or if you want to login a specific user in PW, but don't need to authenticate (because they already authenticated in IP.Board): if($user_is_logged_in_ipboard) { $u = $users->get($ipboard_user_name); if($u->id) $users->setCurrentUser($u); // now a user is logged in for this request, without having to authenticate }

You also have to iterate the pages inside the page field foreach($page->banners as $banner) { foreach($banner->pagefield as $p) { echo $p->title; } }

Ah!!! Ok, i did a print_r on $fields->pagefield->data, and got this: Array ( [derefAsPage] => 0 [parent_id] => 1044 [labelFieldName] => title [inputfield] => InputfieldPageListSelectMultiple [size] => 10 [required] => 1 ) So, you can get the parent id like this: $fields->pagefield->data['parent_id'] And the children like this: $parentId= $fields->pagefield->data['parent_id']; $children= $pages->get($parentId)->children; edit: this feels a bit hackish. I wonder if there's a simpler way to do this in PW...

@pete thanks for your expertise. just for Info: After a bad experience of the IPB support (I asked for something very specific - a pre-sale question about their shop and German Law - I just got a stupid reply how to run the demo instead of an answer to my question). I don't like them stealing my time. I was scared away and purchased xenforo. One good thought you have is why staying away from a single-logon. Also I need to check further how to override the PW logon, if needed. My idea is now to separate front end and backend users in a way that I use the PW login system for backend users: Backend users like admins will need to login to both system, which I think is ok. And a normal user needs to log in to xenforo to be able also to see some VIP content from PW also. If I want to hide PW content from normal users, I could try using the sessions, which xenforo creates.... This is the route I am trying to use now. (I still need to install and get accustomed to PW als well as xenforo, but at least I have my first ideas now...) (If there is no mod or extension planned, this thread maybe belongs to the "how to" area of this board instead?)

You can shorten it a bit when excluding the current page to be id!=$page When you don't specifically pull out a field from a $page object it simply returns the ID. Not a lot of people know that, but it can be handy.

Okay, so I've only just read this thread (I've been busy elsewhere ) so ryan is probably getting sick of the fact I've "liked" every other post in this thread in the last five minutes, but I do like it For mobile testing, you might like to try this ryan: Also, just my personal preference, but I've gone completely off Cufon in recent months and prefer to use the likes of FontSquirrel. I know it's down to personal preference from the designer's point of view, but it did occur to me that if you supported something like a standard site/templates/fonts folder then you could ship several fonts from fontsquirrel with the default theme (they're free) and even support dropping new fonts into that folder and have it tied in with a drop-down font selector in the admin area somehow. Just a thought, but I think something simple like that could be reasonably easy to implement for the benefit of non-web-savvy users. I love everything else about this and will be digging through the code at some point to see where I can use bits on some of my current sites, as well as using the whole thing for future sites. Keep up the awesome work!

Do you need any help with this? Or is it complete?

Thanks for the post Martijn. Glad to hear it serves its purposes. One reason it's not in there, is because language support was still in development and moreover it's not core, it's a third-party module and need to be installed (although it's in the distribution). There's couple things not in the cheatsheet that are not permanent modules i.e. like the comments, pager etc. I'm not sure if those distributed modules should be added somehow or make a separate sheet. What you guys think?

That's a good point--I hadn't actually tried images on the RSS feed before. Here's another way you could do it: $contents = $rss->renderFeed(); $contents = str_replace("<img src=\"/site/assets/files/", "<img src=\"http://clintonskakun.com/site/assets/files/", $contents); header($rss->header); echo $contents; This problem should resolve itself in 2.3, as I'm planning to abstract URLs to IDs in textarea fields. The IDs will be resolved to the full URL at render time.

Hello everyone, this is our latest creation built with Processwire. It's a site for a Photoshopplugin I build to save slices like a boss Let us know what you think! http://photoshopmonkeys.com Team Valentijn Kint (vknt) Thijs Bernolet (recyclerobot)

Next site is online: http://www.troltsch.de (Small Real estate company hier in Karlsruhe) No special modules, but some CSS3-fancyness (hovering images). Their old site didn't have any information, so the goal was to make the maximum out of nothing.

Most sites [that I make] rely on good photography to carry a lot of design weight, making the job easy. But in this case, you've had no such luxury... there's even a pic involving a toilet on the homepage. This is quality design carrying all the weight of making things look good, and doing so really successfully. Beautifully designed and executed--nice work! Also really like the detail of photos zooming on hover.

ProcessWire can be a great back-end for any kind of user data management needs that you have. But since we're shy about generating markup for your site(s), you won't find non-administrative user and account features like you would in something like Drupal. When it gets to those kinds of things, ProcessWire takes more of a framework (CMF) role, giving you tools to manage data for the things you build. If you are building a site centered around things like user registration and profile management, you may find something like Drupal worth putting up with in such cases. But if you are like me and several others here, you'd rather build these things yourself in ProcessWire, so that you can maximize control over the function and output of them. Should you want to do it, we are here to help you through it and answer any questions as you go.

On a housing detail page I am tempted to click the +. But it's not clickable, maybe this is confusing to others as well. Otherwise: looking good MadeMyDay!

More updates to the blog profile at http://processwire.com/blogtest/ Still not done with it, but lots of new tweaks. The biggest one is the addition of Tags, as well as an update to the InputfieldPageAutocomplete (committed today) that makes it work really well for tagging. Now when you are entering something in the autocomplete, if it doesn't match anything you can just hit enter and it adds it as a new page. This is assuming that you've configured the field to support that feature. Anyway, the point of this is that it's a very natural way of adding new pages with autocomplete.

That's why it's going to come with defaults already populated and identified. So to be more clear, there will be a title, CSS selector and color picker. The title says what it's for (i.e. "Vertical borders") and the CSS selector targets them. The only thing the typical user will change is the color picker value. If someone wants to take it further and add their own extra repeater items to customize further, that's up to them. But I don't see or expect the non-developers to do that. Also, I fully expect people to make a horrible explosion of colors. Put even a single color picker into the hands of a non-designer and the results won't be pretty. But I'm not responsible for other people's color choices. Honestly, if there aren't a few explosions, then we're not making things configurable enough.

Here's the next version of the Blog Profile. This one incorporates the simpler structure I mentioned earlier, exactly as outlined. Please let me know how it works for you. To install, download a fresh copy of ProcessWire and replace the /site-default/ directory it comes with, with the one in the attached zip: blog-site2.zip Thanks, Ryan

Diogo beat me to it. But I will reiterate one of his comments I think this is what make wordpress so attractive for many people who can't code. They can download a wordpress theme and if it supports customization then they can easily change out header images, fonts, text color.

That's a good idea! And it's already there. But you have to be logged in to see it. See the sidebar, it says "create new blog post". You always have great suggestions, but sometimes it takes me awhile to get it. After sleeping on it and thinking more on the intended audience here and want it to be as broad as possible. So while I want this to be something that people don't have to touch any code, I also don't want to introduce any unnecessary barriers for people that do. Given what you've suggested, I'm thinking I will tear into it and make it less nice on the code side, but simpler for someone to figure out without having to invest much time in it. Here's the strategy: $markup, $output and $blog will get moved into 1 API variable just called $blog. That API variable will be moved to a module and won't be something that people ever have to look at the code for. The functions in it are: findPosts($selector) getPost($selector) findComments($selector) findRecentComments($limit) setOutput('content|sidebar|whatever', $value) renderPosts($posts) renderComments($comments) renderCategories($categories) renderSubnav($items) renderArchives($year) renderAuthor($author) renderWidgets($widgets) render() // main Rather than having the Markup class, all those render functions map to PHP "views": renderPosts() uses view file: /site/templates/blog/posts.php renderComments() uses view file: /site/templates/blog/comments.php ...and so on: subnav.php archives.php author.php widgets.php main.php Those view files are basically like WordPress templates. Though with no classes, functions or logic. Just markup, loops and variables. The render functions figure out the logic and then just hand the views data that's ready to be output. Not quite as flexible as before (though still flexible), but there's nothing to figure out, so I like that. The template files in /site/templates/ will remain largely the same, other than that they'll be calling on $blog rather than $markup and $output like they are now. What I think this leaves us with is a minor compromise, though one that has a much lower development barrier to entry. People can get in there and adjust the markup output without having to know anything about the system. So I think it's a good compromise. Structurally I think it may be better too because it's much easier to see the scope of a theme: the entire /templates/ dir (and other dirs in it) is it. This setup is kind of similar to the approach some of us use in having common render functions as modules. Like having a PageArray::renderVillas() that is used by multiple template files. The main difference here is that the render() functions are taking care of any needed logic and then letting really simple "view" files handle generating the actual output. So now the "theme" has good separation and hopefully encourages people to create new themes. It's not an approach I'd use on one of my projects, but it should be a perfect approach for this blog and encouraging people to customize it.

Thanks for testing Apeisa and Sinnut. Right now the intended audience is us, as you might guess from the included blog entries. But once everything is worked out with it, the intended audience is folks that want to write blog entries and don't know how to do any development. That's the audience that we have no connection with at all right now, but is WordPress's biggest audience. I'm not too worried about this audience understanding the PHP side of it, because I want to make it technically unnecessary for them to have to do anything at that level. But in order to best support that audience, I also think there needs to be some abstraction on the code side. I did start out with a structure a lot more like the basic profile. But after working with it a bit, decided to build this in the best and most efficient way I knew how. We're already covering the basics in the default site profile, but don't have anything out there that shows how to build something for larger scale. While this isn't particularly large scale, I decided to approach the profile from a development perspective in the same way I'd approach a site I'm building for a client. Though I'll usually bundle some of this stuff into modules, distancing it from the site templates. I may still do that, but still debating the merits of it in this case. Another factor here is that I wanted to support really easy theme-ability, where you'd never have to make the same change in more than one place. If you want to make this thing run on Twitter Bootstrap rather than Zurb Foundation, all you need to do is replace a few classnames at the top of the file (in the constructor). If you want to make all images follow HTML(5) rather than XHTML syntax, then you only need to change it in one place, and so on for any tag. I didn't want to commit 100% to one CSS framework over another, so trying to keep some things abstracted here so I could swap in another framework without having to change the code. For the sidebar widgets, I'm thinking about taking a module approach for those rather than a template one. That way people could install a new widget (as a module) in one shot rather than having to add a template, add fields to it, and create a page for it.