ryan

At the 960px to 1199px width, we're at our ideal line lengths (12 words per line on center column). Right sidebar is about the same as the one on this site. Do you mean the one that appears in the 768px and 959px (i.e. tablet/iPad view)? I'm thinking about throwing down the right column on this view, but not yet sure. I can make the border color there configurable (vertical vs. horiz) so someone could make it the same as the background color, making it invisible. I'm going to use a repeater for the color configuration. Two fields in there: CSS selector and color picker. Kind of a fun use of a repeater. The admin will remain configurable by it's own themes as it is now.

Thanks for the feedback. All 3 fields are required on comments, as they've always been, so didn't think there was a need to designate required vs. non-required, since they are well, well… required. But I think you may have a sixth sense because I'm adding an optional 'website' field, which brings the required vs. non-required designation into play. So expect to see it before this blog profile is considered final.

I agree, I don't know how you get some much done! I wish that I had your level of productivity.

Repeater fields aren't designed to be used outside of the trusted user context of the admin (at least, not yet). That's not to say it isn't possible, just that it would probably take some time to figure out how, so I don't know how to answer the question yet. Even if you can get it working on the front-end, you have to be concerned about scale. Someone could create some real problems in your site by adding a million repeater items. So you would at least want a max_items option before considering something like this outside of a trusted user environment (and that's something we'll add soon). On the other hand, if you are building your own forms and creating and using repeaters purely from the API, then I think that should be fine. In that context, you can tailor it to the fields you are working with (perhaps not having to worry about things like AJAX saves) and account for the maximum items you will allow, etc. So I think my suggestion would be that if you use repeaters outside of a trusted user context, then create and populate them via the API so that you can lock it down with some hard limits specific to your case.

Thanks for taking the time to do this testing Neil. I look forward to seeing the results and learning any ways we can make it even more secure. I've put a lot of focus and effort into the security of ProcessWire and think (hope!) we will score well. I'm not aware of any others that have run a comprehensive security analysis like you, so am very interested. If you find any concerns you want to review with me before posting, PM me here or email ryan at this domain name. Security is one of my favorite topics when it comes to web apps, so very happy to hear about this.

Here's the new blog profile that's built up from the Skeleton CSS framework: http://processwire.com/blogtest/ As Skeleton doesn't come with any real design elements, it's much more of a blank slate than Foundation. So I put a little design time into this one and the profile is much more custom than the Foundation one. I think it looks a lot better than before. Of course, it could use some color and perhaps icons and imagery, but thought it might be a much better starting point than before. I'm thinking we'll make colors configurable via Soma's color picker Fieldtype/Inputfield. I've also added a 1200px view (something that Skeleton doesn't come with) so that this profile has a nice "wide" view, in addition to a normal desktop, tablet and mobile view. Beyond a change from Foundation to Skeleton, this one also includes a lot of improvements and tweaks to the profile itself. Since this is still a work in progress, I won't post an updated ZIP yet, but just wanted to post this preview to the latest version.

This is something that a lot of us do because it's fun, not because it's something that we have to do. We might make a module so that we can do something like this because it's fun, satisfying, and efficient (plus it looks good) … echo $pages->find('brand=/brands/audi/, mpg>25')->renderCars(); But the reality is that it's also not necessary. You could perhaps more easily just package it into your include file and do this: $cars = $pages->find('brand=/brands/audi/, mpg>25'); include("./render-cars.inc'); And in your render-cars.inc: <?php foreach($cars as $car) { echo "<p>{$car->title}: {$car->mpg} mpg</p>"; } What I'm trying to get across is that much of the things we all create and use modules for is optimization and fun. Perhaps others feel differently, but in my case, most of my sites don't even use any modules other than what comes with PW. I create modules when I want something I can re-use on multiple sites or share more easily with the PW community. Another point about modules is that they are a whole lot simpler than you would ever imagine, once you get going with it. But the lack of ability to create modules is not going to limit your ability to use ProcessWire in any way. You can make it do pretty much anything without having to even know about modules. But when the time comes that you become interested in it, it will only increase your enjoyment of development. So when you see what appears to be complex development conversations about modules and such, don't worry. What you don't know isn't going to hold you back in ProcessWire. It already seems like you have a really good understanding of development and using ProcessWire. Based on your past posts, I feel confident you can push ProcessWire to do what you need when you want to. And we're always here to help with questions and problem solving. If I were you, I would keep using ProcessWire for everything that you are comfortable using it for. When situations come up that you feel can't be as easily solved with ProcessWire, then investigate services like what Pete mentioned (Lemonstand, Shopify, Google, Facebook, Flickr). There are services out there for nearly everything and this is where a lot of functionality is trending. For instance, look at the quality of a comments service like Disqus... it makes you wonder if we aren't far off from the time when built-in comments are no longer considered a required core feature of CMSs. When we had to setup a forum for ProcessWire, I never considered trying to create it myself in PW. Instead, we went with SMF, and then IP.Board. Services like these and others are better than what you can reasonably expect to build on your own, or what you could expect to come with (or be added-on to) any other CMS. Honestly, if you use ProcessWire and then utilize services for the things you don't want to build, then you will be able to do everything you could ever want. And more quickly, more securely and easier to support, than if you were trying to leave it all to a CMS. For the rare cases where you need something that won't be easy to do in PW, and your service options are limited, then bring WordPress into the mix. Not that WordPress can do much on it's own, but it's following is so much bigger than anything else that literally every possible thing has been coded for it. I certainly wouldn't want to use WordPress as my CMS, but I have no qualms about pulling it in when something that I need is available as a WordPress plugin. You aren't going to find any other CMS that has as much 3rd party stuff built for it. WordPress is easy-enough to figure out in a day (from a development perspective) that you also won't find yourself as frustrated as in Drupal (at least, this was my experience). It's not much prettier than Drupal from an output generation perspective, but it will be much more respectful of your time.

You can do it like this to set it to today's date/time: $page->date = time(); Or like this to set a specific date/time, you can use any format that PHP's strtotime() function accepts, like this: $page->date = "2012-06-25 11:36:00";

This definitely sounds like mod_security. When posting a form with a field that has specific tags in it causes a 403, and posting it without them works, then you can be pretty sure that's mod_security coming into play. It sounds like your host has mod_security configured to block <iframe> tags appearing in POST submission values. This doesn't make a lot of sense given that all the embedding sites like YouTube use the iframe tag. I would check with your host and ask them how to disable these mod_security rules so that you can properly use the account.

It's hard to answer for sure, because I don't see anything in your first code example that draws a relation to multiple checkboxes on the front-end. But based on what you've said, I'm guessing one of the checkboxes has a name of "type_of_oper"? i.e. <input type='checkbox' name='type_of_oper' value='something' /> If there is another checkbox, then you would need some code to handle that one too. Since these are checkboxes rather than radio buttons, you'll want to give each one a different name in their <input> tag. You could also take an array approach, using the same name and appending "[]" to it so that they come through as an array. But if we're only talking about 2 checkboxes here, then I think it's better to just make them separate.

I think more likely we're both inspired by jQuery. However, it is possible they took inspiration from PW on their API. I published the very basics of the ProcessWire API in 2008 here. Then I emailed it to a few CMS authors, hoping someone would take interest. This was at a time when I wasn't yet sure if I wanted to pursue making ProcessWire 2.0, or joining another project. So I tried to put some stuff out there to see if anyone took interest. I got no interest from other CMS authors (at least not that I knew of), but got a lot of interest from other web developers (users of CMSs). So that's one reason why PW 2.0 open source went forward.

I'm not sure that I understand completely, but if this is specific to repeatable fields you may need to modify the InputfieldRepeater.module to change the output to be what you want. If it's something that you can perform the adjustments with CSS or JS, then even better, as it would be simple to make a module that includes a CSS or JS file that modifies the output without you having to modify any modules. You can also use hooks, but repeaters are probably the most complex fieldtype/inputfield, and I've not put a lot of capability in those (yet) in terms of modifying the output via hooks.

Sounds good. I should be able to get this isset() update into the core early next week. I'm going to initially keep it as a config option, which your module can set dynamically. That way we aren't taking much risk just in case changing the isset() behavior is a problem elsewhere.

I think that your first example looks fine in terms of the code. I'm not sure I understand the question on that one. For the second one, what kind of field is object_square? I don't see anything amiss in your code, but based on the operators ">=" and "<=" it makes me think that object_square is an integer and should probably be sanitized/typecast as such, rather than as a string. i.e. $valueMin = (int) $input->get->squareMin; Also there's no reason to run an integer through htmlentities(). There's also no harm in it, but just wanted to mention it might not be necessary if you are keeping it as an integer.

It's definitely possible to build some great calendars and calendar functions in ProcessWire, and do so without using any other service. But I also want to mention that something like Google Calendar was built with millions of dollars and years of time, so it would be difficult to match the level of capability there. But if your needs are relatively simple, you can probably make a calendar in PW more easily than anywhere. There is no single way to make a recurring event, so I think your approach would just depend on how you've built the rest of the calendar. But I'm imagining that you would do it with a checkbox field called 'recurring', or 'recurring_weekly' or something like that.

Thanks for the updates RTurala, this seems like a nice addition. I will plan to bring it into the the core soon.

Thanks for the feedback guys. There are 107 fields, 29 templates, 8 fieldsets, and a little over 1000 pages on the back-end. Most of the work on this one was done before we had field/template context, so if I were building it again there probably wouldn't be quite as many fields. It's true it may not be important to query on all those little things, but PW makes it so easy to do it that I figure, might as well. There are some people that like those details, and I think it also gives the search crawlers more to chew on.

Nice job Marc. This is the nicest police department site that I've seen, looks like a fun project. Next you'll have the city of Ukiah wanting you to do all the their other sites.

Not sure that I know enough about the use case here, but you can get all the fields to edit a page by doing something like this: $page = $pages->get('/'); // get some page // make a form $form = $modules->get('InputfieldForm'); $form->method = 'post'; $form->action = './'; // add the page's fields to the form $form->add($page->getInputfields()); // add a submit button to the form $submit = $modules->get('InputfieldSubmit'); $sumit->name = 'submit'; $form->add($submit); // process the form if it was submitted if($input->post->submit) $form->processInput($input->post); // render the form output echo $form->render(); But I'm not sure how useful this would be on it's own, because it would be lacking all the admin CSS and JS files that make the forms what they are. So these forms may not be all that useful outside of PW's admin side, as many inputfields go well beyond basic form controls.

The reason those options don't appear if the cache time is set to 0 is because 'cache time' is not just a time, but also a toggle. When non-zero, cache is enabled. When zero, cache is not enabled. When cache is not enabled, none of the cache options are even considered by ProcessWire. But if you want to bypass ProcessWire's cache settings at runtime, you can do so. For example, you could use the 'URL pre-segment' approach, enable the cache, and disable it manually before rendering the page: $mypage = $pages->get($path); $mypage->template->cache_time = 0; // disable the cache echo $mypage->render();

It's perfectly fine to do what you are doing, but I'm not sure why $this->config; wouldn't work when wire('config'); would. They both pull it from the same place. But $this->config can stop working if you override WireData's get() or __get() methods with one that doesn't continue to call the original. However, it doesn't look to me like your module is doing that, so I'm not sure why $this->config isn't working. Just stick with wire('config') if it works, because the two are equivalent. Well I was thinking that ultimately we could make /site/templates/ the views folder for Twig, but until then I was intending to just stick with what you were doing before with /site/templates/views/. Anything else was a mistake on my part That's up to you, but I suppose that RenderTwig or even TemplateTwig or something might make more sense.

Here are a few ProcessWire sites I've launched in the last month or so. Nothing real big or exciting here, but figured it's good to post new stuff here when available. Blue Ridge Beverage This is a beer distributor for the state of Virginia in USA. I designed it back in 2009, but the client only recently came back and wanted it developed and launched. A friend did most of the development and did a great job getting everything working in ProcessWire. The client is still populating content here, so there are a few holes, especially in the Beverages database. Almanac of Architecture & Design Before you click on this one, note that this is using the default ProcessWire "basic site" profile (the client fell in love with it and didn't want to change… what can I do). But don't let that fool you, because this is actually quite a large and comprehensive site, particularly the Architecture Firms database. This one has dynamic maps, graphs, search engines and stats galore. There's also some fun stuff in the Buildings section. This site is an on-going project, so some sections are built out more than others, and stuff will be continually added to it. Jamaica Villas I just did the development on this one (not the design, other than tweaks). The design they had was very much in line with the Kickstart framework, so I stuck with it when producing in ProcessWire. I enjoyed using it, and was nice to use a framework developed by another ProcessWire user. I've worked on a few other villa sites in the past, and this one is smaller in terms of quantity of properties, though still involved a lot of work. This one has a full calendar and availability tracking system built into it (all running on ProcessWire), so it can search by availability or look at availability calendars and such. So there's a lot of power packed into this one. I just wish I'd had the opportunity to do the full design on this one, but it was still a satisfying and enjoyable project (as most are, when using ProcessWire)

I want to add in that ProcessWire does have a pretty nice RSS feed module included in the core. There is a good example of using it in the Blog profile in the posts.php template. I mention it only because it was the first item on your list of things PW doesn't have. As far as the quantity and scope of modules go, that's more an observation about the age of the platform than anything else. Had ProcessWire been open source since the early 2000s then I'm sure you'd find the same depth of modules that you do with the likes of Drupal and WordPress. And I actually think our plugin/module system is far better than theirs too. Growth in the quantity and scope of both free and commercially supported modules is something I would expect to happen with ProcessWire over time, so stay tuned. You've correctly identified some of the major compromises that come with a markup generating CMS like Drupal. I don't like that aspect of it any more than you do. But to the positive points of that approach, I think it gets to the heart of what you are talking about. Something that generates markup is by nature going to be able to provide more ready-to-go, plug-n-play functionality than something that doesn't. The compromise is that you don't have much control over that markup, and the markup is usually a mess. But if it's doing everything else you want, then it still may be worthwhile. As designer/developers we are perfectionists and we take our markup/code as seriously as the visuals, so it's hard to look past the mess and the inherent drawbacks. But you get a nice reward for putting up with this mess, which is lots of bolt-on functionality that you don't have to write any code for. It's a compromise like anything else. Unfortunately I've been unable to keep up with Drupal in my toolbox. I've used it on a couple sites, and have had to continue maintaining them. I was able to get past the wretched smell in the code after a lot of effort. But I absolutely dread doing any kind of administrative task or development task in the system. It's a giant time suck that I really don't like using. At the same time, I recognize that many enjoy using it, and I have a good respect for Drupal and all that is possible with it. So if you've found yourself liking it and it's answering some needs you have, add it to your toolbox (alongside ProcessWire). But only use Drupal when you have to. If you don't want to go very far with code, then I think it's good to keep one markup-generating CMS (like Drupal) in your toolbox for the times when it fits. And only use them when they are going to save real time. Use ProcessWire for everything else. Though for those that like working with code, I wouldn't bother with any markup generating CMS, as I think once you know what you are doing with code, they end up costing, rather than saving time. Also want to bring up the other one you mentioned, Expression Engine. There are some quality add-ons out there for it. If it's doing something that lines up with a given project, go for it. If you are doing work where people pay you for it, the cost of EE and any add-ons should be a non-issue. Your time is worth much more than the cost of these things. You should be passing along the costs of anything you purchase to the client. For me, I can't stand using EE any more than I can Drupal. But if you can stand it, then use it in the situations where it makes sense. EE at least gives you far better markup control than Drupal.

You are right--looks like a bug. Thanks for finding it. I've just committed the fix to the source. https://github.com/ryancramerdesign/ProcessWire/commit/af71f46eacb233c03878700a10c685b4042e84c3

You could also just set it to sort by "date created" (reverse) in the parent's sort setting? This used to be the case up until last month, but is no longer. PW will let you sort by any fields even if they aren't auto-joined.