ryan

I agree, Skeleton is the most in keeping with PW style (and definitely the first one I'd implement). But I think it would be more competitive to provide different versions of the same profile each implemented in a different framework. I've found it's pretty easy to do this, as code written for one framework tends to translate pretty easily to another. I've switched from Foundation to Skeleton in a couple of instances (including the blog profile) and was surprised at how simple it was to do. That's because all these frameworks are based on similar strategies.

I'll be thrilled to add this. I guess I figured HTML5 pattern support wasn't so standard yet, but apparently it is. It also looks to me like HTML5 patterns are PCRE compatible (?) which is great, because we can use the same pattern both client and server side.

That seems like an unusual error to me. I think the only time I've seen that was on an pre-5.2.4 PHP install. Do you know what PHP version was being used?

The skyscraper profile updates are actually one of the next things on my list. A half day is all I need. I plan to make some upgrades to it at the same time as well.

On nearly any site I've built, the photos are accompanying some product. So a site like that one linked above will have a single images field that all the images for the property go into. And then there are a few thousand of those properties (each represented by a page). Most properties have 20-40 photos. So if we averaged 30 photos per property, and there were 3,000 properties, we'd have 90k photos. I don't know what the actual number is as I've not counted up the totals on those sites in awhile. But there's nothing complex going on there, just a few thousand pages that each have a single images field.

ImageSizer won't do anything to do the original image if it thinks it's already at the target dimensions, so be sure to give it a size that the image isn't already at. A few lines of the code in the previous example was specific to that.

Integration with other source control tools -- that makes sense, I understand now. For the reasons mentioned before, I think there are some drawbacks to keeping the templates/fields on separate file systems from the tables that represent them. But the benefits you've pointed out make sense too. Seems like the best route is to choose both, rather than one or the other. I like the idea of the system maintaining a running file that keeps track of the updates in a manner that can be played back on another instance. So perhaps that's what we should aim to do. And I think this is what you were originally thinking with the module you've put together, but we could take it a lot further by making the capability part of the core. So lets keep the discussion going and see what we can do. I think it just depends on the management strategy of the website, more than the scale of the website. For the sites that I manage (a few of which are quite large), I keep local development copies that clone daily from the live server. But I keep my /site/templates/ version controlled with Git. For every 5 hours of code that I might be writing, I'm spend 5 minutes in the PW admin adding fields, templates or modules… though it's rare that even that is necessary. So this part has never represented a bottleneck. I simply re-create those fields/templates on the live server before pushing my template changes. So on this end, this particular part of development has never been a problem to solve because it doesn't actually consume any more time than any alternatives might. But I recognize my projects are not the same as other people's projects and what's not an issue for one may be for another. The ability to version control and deploy things like templates and fields makes good sense to me even if it's not as applicable to my own work. Not to mention it sounds fun, and I look forward to collaboration here.

The blog profile uses Skeleton already. I'm going to make the basic profile responsive for version 2.3. The 2.3 default admin theme is mostly there (in terms of being responsive), and since it's so similar to the basic profile theme, I'm just going to copy the media queries over to do the same thing in the profile. Though I am thinking that the project and users might be better served by powering the basic profile from a widely known CSS framework like Bootstrap, so we will have to keep looking more into this. I'm thinking it might be good to have 3 starter profiles that do the same thing: one in HTML Kickstart, one in Skeleton and one in Zurb Foundation or Bootstrap (or both).

Your theory is correct. When you search fields in a repeater, it is returning the pages that match, not the individual repeater items that match. So your search will be returning pages that have at least one of the repeater items matching your search. Once you've got one of those pages, you'd still need to determine which of the repeater items matched. What you may want to do is aim to match the individual repeater items instead. $matches = $pages->find("template=repeater_rental_period, date_from>=$fromvalue, date_to<=$tovalue, booked=1, include=all"); Then there's the question of how to determine which 'property' pages have the items you matched above. This is a relatively uncommon scenario, so I don't yet have a pretty solution for this. But you can determine the the property (as in real estate property) from each matching repeater item like this: foreach($matches as $item) { $property = $pages->get((int) substr($item->parent->name, 9)); if(!$property->viewable()) continue; // skip if property is unpublished or something // now you have the $property and the matching repeater $item } That solution comes via Soma, Diogo and Antti: I'll come up with something built-in for this soon, but until then the above is probably the best way to go.

I develop my sites locally from subdirectories. When I migrate to servers, usually they go to root, so I have the same problem. However, the fix is really simple. Load the DB dump file (whether from PhpMyAdmin, mysqldump or the profile exporter) into a plain text editor. I use TextWrangler. Then do a search and replace: search: "/subdirectory/ replace: "/ Note the leading leading quote ("). That just ensures that it only matches the subdirectory name at the start of an attribute. That's only necessary if you have other pages in your site carrying the same name as the subdirectory. Personally I think this method is simpler and better than the overhead of having something else manage it for me (like PageLinkAbstractor). But if you are regularly transitioning the same site back and forth between dev and live, then more automation for the issue might make sense.

Any idea how gist can be integrated into the forum? It seems like a good idea, I'll be glad to implement it. Though this may be a question for Pete as he knows IPB a lot better than I do.

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.