ryan

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.

When you tried it before, are you sure that you were using $config->paths (not $config->urls)? The $config->paths shouldn't have the "~" in it, whereas the $config->urls should. The reason is that "~" is a virtual directory symbol that is used and interpreted by Apache. But it's not something that actually exists in the file structure, or at least it's not supposed to. Though if you actually have a "~" symbol in your directory path name, then all bets are off as I'm guessing this would confuse not just ProcessWire but Apache too. Based on what Apache uses "~" for, I have a feeling you might have tried to use $config->urls rather than $config->paths. After all, the rest of ProcessWire and all it's modules are already using the $config->paths and $config->urls variables where appropriate. So if there were a problem with using them then I don't think you'd be able to run ProcessWire at all. I have made the change on my system, but need to do some more testing to make sure it doesn't break anything. What we're doing is asking the Page::__isset() function to behave like the Page::has() function, so it's not really the correct behavior for isset to return true just because the field is valid for the page. So I'm thinking of providing a $config var that can be used to override the behavior, rather than just making the change permanent. That way a template engine module like this could customize the behavior towards the need. Thanks for the update! I look forward to taking a closer look.

Definitely interested. We do get occasional questions about how to use ProcessWire with some other framework or CMS, and they are running into name conflicts with some and not others. I think most recently I heard Laravel has some class name conflicts with PW, but CodeIgniter doesn't. So I think there would be demand for something that provides a solution to those conflicts. My only worry is if this makes a user's upgrade path difficult, since they are running on a modified version.

Those sound like good options to consider. I wasn't aware of the Phar-archives though am interested and need to take a closer look. But my worry is that anything that tries to bundle everything (including potential large images/files) in one export file to be imported elsewhere is going to run up against scale. I've got a couple sites where the client might have dozens of 12 megapixel photos on a single page. They are pretty unwieldy in size to deal with individually as it is. File-based assets are so unpredictable in size I think I'd be afraid to package them up together in any manner. But packaging up the references, and letting the system transfer them individually will scale well. But it does require that production server can talk to the dev server.

For that need, I would just modify the existing Comments module. You'll find the sendNotificationEmail() method in FieldtypeComments.module and it's pretty straightforward and easy to modify. Keep a copy of it separately from your installation as well so that you can plug it back into place after doing PW version upgrades.

Use Time Machine? Yeah, I know it's a backup solution. But it keeps dated versions, it's automated, and catches the things that I don't think to. It has actually saved me more than any other version control systems. But for more formal version control, I think Git is the best way to go. Lots of guides out there on how to use it. I think it also comes on Macs already. I don't necessarily think it's easy to use, but it's not any more difficult than any of the others.

Also make sure you are doing: echo $page->pub_date; rather than just: $page->pub_date;

Every site needs a 'root' page (homepage) but it doesn't matter what you do with it. I think all you need to do is just copy whatever is in your index.php file and paste it into the home.php file. And then get rid of your index.php file, because it will be home.php instead. Of course, you can also add/delete fields from the home template as needed.

This is intended as an installation profile, so not something that is ready to plug into an existing installation. Though you could certainly copy the templates, install the BlogAPI module, and re-create the fields and pages it uses in an existing install. Though I do plan to make the BlogAPI module installable, so that it can install everything needed by the profile into an existing site. But going to wait till the profile is pretty well nailed down before doing that-- it shouldn't be far off. Also an update about the profile: the next version is going to be running on the Skeleton responsive framework instead. I'm just finding that framework to be a little better for the blog profile. However, I'll still include the Foundation template and CSS file as optional, so that you can still use the Foundation version if you prefer it.