ryan

I'm a little confused about the faceted search part, because [if I understand the example and terminology correctly] this is quite simple to do in ProcessWire at present. Here's an example from villarental.com that I coded in ProcessWire a couple years ago. I got there by clicking the terms in the left bar: Location: St. James Price: Up to $500 Bedrooms: 3 Features: Villas with Pool Of course, it doesn't let you select multiple items in each category, but that was by design (for ease of use, per client), not technical limitation, as it would be equally simple to implement. But there's nothing going on here except translating page references in URL segments to selectors. So when you guys mention facets as being a drive for something like Solr, what am I missing? I have no doubt that Solr can achieve these things at larger scale and more quickly than something like MySQL, as it's dedicated to the task. Though am thinking the audience that would benefit from this in ProcessWire may be limited. I don't think anyone has yet reached a scalability peak with ProcessWire where this would matter. Still, I'm interested in anything that enables us to scale further and faster and I do like what Lucene does. But because something like this may have a more limited audience, it's probably something we'd need to find a sponsor for in order to pursue in the shorter term. But count me as interested. The VisualSearch.js would tie beautifully to ProcessWire as the data source. Might be a good one to implement into the skyscrapers demo site.

Soma, this is great! I'm amazed how little code is involved in the module itself too. When are you going to start posting some of your new modules to the directory?

Showing a 404 is exactly what we do when there is a non-recoverable error like this (with guest user). But this is the one scenario where we can't. The 404 is a page like any other in the system, so if the DB is down, then we can't really retrieve anything at all. The DB is a vital organ. The only thing I can think of is that perhaps we could provide some custom predefined error template, perhaps /site/templates/errors/500.php that gets used instead, when present. But you'd have to assume the API was off limits, otherwise you'd potentially start an infinite error loop.

Btw, I'm totally happy to go in and update these things if you'd prefer, but didn't want to go in and start changing stuff without running it through you first. You are way better at writing this stuff than me, so I didn't want to mess anything up. I've still got another 2 days before I make it through all the forum posts, so if anyone is wanting a Wiki account, please send me a PM, which I should get much quicker and can get you setup asap.

Joss, thanks for your outstanding work on the Wiki! I am making my way through it and posting comments on the "Discussion" tab of each as I go through them. Here's what I've got so far: http://wiki.processwire.com/index.php/Talk:Basic_Website_Tutorial And just one or two comments on these pages: http://wiki.processwire.com/index.php/Talk:Pages_Overview http://wiki.processwire.com/index.php/Talk:Page_Field http://wiki.processwire.com/index.php/Talk:Article_Listing_Page

Thanks for giving it a try Pete. Let me know if there's anything I can do to help too.

I've always liked the CodeIgniter docs too, though haven't had experience with the others, but they also look nice. I found this rather humorous though: http://ellislab.com/codeigniter/user-guide Note the lack of a trailing slash in the URL above (copied from onejegolders post). Click it, and then click "table of contents" and click on any item in there. You will get to a page with some Arnold video. Apparently EllisLab hasn't accounted for the trailing slash vs. non-trailing slash.

Marc, I've been out of town so sorry for not being able to reply sooner. Glad you got this figured out. Let me know if you find anything else is still not working here.

Tested here and works great! Thanks for making this Boundaryfunctions and Soma! I look forward to seeing this in the modules directory. This is a very useful module for sure. Minor point, but longer term, I wonder about the hooking method and whether that might present problems for future InputfieldTextarea derivatives. This one specifically excludes TinyMCE, but feasibly there are future others it might need to as well. It makes me wonder if this module might better exist as an Inputfield itself (InputfieldTextareaCounter) or perhaps as a module config setting where you check boxes for which Inputfields it should apply to. Or perhaps as a core addition to existing InputfieldTextarea. These are just ideas for the future, but seems like what you've got here now is working great and I look forward to using it!

Fieldtype::sanitizeValue is the function that gets called every time you set a value to a page. So if you set $page->title = 'something'; then the value gets sent through FieldtypePageTitle::sanitizeValue before the value gets set to the $page. The purpose here is mainly to sanitize for type, potentially add some API setting convenience, and do it quickly. So a sanitizeValue() for an integer field would typically do nothing more than typecast whatever value is sent to be a integer. This function is not intended to be the place to sanitize/validate user input (Fieldtypes exist outside of user input context). Instead, this function is just here to make sure that whatever $page field you are setting does not end up containing the wrong type or something else obviously incorrect. If you want your Fieldtype to have some additional built-in validation or convenience here (to account for API setting of values), that's fine too. But this function is called every time a value is set to a page (whether you set it or PW sets it), so ideally it is fairly minimal and fast. Technically, implementation of Fieldtype::sanitizeValue is optional, but definitely recommended when getting into object-based values (like FieldtypePage::sanitizeValue, where it plays a pretty extensive role). Where you sanitize and validate user input is with Inputfield::processInput($input). That function literally takes the value from $input and populates it to the 'value' attribute of the Inputfield object. As an example, see the processInput from InputfieldText which is where we perform that regex validation. One thing you'll see in a lot of PW's core Inputfields is that we're actually doing the validation in the setAttribute() method, like in this example (again from the Text inputfield). In these cases, we see if the attribute being set is 'value' and if it is, we perform some additional validation on it. So whether the 'value' attribute is being set from processInput, or from the API, it gets validated in the same manner. This is the way to go if you want to validate both form input and values set manually, in one shot. But technically, you don't need to validate outside of processInput() unless you want to.

Also wanted to add this as a disclaimer for this forum: Any arrangement for work made via this board is a private contract between the individuals concerned. ProcessWire and Ryan Cramer / Ryan Cramer Design, LLC or any of its agents cannot be held responsible for the operation of that contract or any of the financial arrangements and will not get involved in any disputes under any circumstances. If it goes wrong for any reason, it should be sorted away from this community. Thanks to Joss for the suggestion and wording.

This is really great Joss! Thanks for all of your hard work here. What's the best way for me to send comments to you? Should I add inline comments directly in the wiki in some way, or post here, email or something else?

This is great Soma! Testing out here and seems to work beautifully. Please add it to the modules directory when you get a chance.

Great module Nik! I have updated the 2.3 (dev) to have that method hookable. I also made the redirectUrl an argument to the method, just to make it more useful for hooks. Tested out with your module and seems to work great.

Looks amazing Luis, I'm really impressed with this.

Quite a bit of validation options have been added to the Inputfield types since Form Builder was introduced. For instance, InputfieldInteger now supports min/max values and HTML5 number type. Text fields now support regex validation. Most of this is in the dev branch though.

2.3 (dev branch) also supports omitting the width/height attributes from inserted images. You can get to it via Modules > Process > Page Edit Image, and see the checkbox in that module's settings.

Could this line be the problem? Notice you are checking statusHidden twice rather than statusUnpublished: if ($galleries_page->is(Page::statusHidden) || $galleries_page->is(Page::statusHidden)) {

For your beginning/ending matches, you might also try using the %^= and %$= operators. They are the same as ^= and $= except that they bypass the fulltext index and the limitations (and benefits) that go along with that.

I'm stepping into this kind of late as I've been out of town, but just want to mention that if you've got a lot of plugins in WordPress that already accomplish what you need, there's no reason to try and duplicate that somewhere else. WordPress is a very good platform for many needs, and if you've got a couple dozen plugins accomplishing things you need, why look further? There should be no shame in using WordPress. Plenty of us will still use it when the needs match up. Ultimately the whole point of tools is to save you time and make your job easier. Use the tool that accomplishes the goal in the most direct manner possible.

The error message is intentionally vague because you don't want to reveal anything about the system or what's happening to non administrative users. Detailed error messages are a hackers best friend. If you are a logged-in admin user, then you should get a more detailed error message. Likewise, you can review your /site/assets/logs/errors.txt for more detailed messages. Lastly, you can enter an email address in your /site/config.php ($config->adminEmail) and get error messages emailed to you as they occur. The one that Soma mentioned sounds unintentionally ambiguous when it shouldn't be, so let me know if you find a way to reproduce it. However, the one BrendonKoz mentioned is very much intentionally vague for security reasons.

I take the same approach as Soma, which is to use browser tabs when I need to keep tabs on more than one thing at a time (like the Page List while editing another page). Basically I'll be in the page tree, and CMD-click the 'edit' link, when I want to keep my current Page List handy. I think there are a lot of good and welcome ideas here, and I'd like to do anything I can to support implementation of them in other admin themes. For the default admin theme, I feel like I've got to keep it immediately understandable and infinitely scalable. It's got to be something that will accommodate any situation. I have no doubt that other implementations are possible that would have more appeal to some (especially power users), but it would be a compromise in some other respect. What I'm trying to avoid is a sidebar tree because that gets awkward when things grow. I've been turned off by the way that Silverstripe and MODx handle this. Likewise, I'm reluctant to introduce any kind of frames in the default admin theme (other than modals) or accept the overhead of executing PageList on every request. I do like what Diogo demonstrated about a sidebar that pops out only when you hover (or click) it, but only if it were a top (or bottom) bar instead that can span full width. But there's lots of baggage to consider. Example: if taking the frame route, adding a new page wouldn't be reflected in the PageList. If not taking the frame route, then PageList is getting executed on every request. There may be simple solutions to these that I'm not aware of, or there may be other issues to consider as well. If anyone is interested in working on an admin theme (or variation of one) that accomplishes any of what's been mentioned in this thread, then I'd be very interested and glad to help in any way I can. If there's anything that needs to be added to the core in order to support, I'll add it too.

Nik, thanks for your research and testing on this. Admittedly I found a lot of ambiguity about the the salt rules. It's been awhile now, but if I recall correctly I was not getting the expected results when taking the PHP docs literally on this one. I found several other sources that indicated it should be 21 characters plus a trailing $, so that's what I went with. My first inclination here is to avoid the issue you brought up by making supportsBlowfish() return false when the PHP version is older than 5.3.7. After all, 5.3.19 and 5.4.9 are the current, so treating 5.3.6 and lower like 5.2 probably makes sense here. Based on your understanding of this, would this solve the issue you were running into? Or do you think revisiting the salt length is a necessity?

If you are using any template or markup caching features, you might also want to clear those caches after moving a site to/from a subdir. To do this, go in the admin to: Modules > Markup > Markup Cache > clear cache Modules > Page > Page Render > clear cache

Those status values are just meant to indicate the comment's moderation status whether spam, pending or approved. They aren't bitmask flags like a Page status, so I don't think it's a good candidate for what you are trying to do unless your statuses would supersede the built-in ones. You might instead want to designate a certain email address or IP address to indicate a system comment. These fields are already built-in and can potentially be repurposed. You can modify any of the values before a comment is saved by hooking before one of the functions in FieldtypeComments.module. I would recommend either sleepValue or savePageField, both of which are called before a comment is saved. Another alternative is to copy and rename the FieldtypeComments.module or all of the comment module files to make your own customized comments module. If you go that route, you'll need to rename the classes. I know that Nico has done this, so you may want to look at what he's done with it as well.