ryan

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.

I've committed some updates to the admin theme, including a bump of the font size up a bit to hopefully look better in Chrome/Windows. I'm curious if you guys running on that platform find it makes an improvement?

It sounds like the dependency is working on the front-end (javascript side) but not the back-end (PHP side). So it sounds like a bug–I'll try to duplicate. But since you are on the dev branch and regular updates are made, especially with dependencies being brand new, you might want to get the latest dev branch, just in case this issue was already fixed (though I've worked on so much recently I don't recall offhand if this has been fixed yet or not).

Looking closer at LazyCron within your context, I can see a potential for more than one run of the same interval in high traffic or if the LazyCron jobs take more than a few seconds to run. I've gone ahead and added a second lock file to account for it. Can you try the latest version of LazyCron (just committed to dev branch) and let me know if it makes any difference? Btw, if your LazyCron jobs take time to execute, you might be better off using regular cron. LazyCron piggybacks on top of user web requests, so it has potential to slow down individual users (when slow tasks execute), whereas regular cron executes separately from the web requests so is not piggypacking on any users.

That's correct that the /wire/ directory should give you a 403, since the .htaccess is protecting it (it's a feature). That also means that the .htaccess is working. But don't yet know if Apache Rewrite engine is working (it sounds like it isn't). First off, are you sure that you named your admin /processwire/ ? The last step in the installer lets you choose what you want it to be named, so just double check that's what you named it (chances are it is, since /processwire/ is the default). Next, edit your /.htaccess file and add "RewriteEngine On" at the very top of the file. Then try to load any page in your browser. If you get a 500 error, that means your Apache installation does not have Apache's rewrite engine enabled. From that point, you could figure out how to enable it in your Apache settings (httpd.conf), but I'd honestly recommend just installing MAMP. The web server software that Apple distributes with OS X is really not configured consistently with how most web hosting situations would be, whereas MAMP very similar to a typical web hosting server. I never even bother with the OS X AMP setup, and always go straight to MAMP. It's free and it takes about 1 minute to install and be up and running.

Just watch out for TinyMCE adding all sorts of other spans with style attributes for various things.

It might just be a matter of the forum using an older version of CKEditor (3 vs 4). Does it work if you do an unformatted paste? i.e. shift+ctrl+v ? Though I'd have no problem making it support the videos as links, but it seems like that then creates a problem where you actually want to link to a video (as opposed to embedding it). If someone puts the link in it's own paragraph, maybe it's safe to assume they are trying to embed though. Especially if the anchor text matches the src attribute.

I would fully expect those guys to come up with a pretty implementation for matrix fields. After all, aren't they the ones that wrote the EE matrix fields plugin? I think that matrix fields make good eye candy, and provide a quick n' dirty way to solve some things in lieu of real structure. But I don't think they are great for the long term or large scale. I'm much more interested in creating timeless tools with well defined data formats and structure, and separating our clients from getting involved with defining schema. I can see the solution presented there being a bit of a monster as the format of data becomes more ambiguous than a rich text field (chances are it actually isn't much more than a rich text field from the storage end). Chances are that data can't be indexed, searched and plucked field-by-field the way ProcessWire's repeaters can. But I haven't actually used it, so maybe I'm making assumptions from what I see on that page. Such things would certainly be possible in ProcessWire, but I'm just not convinced it's right. I can see why the Craft guys are doing it, because they are trying to sell stuff and candy sells. Whereas we're trying to make the best, most sustainable tools for the long term and large scale... the meat and potatoes rather than the candy. So something like this from Craft is not something to "catch up" to, because their bottom line is to make candy you will buy, not on providing what's really the best. My full time job is to develop web sites and applications that use ProcessWire (rather than to sell you something), so I'm simply not interested in colorful gadgetry and instead want the best foundation of quality and substance, at least when it comes to the core. Matrix fields and repeaters are somewhat at odds with that goal (even ours to some extent). These types of fields should be used occasionally and sparingly, for specific purposes. As it is now, I don't personally use repeaters very often. Half the time that I see people using them, they are being used in situations when the person really would have been better off without them. So I'm not so enthusiastic about pushing the core further in encouraging use of repeater/matrix type fields, when I don't personally use them very often, nor do I often recommend them. Don't get me wrong though, I do like candy too (sparingly), but really want to limit it in our core. When you get down to the core, Craft doesn't hold a candle ProcessWire. But I'm always glad to support whatever people want to build as 3rd party modules, and ProcessWire is a good engine for this.

Whether it's okay or not largely depends on your hosting situation and whether it's completely isolated from other accounts or not. This would be a question for your web host. Chances are your web host hasn't heard of ProcessWire, so a quick way to get an answer to the question is to ask them what permissions they recommend for your /wp-content/uploads/ directory. While I don't know what the issue might be there, it does sound like you need to check your Javascript console. In Chrome this is in View > Developer > Javascript console. Look for error messages, as it sounds like there probably will be one there waiting for you. Paste it here. Also, another possibility is that the color picker module requires 2.3 or newer (?). I know that a few of my modules require at least 2.3.

ProcessWire 2.4 (2.3 dev) also has the ability to install modules, check for updates, and and update modules individually, pulling from the modules directory. It uses the same method as ModulesManager (actually Soma's code for the most part). But ModulesManager has a nice advantage in that it can check for updates on all your installed modules at once.

Great article Felix! I had to use Google translate to read it, and German is one of the languages it doesn't translate to English particularly well, but I think I caught most of it and thought it was really fantastic. Thanks for writing it! It sounds like you are going to do more and I look forward to it.

Wow, awesome update Teppo! The diff feature looks fantastic. Can't wait to try this one out.