ryan

Yeah I haven't figured out how to resolve that one just yet. Luckily core module additions are fairly rare, and in this particular case, that module will install itself. It sounds like you just made it to the modules screen before the page editor (with an image field), otherwise that module would have been already found and installed. Magnific Popup has replaced Fancybox for InputfieldImage. But FancyBox will remain in the core for now, as I know some modules (and sites) still use it. I'm also in OS X, though Safari 5.1.9. I haven't been able to duplicate that issue. It sounds like a javascript error though–check to see if anything appears in your JS console? In Safari that's: Develop > Error Console. Glad to hear the new font size renders better with Arimo and Windows/Chrome. I've not put much attention towards translation of this particular module since it is largely a tool for translating from English to other languages. I think those are translated with the field names. Some may be under the "show system fields" filter. Though to be honest, I'm not positive we're pulling the translated versions here or not. I'll check on that, as I've got some other related updates to cover. Thanks–I can see that here too. That button probably shouldn't be showing up at all. I'll add code to skip the button cloning when in modal view. I've used superfish before, and did like it. But kind of wanted to stick with jQuery UI here since we're already including it. We might as well use the tools that it provides when possible because there's no extra overhead in doing so. I'd be okay with pw-* (even if not as clear in code) but just wanted to have an expected/standard set of icons that modules know is always there. If something happens with font-awesome down the road, or we find a set we like better, I like the idea of being able to substitute the existing icon-* rules with another set, without everyone having to go in and change their class names. Just the term "icon" is a lot of clarity for code and seems like a good standard in our environment. I'm not really worried about collisions here since the admin is a more isolated environment. We aren't telling people what they have to use in their websites. Just telling Process module or admin theme developers that they can rely upon an icon-* set being available, regardless of what that may point to. But I don't really feel that strongly about this, and it doesn't matter much to me either way. The old admin theme will remain as a core-bundled option for IE8 support. Though admittedly I don't do any testing with IE8 and PW, so am not sure to what extent even that is compatible with IE8. This was a bug that was there for a day or two, but should be fixed in 2.3.7.

Are you sure (on 3 digits)? We didn't have to do that on the CMSCritic site, though I think we had to setup a custom news feed.

You can use fieldsets, but not tabs.

I made the logo. Its just mahalia and avenir (which I licensed through myfonts.com). Its totally fine with me to have the logo font (i love it!), so long as it's ok with the fonts/license (?). I would think it would be, but maybe somebody else knows more about this.

Sideshows and rate tables are examples of good use cases. Anything naturally bound by scale that produces in-page components, rather than groups of data that need to be represented by their own URLs. This sounds like another good use case example. Who said anything about phasing out repeaters? That is definitely not the plan. I currently have a big to-do list of items to improve repeaters, which I'm slowly working through. But just wanted to clarify that we're not trying to follow the path that Craft has taken.

Thanks Roope, I'll take a look at this and see if I can duplicate and find a solution.

Regardless of whether it would be useful in this instance or not, if it'd be useful to have this type of hook for anyone, I'd be happy to add it. Though rather than having the code in Database.php (now WireDatabasePDO).php it would instead be added as a hook that a module could monitor and take action when desired. I did get a preview of mindplay.dk's module and it's very nice. Rasmus I hope you get the time to finish and release it sometime, you always do great work. You are right on that from a portability standpoint, as the IDs may not probably won't be the same between systems, so could never be relied upon. But I suppose the queries could always be altered to reference the name rather than the ID. I'm not sure that I necessarily understand on this point or if it's something that can't be worked around, though you've obviously spent more time coding towards this need than I have. But just to help me understand, can you give an example of what you mean?

It doesn't matter. Either width() or width can be used in that scenario. When using the non-function version, $page->image->width then you are just retrieving the width. When using the function version you can retrieve or set set the width. $width = $page->image->width; // get the width $width = $page->image->width(); // get the width, same $thumb = $page->image->width(100); // get image having width 100 Same goes for the height.

I also share Mike's opinion, that forums are best left to dedicated software and we've already got a lot of great options. Part of this is that I think the huge scope of forums and the potential needs are not apparent until you run one. A CMS dedicated purely to community generated content (forum software) is a completely different animal than another type of CMS. The focus of features needs a very different slant, especially on the administrative side. What I'd be more interested in is bridges between ProcessWire and forum software, so that one can more easily communicate between the two. I know that Pete has been working on and off on this stuff for awhile with IP.Board and ProcessWire. Hopefully we'll be using some of those solutions on this site eventually too.

Actually this is very applicable stuff and I think everyone here is interested. I know I am. Thank you for posting! please keep doing so.

Or you could go in the opposite direction and minify all your output, and never again worry about what it looks like to others because... it's all on 1 line and you are doing it in the name of saving bytes! I'm actually using this in my latest project and quite happy with the result. Though I've made some modifications to it (to account for removal of Javascript comments and leaving textarea fields alone), which I still need to submit as a PR to michamichamicha.

Felix, it'd be great to find a way to get your articles in English versions too, perhaps published on your own site or here. I think there's a big audience that could benefit that might otherwise miss it due to not knowing German (and the imperfect Google translations). Though the same could be said for translating to any other language too, but I perceive ability to read English is a common element among most of our users. Though it does seem like most of our audience reads German too... I think I may be one of the few here that doesn't.

Good to hear about the new version of Foundation! I will plan to update this profile for Foundation 5 (and add any other necessary description files) as soon as there's time to do it.

I've recently built out a site that does exactly what you are describing. Users can create an account. Once approved as an editor, they have the opportunity to "submit new product" or "edit this product" (appears when viewing a product page). The submissions go into a FormBuilder queue, where the site managers review and approve them. When approved, they go straight into a page (whether new or existing), and the entry gets automatically deleted. The edit product form essentially looks like this (even though this is technically the search page). I would link to it directly, except they wanted the add or edit form submissions to be limited to registered users. All the forms on this site, including user registration, login, search and edit/add products are all done through FormBuilder. Though FormBuilder is not a turn-key solution for this stuff, as some development was still involved (primarily via FormBuilder hooks). But this site had to be developed in a very short period of time (a few days) so FormBuilder and the Foundation profile came in handy.

If that works, I think it should be fine. Another way to do it is to enable $config->advanced=true; in your /site/config.php temporarily, and you'll see a new "system" tab appear when editing a template. There is a checkbox there to disable the settings tab. But note that applies for everyone, not just a single role. If you use this, remember to change $config->advanced=false; as it's not intended to be something you leave on and some settings it offers are irreversible (thus can be dangerous).

You could always create an XML file in multiple stages and keep appending to it. If you are filling up memory even while using the $pages->uncacheAll(); as described in the original post, then you are probably filling up memory as a result of the output you are generating. In this case, it does make sense to write to a file and do it in chunks rather than all at once. What i mean by write to a file is fwrite($fp, $data); rather than echo $data; Whenever you fopen() a file, you can choose "a" as an "append" write mode, which means anything you write to it will simply be appended to what is already there. Chances are it'll take some time to write out 10k+ pages, so you'll need to ini_set('max_execution_time', 60*5); // 5 minutes or however long you need. Lastly, consider whether you really need a sitemap.xml and if it's worth the effort. My experience has been that so long as the site has good internal links, a sitemap.xml doesn't provide any perceptible benefit other than adding some fun to the webmaster tools screen. Though maybe others have a different experience.

You should be able to remove these files and it will immediately re-create them. One represents the list of modules in /wire/modules/ and the other in /site/modules/. You shouldn't ever have to manually edit them (at least I never have). If you got an error after removing the file, that sounds like your file system is not writable (and it was unable to create a new one). This would also explain why it was unable to see new modules. Try enabling debug mode and doing it again, as I'm guessing you'll see an error message about file permissions. You most likely have to do a chmod -R (or the recursive equivalent through your FTP client) to add write access for your web server on /site/assets/. Note that lack of write permission to anything in your /site/assets/ could create any number of other problems too. When ProcessWire creates files in there, it makes sure they are writable. But if you transfer files yourself (via FTP or something else that doesn't include permissions) then you would have to restore such permissions.

When I originally looked at this, it worked with some fields and not others (like rich text fields?). TinyMCE has such a plugin too, but it regularly results in false positives, which get to be a real annoyance. I don't like adding stuff to the core unless I know it's going to work universally across any field, triggering when it should, and not triggering when it shouldn't. Otherwise I know I'll get regular bug reports about this or that field not working with the functionality. Another factor is that I've never personally felt the need for it, nor has it ever come up with a need with clients, until Mike mentioned it above. So I've always seen this as a feature that would serve as a big annoyance for myself and many others. But if it's something that at least 30% of users would use, and it can be done in a way that always works, then I think it would make sense as a core module and I'd be happy to include it. That's so long as it's something people that don't want it can leave uninstalled. But in lieu of these conditions, I think it makes a lot of sense as a 3rd party module and I'm thankful that you've created it. It's been awhile since I've tried it, so I'll have to experiment with it again.

Files uploaded to pages go in /site/assets/files/. Files uploaded to FormBuilder forms go in /site/assets/cache/form-builder/ (or another directory, which you can define in your FormBuilder module settings). If you've got a file that's going in both, then that would be because you've got FormBuilder publishing entries to pages. I don't recommend automatically publishing entries to pages–better to approve them individually before publishing to pages. But either way, if you are publishing entries to pages, then there's going to be a file associated with the entry and another associated with the page. If form submissions are being used for the purpose of publishing to pages, then typically you'd delete the entry after publishing it to a page (thereby deleting the original copy of the file too). Let me know if I've misunderstood the question?

Could it be built more rapidly, smoothly and reliably with ProcessWire? Absolutely. Could the same be said of using a quality framework vs. starting from scratch? Yes, though I'd personally choose ProcessWire. Would it be as scalable as building something from scratch, and optimizing it specific to the need? No way. As Facebook grew, they even went as far as to build their own PHP, separate from the one you can I use. Using an existing PHP framework like ProcessWire is an excellent way to take a potentially big idea to fruition. If the idea is a good one that delivers on being the next Facebook or Craigslist, then you'll have no problem getting the resources to take your application code where you need to. I think most of the heavy-hitting services out there start this way, and then move on to something custom once the scale justifies it. But that scale is extremely large. It would be cost prohibitive to build for that scale when you haven't yet reached it. In terms of price to pay, the most likely needs for scale can be solved by increasing your server's resources or switching to a cloud-based hosting environment that can scale larger than an individual server. But again, if things get Facebook-large, then you'll be in an entirely different segment where you'll probably be building not just your own software, but your own hardware too.

I'm not sure I know enough about this particular case to suggest code for it. But PW's API is PHP based so you can pretty much do anything. I don't know for sure what you mean by nested categories, but if you mean something like a category/subcategory/ structure, where you wanted to output the pages having each of the subcategories you could do it like this: foreach($pages->get('/categories/')->children as $category) { if(!$category->numChildren) continue; echo "<h1>$category->title</h1>"; foreach($categories->children as $subcategory) { $items = $pages->find("subcategories=$subcategory"); if(!count($items)) continue; echo "<h2>$subcategory->title</h2><ul>"; foreach($items as $item) { echo "<li><a href='$item->url'>$item->title</a></li>"; } echo "</ul>"; } }

Does using require() in the module not work in this case? This is typically what any PHP class that extends another needs to do (require the class it's extending). That's of course in lieu of an autoload or something else doing it. If there's a way we can do it for them that's great, but cycling all the modules is kind of an expensive operation. I've also been thinking that I could have PW's core Modules.php parse the getModuleInfo() on it's own separately from PHP (loading it as a text file), bypassing any requirements needed by the class definition. Or just providing the option for the way PW1 did it: a separate ini or json file for the module info (i.e. MyModule.info).

Well PW uses strtotime automatically when you provide it non-numeric values for any date field in a selector. For some reason it didn't understand that your text was intended to be a date. But glad you found a solution, converting it to a timestamp on your own. But just wanted to mention it's usually fine to supply a formatted date in a selector, so long as it's one that strtotime() recognizes. Pagination is there to place limits on how much data you pull from the database at once. As a result, it's not something you'd typically use with results of a find() that are already in memory. I'm not clear if your $res->clndr->find() there is being called on a Page object or a PageArray object. Is 'clndr' a Page or a PageArray? If it's a Page object, then you should be able to just supply a "limit=n" and it'll take care of the pagination for you (so long as you've enabled page number support in your template settings > URLs tab). If it's a PageArray (i.e. 'clndr' is a multi page reference field) then you can still use the "limit=n" in your selector, but you'll also want to supply a "start=n" in your selector as well, i.e. $limit = 10; $start = ($input->pageNum - 1) * $limit; $items = $res->clndr->find("arrival=$dates, book=0, start=$start, $limit=$limit"); foreach($items as $item) { ... }

InputfieldCheckbox does actually support use of an alternate value for a checked or unchecked value (i.e. Yes/No), but you won't see it except in FormBuilder or in your own usage of the Inputfield. That's because FieldtypeCheckbox does not support different values for these. The reason is that they all map to 0 or 1 in the database, and I think it could get confusing if people start thinking of checkbox fields like text fields when it comes to searching/sorting, etc. So from the development sense, it's best to think of a checkbox field as a boolean or on/off toggle, and you can determine what the on/off state means from your code. This also makes it easy to translate for multi-language support, i.e. echo "Likes spicy food? "; echo $page->spicy ? __('Yes') : __('No'); Okay it's early in the morning here and I'm going back and reading your question again and seeing you mean within the context of locked fields and I see what you mean (appearance of "1" in editor just isn't so useful). I suppose we could always have FieldtypeCheckbox's formatValue() function translate the 0 or 1 to some other text (this is essentially what formatValue is for, though not typically used in admin setting). I'll keep thinking on this, it might be a good idea.

Obiuno, it sounds like your PHP version may have had blowfish support excluded, so changing the php version to 5.4.0 forced it to use the older hashing mechanism. It would be more secure to use the new one, but it it doesn't work in your case, I'm glad you found a way around it. Thanks for outlining the process.