ryan

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.

Nobody likes upscaling. But if I call a function asking for it to create something at a certain size, it's because that's the size required. If there are other conditions surrounding that, shouldn't it be left to the caller to decide? i.e. if($image->width > 300) $image = $image->width(300); If not wild about extra arguments (especially booleans) in API functions because they aren't self explanatory in the resulting code. So I'll only use them when absolutely necessary. Whereas, a bit of code like above is self explanatory to us now, and years from now when things like "what does the 3rd argument mean" are no longer fresh on our minds. On the other hand, I've got no problem with self explanatory function names, like widthNoUpscale(), but sometimes adding more makes the API less simple.

You can edit the profile page directly and change the template that it uses. But it would need to be one that's doing the same thing as PW's admin template. A much simpler thing you could do would be to edit the existing /site/templates/admin.php and set it to add some stylesheet or JS to change the look. For instance: /site/templates/admin.php <?php if($page->name == 'profile') $config->styles->add($config->urls->templates . 'styles/profile.css'); require($config->paths->adminTemplates . 'controller.php'); You'd want to have a role called 'employee' that has page-view and profile-edit permissions, and nothing more. They will be able to edit their profile.

Thanks for posting this! The SVN diff looks exactly like the Git ones. This seems like a good method, perhaps even in addition to extension filtering. But one thing I'm wondering is, does it change anything about the result? ImageSizer fails at it's own check rather than at GD's check, but seems like it would still fail. I'm just wondering how this solved the issue of BMP images renamed to JPGs?

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.