ryan

I see what you mean. I could reproduce that here. The deal is that the repeater doesn't want to be left with no fields, so it's aborting it when you perform an action that would essentially leave it empty. I will work on finding a better behavior for this.

That's interesting -- PHP 5.3 doesn't report this error. The methods it's complaining about are implemented. Here's the inheritance stack: Wire > WireData > SessionHandler > SessionHandlerDB. The __get() and __set() methods are implemented by WireData. The PHP 5.4 error doesn't appear to be correct, unless they've changed something fundamental about the way objects work. Is your PHP 5.4 version possibly a non-stable version? If not, I'm going to see if I can upgrade to 5.4. Lots of tweaks to take care of still. I'll definitely lose the 85%. Right now it's responsive for the desktop browser and theoretically mobile responsive, but have not yet gotten to the point of testing with phones and tablets (will do that later this week). I expect a lot of tweaks once I'm actually testing with real mobile devices.

…and another update, the default admin theme is now responsive. Though I'm sure I'll be tweaking details on this for awhile.

The field and template tags features are now active on the dev branch for anyone that wants to try them out.

For those that wanted field/template categorization, I've got them implemented for fields and now development the same for templates. This is one of those features that don't take effect until you use it. The hope is that it won't add any complexity for those that don't need it. There is now a "tags" field on the 'advanced' menu of any field: You can populate that field with one or more tags. Read the description in the screenshot. When you populate that tags field, suddenly the fields list starts grouping them by tag, like this: You can make a tag group appear collapsed by default by prepending a "-" to the tag. Any field can have multiple tags. It'll appear in as many groups as it's defined in. This isn't yet on the dev branch -- I will push it tomorrow after finishing up the Template tags. Can anyone else duplicate in 2.2.10 dev branch, DB session support module installed? I've never been able to duplicate it, but followed the official instructions on the solution to this issue so afraid to change much more until it's repeatable.

It depends. If the file is placed in a non-web accessible quarantine area and the download link runs through a passthrough script that eliminates possibility of file execution or unsafe mime type, then yes, it would be more secure. If that's not an option, then emailing may be more secure so long as the file size is kept small, and the file never exists in a publicly accessible URL on the server. Keep in mind anything sent through email is going to have to be base64 encoded, so the file will suddenly become a lot larger once it's encoded for email. Have the file send to gmail or some other service that has a strong filter for malicious stuff. Keep in mind that it's limiting the file extension, not necessarily the file format. One thing I see through my public upload forms is a lot of files like c99.php.jpg where the person uploading is hoping that there's a bug somewhere down the line. If there are any files involved, there are additional dangers in having it create a page at form submission time. Not saying it can't be done safely, but just saying it starts getting more scary to a security paranoid person like myself. If the files involved are images, I would only add images to the page that were confirmed to be actual images. One way to do this would be to use PW's ImageSizer() class to create another size variation of the image, and add that one instead of the original. This is what just about any social network does when you upload photos to it. Here's a stab at some validation. Not suggesting this is everything you'd need to do, but just attempting to cover most bases while thinking here in the browser: // $filename = the file that was uploaded $pathinfo = pathinfo($filename); if(!in_array(strtolower($pathinfo['extension']), array('jpg', 'jpeg', 'gif', 'png'))) throw new WireException("Invalid"); $info = getimagesize($filename); if($info === false) throw new WireException("Invalid"); list($width, $height, $type) = $info; if(!in_array($type, array(IMAGETYPE_GIF, IMAGETYPE_PNG, IMAGETYPE_JPEG)) throw new WireException("Invalid"); $targetWidth = 200; if($width == $targetWidth) $targetWidth++; // forced resize $sizer = new ImageSizer($filename); if(!$sizer->resize($targetWidth)) throw new WireException("Invalid"); Everything that FormBuilder does is meant to save you time. The default embed methods isolate the form from the rest of your site so that [unlike FormTemplateProcessor] you don't have to get involved with the CSS part at all if you don't want to. Meaning, it'll exist in your site without any effect or requirements on your site's stylesheets. That's assuming you utilize the default embed methods. But if you love having control over your own markup (even if it's isolated from that of your site's) then Form Builder will not be as much of a time saver just because writing markup takes time... especially form markup. Half the benefit of a form builder is that it takes care of the output for you. The other half of the benefit is that it takes care of the processing for you. The most time savings come when you let it take care of both for you. Though it'll do just one or the other if you want it to. There isn't currently a means by which to inject custom attributes into the actual markup. You'd have to do this with jQuery. Though this would be a fine way to go given that the data attributes are intended for javascript use in the first place. Each Form Builder theme has the ability to specify a custom JS file (like you can with a custom CSS file). So you'd do it like this: $(document).ready(function() { $("#your-input-id").attr('data-something', 'Something'); });

Thanks for the explanation. I get what you are saying now. I'd be supportive of anything that achieves what you are talking about so long as it doesn't change the nature of the API interactions. For instance, I wouldn't be enthusiastic about having to literally type out command pattern syntax from the API code (or asking our users to), but would be fine with that sort of pattern happening behind the scenes. It seems like you've got a good start on this with what you were already doing. If there are any hooks, methods or states I can add that would facilitate it, I'll be glad to. For instance, after a field/template has been populated at load time, it could switch from a population state to a command state. It's already doing that in a sense with the setTrackChanges(), trackChange(), and getChanges() methods, but they are obviously for a different purpose. We have a pretty clear separation of data from meta data in ProcessWire, but it is by table. I totally agree with separating data from meta data, but think the distinction between flat file vs. table (or any other storage mechanism) hardly matters here. Either can be equally accessible for any purpose. Seems like storage medium shouldn't even be part of the equation. These things are all flat files behind the scenes. I'm fine with duplicating it into some other flat files if that adds a convenience factor for a particular purpose. Logical separation obviously makes sense. But isolation of these things from one storage system to another (database vs. file) seems to me like it increases the chances of corruption. If I need to restore a database or a public_html directory, I would be distraught to find the data and the schema on different file systems. For the same reason, it would be disheartening to find SQL dumps that have nothing but INSERT statements and no schema. Looking outside it all looks bad. Nobody likes eval(). And there is no good place to store code that will be run through eval(). At least in the cases where I've seen PHP code stored in a database, it was a matter of pursuing the lesser evil as it relates to the context of a web site (or perhaps the more secure one), not a misunderstanding or a blind decision. The eval() function really should be renamed evil(). If you are presented with a situation where the requirements call for input of PHP code through some form, nothing you do will look good to people looking from outside. I have been asked a few times to introduce some ability to enter PHP code in text page fields (like you can do in Drupal for instance). I understand the convenience it may bring, but have completely avoided it thus far.

Assuming all the pages that have the contact form are using the same template (or including the same file to process the form), then you don't need to worry about "putting the same processing logic on every page." It may appear that there is duplication there, but there actually isn't. If the code is shared, it really doesn't matter whether it all posts to the same URL or not. A situation where it would matter is if you were using template caching on your pages. In that case, you could solve it by making all the forms submit to the same [uncached] page. Though you could also solve it just by setting a cache-disabling POST var in your template settings.

The tags are fairly no-frills at the moment, and they behave exactly the same as text fields. I haven't tried it out yet, but think that you could specify more than one tag in a query like this: "files.tags~=hello, files.tags~=greetings". Once you have the actual page field, the hasTag and findTag methods don't accept more than one tag at a time. The actual tags field on the Pagefile is just a string. The tags came about for backwards compatibility with Dictator CMS (~2003). I recently had to redo a couple of sites running Dictator into ProcessWire. It was going to save a lot of time to implement the tags back into ProcessWire rather than manually converting a bunch of image and file placements. But I've found that the tags really can be useful today, as it provides a way for you to reference a file separately from the filename, or a way to group multiple files together, within the same field. That sounds good for the future. A little more than I want to get into now, but will bookmark this. Are you talking about the session issue that Soma was running into? This should now be fixed in the latest dev branch. Let me know if you are still experiencing it.

This is perfectly fine. I think that's what most people do. Though those fields, pages and templates are the bare minimum foundation for nearly any site I build, so it's rare that they get deleted here. I guess you could say that the default profile is the blank profile for some of us.

I'm assuming that logo is an image field. Edit your 'logo' image field settings. On the details tab, what is the max number of images set at? For something like a logo, I"m going to assume you've set that at 1, since you typically wouldn't have more than 1 logo. If that is the case, the code to output it would be: <img src='<?=$page->logo->url?>' alt='Logo' /> If your max number of images is set at 0 (no max) or something more than 1, then you'd have to determine which image you want to pluck from the logo field. Lets say you want to grab the first image out of it: <img src='<?=$page->logo->first()->url?> alt='Logo' /> Or lets say you want to show them all: <?php foreach($page->logo as $file) echo "<img src='$file->url' alt='' />"; ?>

Not sure I understand 100%, but it sounds like maybe you have ready items set to 1? Edit your repeater field settings and see what the quantity of ready items is. It will keep that number of items ready to edit, hidden from view, but still existing in the background. When you delete an item, that item should be gone for good. Let me know if you are getting a different behavior and exactly how to reproduce?

I'm planning to add a tags option to fields/templates, per a thread with Renobird the other day. This will provide a basic categorization that one can use, that doesn't get in the way for the people that don't need it. Once you start using tags, the fields/templates will be grouped together when the admin list. The fields/templates will still all exist in the same namespace, but this will provide a visual grouping on the admin side for those that want it.

Can you clarify? I understand what you mean by command pattern, but not sure I totally follow the question in this context.

The file size shown for Sample.pptx is pretty large. You may need to bump up PHP's memory_limit. Can you tell what the memory limit is currently? One way to see it is to upload a PHP file to your server that has this: <?php phpinfo(); Then view the URL in your browser and locate the PHP ini settings. You should see a line that refers to memory limit. You want this to be 128 or higher. I have mine set at 256.

Looks good, thanks Nikola!

Taking the first example from the CrossSlide site, you could do it like this: <script type='text/javascript'> $(document).ready(function() { $('#placeholder').crossSlide({ sleep: 2, fade: 1 }, [ <?php $o = ''; foreach($page->images as $img) $o .= "{ src: '$img->url' },"; echo rtrim($o, ","); ?> ]); }); </script> I'm stuffing it into the variable $o before echoing it just so that I can trim off the trailing comma, which prevents a JS error in some browsers.

URL segments are a runtime thing that ProcessWire doesn't know anything about. It only knows where you want to allow URL segments, but not what they are or what you plan to do with them. It's up to you (in your templates) to look for the URL segments you want to act upon. Likewise, it's a best practice to throw Wire404Exception(); when your template gets a URL segment it doesn't recognize. If you want to avoid any possibility of there ever being a collision between a page name and a URL segment, then you wouldn't use URL segments on pages that had children where the URL segment names had potential similarity with the child names. However, I think it's okay to use them in the instance where you are because it seems like there is no chance for a real-world collision here. I would feel comfortable using the URL segment "category" in this instance just because it doesn't seem to be consistent with something that would ever be used as an article title (though that may be just me).

File uploads through public forms is where things can get dangerous if not handled really carefully. Adding email to the mix makes it even more so. When a client brings up this need, I always see if the need can be solved in some other fashion, like asking the user to email the file, or specify a URL, etc. I consider public file uploads kind of a last resort if nothing else will work, so generally avoid them when possible. Recognize that you will get viruses and exploit scripts sent to you through your public upload form (even if limiting it to images). Given that, it's important to make sure those files could never end up in a spot on the server where the user could access them by direct URL. It's also important to make sure that the client is prepared to deal with this sort of stuff. In terms of actual implementation, I think this may be outside the scope of what we can safely cover in full, but there are a lot of articles that include details of how to do this (search google for "file upload php email attachments"), such as this one at Sitepoint. Another option is to use Form Builder, which has page creation and safe file upload capabilities built-in. It doesn't email files, but it does email secured links to them (which is a more complex, but potentailly safer way to go vs. emailing the actual file).

Your selector looks good to me, assuming the repeater field is named rental_period. If it's not working, you may want to check what values you are providing to date_from and date_to, just to make sure they are either a unix timestamp or some other recognized date format string. Longer term, you'll probably want to be careful with repeaters for this particular purpose because it seems like quantities could grow quite large (over time) in terms of repeater items per property. You may want to setup an automated process to remove expired rental periods. I had a similar need when setting up a property availability system, but opted for a separate /properties/ and /reservations/ structure, where the /reservation/items each had page references to a /property/. So far this has worked well in the application where I'm using it.

I lose it here unless I copy the code out of the IPB editor (before message has been posted) and into a plain text editor, then paste it back. Once I post a message, I've lost the ability to alter the code without losing formatting. That's because IPB doesn't even retain the original formatting in the posted message (if there's any indentation). In some cases, I can copy the code out of the posted message into my editor, but this only works if there's not much or any indentation. It seems that IPB starts to exponentially magnify any indentation after the first tab (or 2 spaces). So unless I go back and redo all the indentation, IPB exponentially doubles the indentation yet again. :'( I actually keep dozens of text documents open with code samples I've written so that I can go back and re-paste them should I need to, but no longer had the one above. If you know of any tricks to avoid all this, I'd love to learn them. I anxiously await the day when the IPB developers fix these bugs.

You can do it if using Inputfields from the API, but not from Setup > Fields > some_checkbox_field. Though I'm not sure what you mean about a double negative. ProcessWire is designed to be friendly to schema changes. We assume that you are probably not defining everything you need ahead of time. As a result, it's preferable to use a checked checkbox field to alter a default behavior, not to enforce one. Lets say you have hundreds of pages using some template, and you decide to add a new checkbox field called enable_nav that you use to determine whether or not to show navigation on a page. You could say that you wanted that checkbox to be checked by default... great, but that only applies to pages created from this point forward. All your existing pages didn't have the field before, and are not checked. So now you have a new problem. Now consider the the alternative, which would be to make your checkbox do the opposite. Instead of calling it enable_nav, you call it disable_nav. Add it to your template, and your existing pages are kept in the proper default state. New pages created from this point forward will check a box to bypass a default state rather than enable one. Using this strategy scales well, enforces consistency and don't break existing systems when you add a new field.

It really depends on the server. This is a question for your hosting provider. In terms of ProcessWire, these particular permissions apply only to files in /site/assets/. The default permissions are going to work anywhere, but are not safe in shared environments that aren't completely jailed from one another. I don't know anything about your hosting environment, so can't suggest without more information. But one thing you can do is to test different permissions to find what will work. If 0700 for dirs and 0600 for files will work, that might be a good place to stay. But unless your server is using suexec, that won't work. If that doesn't work, see if 0755 for dirs and 0644 for files will work. This is a starting point, but you want to find the most secure solution for your server environment. The best way to check if something works is to create a page with a files field on it and upload a file. If the file upload does not work, then you've likely not found the right permissions. Once you have found the right permissions, make sure to go back and apply it to directories/files that already exist in /site/assets/, including the /site/assets/ directory itself. This is starting to sound like a good idea for a new module... The most common ProcessWire hosting environment is a dedicated one (server or VPS.) If that is also your environment, then you won't have to worry so much about locking down the permissions. But if you are using a low budget/shared hosting environment, then tweaking the permissions is definitely a good idea. Either way, your hosting provider will be the best to recommend what is right with their servers.

Here are some more recent 2.3 additions that are currently in the dev branch. This list is far from complete, but covers the more interesting ones: Admin Theme The default admin theme now handles long titles better. If you are editing a page with a really long title, it will dynamically reduce the size of the headline in the admin theme so that it can fit. After a certain point, if it still won't fit, then it will wrap it. If you try to make a headline as long as a paragraph, then you are on your own though. Inputfields Added the 'side-by-side' (inline) option to Checkboxes and Radios Inputfields. This lets you have them all display on one line, floated, rather than placed in columns. To do this, specify "1" for the optionColumns setting. Added ability for PageEditImageSelect to select images from within repeater fields on a page. Update InputfieldDatetime to support i18n jQuery UI translation files with the datepicker. TinyMCE: Add config option to ProcessPageEditImageSelect enabling you to turn off the population of width/height attributes in TinyMCE inserted images. This is desirable for responsive images. To configure this go to Modules > Process > Page Image Select. Sanitizer Added new $sanitizer->entities($str); method, which is the same thing as htmlentities($str, ENT_QUOTES, 'UTF-8'); Added $sanitizer->emailHeader($str); method that does what it says (sanitizes an email header). $sanitizer->url(); will now optionally accept query strings. Comments Fieldtype Add new 'redirect after post' option which makes the Comments form perform a redirect after a comment is submitted. This prevents the possibility of duplicate submissions and enables the user to see their posted comment immediately (when applicable). To enable, see the 'details' tab of your comments field. You can now search the contents of comments fields from $pages->find() selectors in the same way you search text fields. Example: $pages->find("comments*=some text"); Added new 'website' field option to comments fields. To enable, check the box in your comments field 'details' tab. Added Gravatar support to comments fields. To enable, select the Gravatar rating in your comments field 'details' tab. Added option to not send notifications to admin when comment is detected as spam. Some of us were getting dozens of emails a day from spam bots making the rounds through our sites, so this prevents that from annoying us. Added new gravatar() method to Comment class that returns the Gravatar image URL (this is a convenience for those implementing their own comment output). File and Image Fieldtypes Add new 'tags' option to FieldtypeFile. This gives you the option of specifying a 'tags' field with each file/image. From the API, you can then retrieve a files/images by tag using $page->files_field->getTag('some-tag') to retrieve first match or $page->files_field->findTag('some-tag') to retrieve all matching files. Previously you could only retrieve files/images by filename or index. You can also use "[field_name].tags=[tag_name]" in $pages->find() type selectors. To enable tags for any files/images field, see the checkbox on the field details tab. (Note that this also affects InputfieldFile, Pagefile, Pagefiles, FieldtypeImage, InputfieldImage, Pageimage, Pageimages). Add support for secured pagefiles. Now unpublished or non-public pages may have their files (in /site/assets/files/...) protected from direct URL access. For existing installations, you need to add $config->pagefileSecure = true; to your /site/config.php in order to enable this capability. See also $config->pagefileUrlPrefix and $config->fileContentTypes in /wire/config.php, if interested. Files become secured when the page is not accessible to the 'guest' role. Functions/Methods Add new methods to WireArray class: replace(), findRandom() and findRandomTimed(); Name of the last one may change to findRandomInterval before 2.3 is final. Add new wireRmdir() function, to go along with the existing wireMkdir(). The wireRmdir() function works the same as PHP's rmdir() except that you can specify a second boolean argument to make it recursive. This essentially results in a directory prune function that not just removes the directory, but everything in it, recursively. Be careful with this! Add new wireSendFile($filename); function that works as a file passthrough script. This is used by the new secured file functions, but also available for your use should you want it. Add new wireRelativeTimeStr("timestamp or date string"); function that provides a relative time string like "1 minute ago" or "10 hours ago" or "5 minutes from now" type string.

This is great -- thanks for making this translation! Nice to see a new translation here.