ryan

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.

Actually it looks like 15px (0.9375em in our case) is a good route. This seems to render nicely in the Arimo screenshots above, and looks about the same as 14px in OS X. The 16px size I tested just seems way too big, but 15px seems like a nice balance. Is there something special about 15.245 or are you just being silly? You know I'm actually going to go test it out now. Just tried but I can't reproduce that one yet. My version of the admin theme here is a little newer so maybe that's the difference. I'll get these files together and commit them shortly just in case that's it. Thanks, I found the problem and fixed it. It will appear in the next commit. Yes it may come to that. I have no problem with Arial, but I've also become very attached to Arimo and so want to exhaust all options before giving up on it.

It looks like data rows are under category rows. What are data rows? Do these represents the pages having that category or something else? If they are the pages having that category, consider using page references and moving the pages to their own container. That way your pages can have multiple categories, if they need it. Though if multiple categories aren't ever needed, then the structure is just fine. Also your questions relate very closely to what the Blog profile does, so I'd suggest looking at that too.

Sorry, I wasn't thinking about the fact that your module actually extends ProcessLanguageTranslator. What you'd need to do instead is include the ProcessLanguageTranslator.module file somewhere outside of your class. I would put this before the class definition. require(wire("config")->paths->modules . "LanguageSupport/ProcessLanguageTranslator.module"); You may also be able to do this (below) instead, but it would have the effect of installing the ProcessLanguageTranslator module, which you may not want or need to do in this case. wire("modules")->get("ProcessLanguageTranslator");

Is this dev branch? None of those line numbers in the errors line up with the line numbers in the file. Also, I don't see any of those warnings and I've pretty much got debug mode on all the time locally. I also tried to duplicate this but couldn't. Here's the code I used: $img = $page->images->first(); $img2 = $img->size($img->width, 0); echo "<img src='$img2->url'>"; Is it possible you've got a different ImageSizer.php somehow? EDIT: Soma never mind–I'm the one that's got a different ImageSizer.php not sure how this has gone uncommitted for so long, committing now...

Nevermind about 12px–it's just too small, at least in OS X. 16px too big, but renders ok.

Your simplest best would be to just extend ProcessWire most basic starting point, which is Wire. This enables your class to have access to API variables (through $this), enables any of your methods to be hookable (that you precede with 3 underscores), and makes the file possible to translate with language support. Another option is to extend WireData. This is the same as Wire, except that you gain $this->set() and $this->get() methods that are accessible both in and outside of the class. It essentially means your class can function as a shared data container. The set() and get() can also be accessed by $this->key = 'value'; and $value = $this->key. The last utility class to mention would be WireArray, which is meant for storing an array of objects. This one is a little more complex than the other two (though it's still quite simple), and I'm guessing it's not what you need in this case, so won't go into detail unless you want me to. You don't necessarily have to extend any of PW's classes. But if you want $this->property; access to the API variables, you'd want to implement your own __get() method in your class: public function __get($property) { return wire($property); // or Wire::getFuel($property); }