ryan

Thanks for letting me know. I'm thinking it has to do with moving pages rather than template changes. The reason is that template changes force the entire thing to rebuild (which is what running that code snippet does). Whereas moving pages attempts to just rebuild the affected page(s). I am going to experiment further and attempt to duplicate. Was the selector that was failing the same one you posted before or different? Thanks, Ryan

You are right, I still need to add this to the documentation. I will make that the next item added, this week. Here is some code you can add to your template (temporarily) to make it show all the URLs available for access from $config->urls: <?php foreach($config->urls as $key => $value) { echo $key . ": " . $config->urls->$key . "<br />"; }

Well stated. This actually sounds a lot better than what I was thinking (a retro, indecision-oriented site without future in mind). I'm complimenting your buzzword ability. Do you mean moving some of the tutorials we've posted in the forums to be in a permanent section of the site? I think this is a good idea. Some of this stuff gets lost in the forums, but really deserves a prominent place in the documentation. I'm not sure I understand the distinction you mentioned above, but think I might understand what you are getting at. Correct me if I'm wrong--something like: documentation for developing sites in PW that's separate from documentation on extending PW (like building modules)? Right on, I agree. Thanks for your feedback. We are now up to 1552 posts.

Antti, thank you for all the kind words. Excellent ideas. In addition to a news/blog section, I'm thinking I should put together something that pulls the most recent posts from the forum and provides links to them on the homepage (and places throughout the site). I agree on the timeline. The association idea is interesting, and seems like a good idea... it's something I'd not thought of before, but it looks like this is type of organization used by Drupal (http://association.drupal.org/about). Looking at some other projects, I've not been able to figure out exactly what type of organization they are, but I may not be looking in the right places. This association idea seems like a good one for any project, and I think we should go in this direction. Thanks, I think this would be a great collaboration. I think after 2.1/2.2 (as you mentioned), PW will look very good in feature-to-feature comparisons of other large cms projects (for those that are looking for that), and this will definitely be a good time to really push forward on the marketing, site design and features. All great ideas that we should pursue in the site upgrades. Commercial module development is something that I already do for my clients (when they have specific needs), and I think it's something that is good to support with other developers and people needing development. This is related, but also off on a tangent and something I've been thinking about for the future. Our target markets are web designers and developers. This market is a group of people that are employed by their ability to create things that ultimately gets managed and presented by the CMS. Their reputation is on the line with every deliverable they provide to their clients, and so they must place a lot of trust in the products they work with. I think this is why many designers are so high on ExpressionEngine, because there is support guaranteed by a transaction and a company. But EE the software and EE the business model are not my cup of tea. I have used it and think a lot of designers use it only because it's familiar and they don't know any better. I only bring up EE because there now appears to be a lot of crossover with their audience and ours. I would like to find some way for designers/developers to have that confidence level in ProcessWire and know that they (and their clients) are supported. I think the best way to provide this is probably by offering paid support contracts for those that want it, but I don't really know. I think we're doing a good job of providing support in this forum and that's all that most people will need. Even though we're just a small community right now, I know we'll be able to continue to do that as it gets larger too. I also want people developing major commercial, big-brand and high-profile sites to also choose ProcessWire (this is the best marketing), and I'm thinking the insurance of a support contract will really be a point in PW's favor. Does anyone have any other ideas of how we might best support this target market and offer them a level of comfort and confidence that they can't find with other open source projects? One of the reasons ProcessWire exists (out of many reasons) is because I've fixed countless hacked sites implemented by other developers running on other people's software (hello WordPress, Drupal, OpenX). I don't have as much comfort as I'd like to support another open source product for my clients. And I didn't want to my reputation with my clients to have that liability placed upon it. Despite my like of the support options behind EE and it's plugins, EE is proprietary, problematic and not something I enjoy developing a site in... so that was out after a couple tries. I have a ton of confidence in ProcessWire. Beyond this forum, how can we best support it? I think any commercial support options might require a team of us in different time zones in order to provide quick online response around the clock. Just ideas, but something to think about as the project grows. Installation profiles and themes are definitely key. I had a friend that needed to put together a quick site and didn't really have a budget for it. We just installed the default PW site, replaced the logo, and in 10 minutes he had something he could work with and put in his own content, images and pages. Not what I'd recommend for most, but it seemed like a good fit in that instance. It also speaks to the value of ready-to-go install profiles... they can be huge time savers in the right instances. For install profiles, blog, as you mentioned, is probably the first one we should start with. I am very thankful to you and Avoine for your support of ProcessWire! Thanks, Ryan

These are some great ideas, thank you for your thoughts here. I definitely agree about more articles, tutorials and full site examples. My plan is to continue writing as much as I can as time allows, and kind of split that time between coding PW and writing stuff about it (whether in the forum, articles, emails, etc.). As you mentioned, we also need is to get more people writing about it. I was really thrilled to see the article that @almonk wrote last week. I know that @jimyost has also been working on some tutorials, and they were looking really good last time I checked. I need to check in with him again and see how it's coming along with those and if he needs any help. I figured we would launch an articles/tutorials section to the site so that I can post and/or link to these articles and tutorials as they are created. Regarding the processwire.com site design and copy, I think what you are saying makes sense. What you see with the site is basically the result of needing to do something quickly, so it's not designed, worded and refined in the same manner that I would do for one of my clients. (All the time is put into the software rather than the site). In addition, I'm my own worst client–I don't like to talk up anything I do... whatever ability I have to market and communicate for my clients doesn't translate as well to my own stuff. So I end up with workable but much more restrained-and-quick solutions than I would produce for others (as evidenced by my own site and this one). But ProcessWire is no longer just my project; it's now our project, and anyone's project; so I'm hoping I'll be able to use less restraint in marketing as we move forward. Most of the copy on the site was written before the software was released, and I didn't really know if anyone would be interested in it at that time. But after only a few months of being out there, I think the response and interest has been fantastic ... we're on to something here and should bring it to the next level. By the way, the copy points that you wrote up as examples were great! Want to write some copy? It's always funny to me that half the people that ask to excuse their wording because they are "not a native English speaker" are able to write better English than most native English speakers. I was particularly impressed by the symphonycms site you mentioned. They appear to have done a nice job with the design, content and flow of that site. I have some thoughts on how to bring PW to the next level, and that involves more collaboration. I struggle a bit with time as I try to balance my work time between client work and ProcessWire work. There's so much that I want to do, but I can't always do it as quickly as I'd like because of having a full time job running my business (as is the case for many of us). Though I hope one day to make this my primary job, one way or another. I'm committed to the project for the long term either way. I think we're at the stage where the project could really benefit and move to the next level by getting more people directly involved. Antti–you've done a great job of getting involved in the project, as have a few others. Thank you for your contributions! We need more people like you and many others on this forum. I welcome and am enthusiastic about more designers, developers, marketers, writers and others making ProcessWire their project too. Perhaps it would help if I formalized it in a "team" page on the site, so that it would be more official (?). Below is a list of areas where I think we could use help from others. Marketing and Communications ProcessWire.com site design, concept, strategy ProcessWire.com site content, marketing copy, documentation, etc. Design of marketing graphics, like "powered by ProcessWire" image(s) people can optionally put on their site Marketing and communications with or on other sites and social networks On-site or off-site tutorials, articles, examples, etc. Design, maintenance, distribution of regular ProcessWire e-mail newsletters ProcessWire.com site development Site features like robust "sites running PW" directory Site features like robust "modules & plugins" directory Maintaining directory of bug reports/known issues, feature requests, roadmap items. Project Management Help with general project management Help building and managing a team around the project Core Development PW core development, PW module development (whether core or 3rd party) Help with identifying and fixing bugs in PW and submitting updates, pull requests, etc. Quality-assurance in PW code: finding better, faster or more efficient ways to code things, and submitting updates/pull requests. Site Profiles and 3rd party modules Designing and building new downloadable site profiles Designing and building a mobile-friendly site profile example Continue creating new 3rd party modules (as many have already done) Language support PW admin translations and updates (when we reach that point) Testing and expertise with i18n and l10n Forums and Support Forum administration and keeping things spam free, organized and making sure everyone is welcome. People should always feel comfortable asking dumb questions in the PW forums, and I'd like PW to have the friendliest community of any CMS. Helping with support questions in the forum (especially when it grows a lot larger). Maintaining FAQs on the processwire.com site or forums That's just what I can think of right now. What other things should be added to this list? I also want to acknowledge several of you have already helped with many of these items too, so want to thank you for that.

Great site, I really like the minimal design. It looks like you've also done a nice job of getting a blog-type presentation in PW. Also like the way you used multiple bg images with your topnav a.on to get the apparent slanted/italic background color in the top navigation (a nice detail)

The latest commit of PW 2.1 now has the publish/unpublish as outlined by Apeisa. Take a look and let me know what you guys think. The main difference from how it was before is the following: 1. It now tells you in more obvious terms when a page isn't published (with a big headline at the top). 2. When editing a page that isn't published (only), there is a separate "Save + Keep Unpublished" button. 3. You can now unpublish a page. To do it, check the 'unpublished' status box on the settings tab. 4. Unpublished pages appear with a line-through in the PageList labels. 5. Unpublished pages are now viewable, but only if you have edit access to them. Previously, unpublished pages weren't viewable under any circumstance. I'm thinking we should add new 'page-publish' and 'page-unpublish' permissions that can be definable with roles (?) This version of PW 2.1 also includes several updates to the Setup > Templates section. You can now define roles that can add child pages for a given template, rather than having to maintain separate roles for page-edit and page-add access. Note that this also removes the need for a 'page-add' permission. This commit of the development version has had very little testing so please let me know when you come across bugs. Thanks, Ryan

The site looks great, nice work! It looks like your templates are effectively pulling in content from lots of pages and it's all nicely presented. I bet this was a fun site to develop! You've posted several sites and I've been working on the same client site the entire time. You must be very fast at development (or I'm very slow!). So I want to compliment you on the speed with which you are able to develop these. I am very happy to see people posting all these great sites in here.

Thanks for taking the time to think this through. I agree with everything you've stated here, and also like the execution in the screenshots (and the link style for 'keep unpublished'). After seeing Benbyf's message today, I am thinking we might do one more thing to highlight that it's unpublished... perhaps strikethrough text for the page title in the editor, as well as in the page list, just so there's no way to miss that it's unpublished.

That $config->ajax is determined exactly like the snippet you pasted, so your isAjax() function and $config->ajax are the same thing. While there isn't yet a function to convert a page to an array or JSON, I agree that it's something we should add. In the short term, here's one way you can convert a page's data to JSON: <?php function pageToJSON(Page $page) { $data = array( 'id' => $page->id, 'name' => $page->name, 'status' => $page->status, ); foreach($page->fields as $field) { $name = $field->name; $value = $page->getUnformatted($name); $data[$name] = $field->type->sleepValue($page, $field, $value); } return json_encode($data); } (written in the browser, so not yet tested, but I think it should work) That $field->type->sleepValue function converts whatever the value is to a native PHP type, suitable for storage in a database or JSON (or some other type). For simple text-based types, the value probably won't be changed by sleepValue. But for more complex types like files, images, page references, etc., it converts them to an array representation.

The code you posted in the second snippet is from the skyscrapers site, so if you copied that directly you would need change the variable names and such to match your own. If you are already doing that, can you post the actual code snippet you are using?

I agree, and I think once 2.1 is in stable release it'll be a good time to get PW up on sites like opensourcecms and others. I've intentionally avoided that kind of thing until I could get the software further along. We've also built up a pretty good email list of people subscribing to updates on the site, but I've not actually sent anything to the list yet (I'm a little short on time right now). But I figure also once 2.1 is ready we'll start doing regular distributions to this opt-in list as well. What are other ways you think would be good to do 'marketing'? (not sure if that's the right term in this case).

Adam, Antti: I thought I'd set it up so that both of you have some additional permissions on the forums (like ability to move and delete stuff), but let me know if you don't. I'm not much of an expert on this software, and may have set it up incorrectly (a couple months ago).

This topic has been moved to General Support. [iurl]http://processwire.com/talk/index.php?topic=267.0[/iurl]

Adam: I think you already have permission to move topics? Let me know if you don't, I can check this again. For now I am moving this to the general support. Benbyf, Apeisa posted some great ideas for this that I'll be implementing, hopefully very soon. The purpose of this behavior is just to prevent you from having pages show up in your site that are only half way through being created. If I recall correctly, PW only does this if the page has additional fields to populate beyond those you see on the "add page" screen. If you've created tons of pages don't go back and save each one. Instead, I'll paste in a snippet of code that you can put into any template temporarily and it'll publish them all for you. Just let me know if you want that.

Adam, here's how you might accomplish it: 1. Create a new role for users in this group, i.e. "client". Give the role page-edit (or ProcessPageEdit) permission along with any others necessary for your needs. 2. Create the client users, and give them that "client" role. 3. Assign that role to the template for pages (2.1) or pages (2.0) that they can edit. In this case, I think that means ALL of your client pages. For now, all "client" users can edit the same pages, but we want to restrict it further so that they can only edit pages that have the same "name" field as their username.... Or you could use some other criteria if you preferred. In PW 2.1, you might even add a page-reference field to the "users" template's fields so that you could select what page(s) each user could edit. But the point is that we'll need to restrict access further than the role, and you'll want to do this with a module. I'll post just the parts that I think you are looking for: <?php public function init() { if($this->user->hasRole("client")) $this->addHookAfter("Page::editable", $this, 'editable'); } public function editable(HookEvent $event) { // if it was already determined they don't have access, then abort if(!$event->return) return; $page = $event->object; // set your criteria to determine if they can edit this page. // shown below: if user name isn't the same as page name, make it not editable if($this->user->name != $page->name) $event->return = false; } This editable() function is used through ProcessWire, so they won't see edit() links for anything other than what you've allowed via the above function. If you don't want them to be able to view other pages (or see them in the admin), you can also hook into the viewable() function in the same manner.

Wow, I can't believe we got up to that many posts so quickly. Then I just looked at my post count and see I account for more than a 3rd of them... :-\

You can detect whether the current page was loaded from ajax by checking the value of $config->ajax from your template file: <?php if($config->ajax) { // page was requested from ajax } Following that, you will likely want to render the page differently to accommodate whatever you are doing from the javascript side. For instance, you might want do one of these: 1. Deliver alternate or reduced markup when loaded from ajax 2. Deliver a JSON or XML string for parsing from javascript Below are examples of each of these scenarios. 1. Deliver alternate or reduced markup when loaded from ajax You might find checking for ajax helpful when you want portions of pages to load in your site without re-rendering the entire page for each request. As a simple example, we'll use the default ProcessWire site and make it repopulate it's #bodycopy area when you click a page in the top navigation. (To use this example, you'll need the default ProcessWire site templates, though you can easily adapt the example to another situation.) To accomplish this, we'll update our main page template to only include the header and footer markup if the page is NOT being loaded from ajax: /site/templates/page.php <?php if(!$config->ajax) include("./head.inc"); echo $page->body; if(!$config->ajax) include("./foot.inc"); Next we'll update the top navigation to do ajax loads of the pages when the client has javascript (and leave as-is when they don't). Paste this javascript snippet before the closing </head> tag in the header markup file: /site/templates/head.inc: <script type="text/javascript"> $(document).ready(function() { $("#topnav a").click(function() { $("#topnav a.on").removeClass('on'); // unhighlight selected nav item... $(this).addClass('on'); // ...and highlight new nav item $("#bodycopy").html("<p>Loading...</p>"); $.get($(this).attr('href'), function(data) { $("#bodycopy").html(data); }); return false; }); }); </script> Now when you click on any page in the top navigation, it pops into the bodycopy area without a page load visible from your browser. And all pages remain accessible from their URL as well. Note that this is just a test scenario, and I probably wouldn't use this approach for the entire bodycopy area on a production site (it would make bookmarking difficult). But this approach can be very useful in the right places. 2. Deliver a JSON or XML string for parsing from javascript Lets say that you want pages in your site to return a JSON string with the page's id, title, and number of children when it is requested from ajax. When not requested from ajax, they will return their content as normal. To handle the ajax requests, you'd want to add something like this at the top of your template file before any other output. <?php if($config->ajax) { // this is an ajax request, return basic page information in a JSON string $json = array( 'id' => $page->id, 'title' => $page->title, 'numChildren' => $page->numChildren ); echo json_encode($json); return; } // not ajax, continue with regular page output And here is some markup and inline javascript you might use to test the ajax call on some other page (or the same one if you prefer). You would paste this snippet right in your site's markup where you want that info to appear. <ul id='info'></ul> <script type='text/javascript'> var url = '/'; // this is homepage, so replace '/' with page URL you want to load JSON from $(document).ready(function() { $.getJSON(url, function(data) { $.each(data, function(key, value) { $("#info").append("<li>" + key + ": " + value + "</li>"); }); }); }); </script> The above snippet would output something like this: • id: 1 • title: Home • numChildren: 5 To take this example further, you could build an ajax-driven sitemap or any number of web services. Conclusion Hope this helps you to see how simple it is to use ProcessWire to deliver output for ajax. These are just contrived examples, but hopefully examples that might lead to more ideas. In addition, much of what you see in these examples is also applicable to building web services in ProcessWire.

Nice work -- Thanks for posting this. I enjoyed hearing about how your client is using it on the back end too. The way you are handling the photo galleries is very effective, and I like how you are overlaying the price on top of the photo (nice effect, looks like it's actually rendered in the photo). And likewise with the "sold" version (transparent PNG?) -- gotta love that Karmann Ghia. Are you maintaining separate fields in ProcessWire for year, mileage and features? Or is that a textarea?

The main reason for the "unpublished" status is to accommodate that state that a page has after it's been created, but before any real content has been added to it. It's a temporary status. You wouldn't want it showing up in lists, or to be accessible at it's URL, until you'd populated it with content. But I agree the current implementation could use improvement in the areas you've described. The "hidden" status is unrelated... that's just a way to designate a page not to show up in find() and children() calls. It's a way to take a page out of the general flow of the site, but still have it accessible at it's URL. So you can still $pages->get() a hidden page, but you can't $pages->find() it (unless you override the setting in your selector). The hidden status isn't intended to be used as a workflow status. Instead, it's just meant to be something to hide specific purpose pages from showing up in navigation and searches... I like what you've suggested here, it sounds like a great solution. I will proceed with the changes as you've described. I think this will be possible to implement fairly easily.

In PW 2.1, the latest commit supports specifying max width and/or height dimensions for any field using InputfieldImage (which is what's used by FieldtypeImage). You'll see these in the settings for your image(s) field. Thanks, Ryan

One idea is that we could add an optional max width/height specification to the FieldtypeImage field, so that it would downsize any particularly large images automatically at upload time. In that manner, you could specify the max size for your needs in TinyMCE. Another possibility is that we could make this setting part of the InputfieldTinyMCE, where it checks the max size at the time you click an image to paste it in... if the image is larger than the max, it resizes it before completing the paste. I'm not sure that either solution is necessarily a quick n' easy approach, but it does seem that something like this is necessary. I guess the question is whether it should be part of the FieldtypeImage, which would extend it's use outside of just TinyMCE; or whether it should be specific to TinyMCE.

This is possible. The siblings method will accept a selector just like others will: <?php echo "<ul class='menuposht'>"; foreach($page->siblings("sort=-created, limit=3") as $sibling) { $class = $page === $sibling ? " class='active'" : ''; echo "<li><a$class href='{$sibling->url}'>{$sibling->title}</a></li>"; } echo "</ul>";

After testing here, I was only able to get a blank screen if I put PW into an infinite loop. I unintentionally did this when I attempted to render a page within a page where they were both using the same template, and each tried to render the other indefinitely. So I would say that the first thing to look at is to make sure that you don't have a possible infinite loop where the two pages may be trying to render one another. While looking into this, I also discovered an issue where Page::render() sending the template the wrong $page object... giving it the one requested on the URL rather than the one you provided it. The result was attempting to render a $page object in the wrong template. PW still went ahead and rendered it just fine in my case, but with the wrong content showing up. In your case, if the unexpected $page in the template produced a fatal error, it's possible that could have led to the blank screen as well (assuming no debug or superuser). Thank you for helping me to find this bug. This issue has been fixed in the latest commit in both the 2.0 and 2.1 source. Please grab the latest commit and let me know if the $page->render() now also works as expected from your side? Thanks, Ryan

Just for clarification (for other people reading this), the posts above mine and Adam's aren't talking about the plugin module, they are just talking about regular API use of PW's Inputfield classes. That FormTemplateProcessor module is just a proof-of-concept, and it may work with any field, but I have not tested it with anything other than text-based fields. In addition, the style recommendations included at the bottom of the module file only attempts to style these simple fields. Even if it does work with any field, I would not recommend adding file/image uploads or things like that to a contact form. Most of PW's Inputfields are designed for administrative tasks, not contact form tasks -- It is overkill and overhead for simple contact forms. But for simple things like text, textarea, integer, email, url fields, the distinction doesn't matter much. For fields that deal with outside assets (file/image for example), those should not be put on a public contact form (nor do I think they would even work). Probably so -- When I make updates to this next, I'll put it in it's own thread. I think in most cases people are better off creating their own forms for most things you would have on a site (at least that's what I do). But this module can be very handy in the right circumstances, especially as something to build from.