ryan

Adam not sure why that would happen. Can you rename the /site/ dir? Are there any files in there (/cache/Page/ or /sessions/) that don't have the right permissions?

Not unnoticed, just things to do before this. But I'm quite certain we'll be doing this once getting through the current todo list. It looks like we now have two different and good ways to do this (whether 2 columns or half width fields) good suggestions!

I'm guessing that installing all the 3rd party modules might be a problem because many were designed for version 2.0 not 2.1. Unless a module specifically says it'll run with 2.1, it's probably not been tested with it. Do you have a guess about what module it might be? -- for instance, did the problem start appearing after you installed one of the modules?

Adam, haven't gotten your email. What address did/are/you sending to?

Can you describe the series of steps I would need to take on my server in order to duplicate it? Also, what version (2.0 or 2.1)? Thanks, Ryan

It's definitely planned -- I have a need for it myself. But it's not on the short term list. Most likely I think we'll target this as one of several items in 2.3.

So it's not safe for me to assume that you want $this->process or $this->page->process. It really depends on the context. In the example you linked to, it has to check $this->page->process because it's checking to see what process is going to be executed, not what process is being executed. Since it was a 'before' hook happening before the page render, the value of $this->process was always going to be ProcessPageView (viewing an admin page). But once that page render started, then it would load the new process (ProcessPageEdit or otherwise) and execute it, and then populate $this->process with that one instead. So the value of $this->process will change according to what is being executed and where it is in the execution process. That's why it's checking against $this->page->process rather than $this->process. Let me know if this doesn't make sense, I'm trying to type this out quickly and am not sure if I'm being clear.

What I meant by 2 queries where you would first find the parcells based on the non reserved value. Then go through those parcells as the 2nd query and look at which ones don't have any houses attached. i.e. $parcells = $pages->find("parent=/parcells/, reserved=0"); foreach($parcells as $parcel) { if(!count($parcel->houses)) { // found one } } I'm at the AEA conference here in atlanta, so a little slow on my replies today.

If the page in question actually has a field called 'process', then checking $page->process is going to return the value of that field. But $this->process [or wire('process')] is a runtime property that is made available to the system and represents the process that is currently running. My guess is that you probably don't want to be looking at the $page->process.

It'll be stated once the modules documentation is complete. Though I'm not yet sure it'll stay that way. I might change the loader to just look at what classes they implement rather than the naming convention... not yet sure. What do you guys think?

This is correct with both Textformatter and Process modules: they need to follow a consistent naming convention. This is just so that PW can filter them by name. Glad you got it working.

So long as any given shop isn't ever going to have more than 1 category, then the structure you mentioned is good. Admittedly though I am a little confused between house, parcell, shops, categories and places. But it looks like you are asking about a solution that effectively caches the number of shops on the place page, and that's certainly one good potential solution (and you could also setup a module to do it automatically if you wanted). Also, if there aren't going to be hundreds of parcell (place?) pages, then I think you'd be fine to do two queries too: first to find the non-reserved places, and second to determine which of them don't have any shops.

Adam, good question. What you are describing seems to be a parent-children relationship between PARCELL and HOUSE? In this type of situation, it might make sense to relate these things with your structure so that HOUSE pages are children of PARCELL pages. Then you can do this: parent=/parcells/, reserved=0, num_children=0 (I realized as I was writing this email that I hadn't actually implemented the num_children/numChildren field as an option in selectors yet, so I went ahead and added that to the 2.1 source and committed it. So it works now.) If you don't want to relate these things by structure (as described above) then you can't really use a selector because there is no HOUSE field on PARCELL pages (i.e. there's nothing to select). So if you need to be selecting them in this way, then it might make more sense to not have a parcel_reference field on your HOUSE pages and instead have a house_reference (multi-page) field on your PARCELL pages. Then you could select like this: parent=/parcells/, reserved=0, house_reference=0

I love the "unfeatures". I think you make a lot of great points, thank you for taking the time to write. It seems possible that some specific projects in the future may want to collaborate to make our products play nicely together. Though PW isn't well known at present so strategic partnerships may be difficult to get in the short term. But I also think it can be accomplished by providing standards, documentation and hooks to make such integrations easy to do. I'm also really not worried about trying to be all things to all people, because the core is primarily built as a means of handling web requests and of supporting modules, and that's not going to change. PW is going to stay true to its roots. The core will continue to get optimized, but most project growth will be accomplished through optional modules. For something like a forum, I don't anticipate we'd ever have something produced as a module that would replace the likes of a forum like this (SMF), but there may be usefulness in an optional module that provides basic forum-like capabilities for those with simpler needs (that perhaps don't want to install a full blown forum ... though a forum is not currently on the roadmap). I think there is also growth potential with modules that provide integration with existing web services rather than just existing software.

I like the overloading idea for some of these files. Will look at taking this approach in the future.

I think the simplest thing is probably just to duplicate that admin-templates dir into your /site/ dir. But if you didn't want to do that, you could do any of these: Duplicate just the file you want to change, put it in /site/templates-admin/ and then symlink to the others in /wire/templates-admin/ Create an 'autoload' module to intercept and modify the output of admin page renders. Create an 'autoload' module to add a CSS ($config->styles) or JS ($config->scripts) file that makes the change you want.

Documentation updated to cover these as well: http://processwire.com/api/selectors/

Great! glad that fixed it, thanks for letting me know.

This was a really simple thing to add so I went ahead and put it in, and it's now in the latest commit of PW 2.1: https://github.com/ryancramerdesign/P21/commit/f1c848a9a3766bf031e88bf7f10b667495eb26a3 In testing it on a site with 3,000 'bodycopy' fields (about 12 megs worth), I found it was faster than I expected. It's finding matches in about 0.2 seconds in this relatively large site. Though it depends on the search, and I'm suspicious MySQL might be optimizing some of them to MATCH/AGAINST queries. But all in all, it seems like it's a pretty practical solution for a site that isn't going to grow massive. If you need to match short words or stopwords, %= is going to be pretty darn useful, so thanks for bringing this up. While I was in the code, I also completed the ^= and $= search operators, so they should be fully functional now too. I use RLIKE for these rather than LIKE so that it could skip over potential markup tags or punctuation at the beginning or end of the field (something that couldn't be done with LIKE).

Sounds like the forum is having a fit because it flagged your message as spam too. I unflagged it. I tried to duplicate the issue here but so far can't seem to. I'm guessing SMF has some issue with a character in your password or something, but not really sure. We're up-to-date with the SMF version, so if it's a bug they haven't fixed it yet. If you want me to change any details for you, feel free to PM them to me and I'll make the change from here.

Good question. The $= and ^= search operators are actually designed to match text at the end ($) or beginning (^) of a field. They are supposed to serve the equivalent role of what they do in jQuery. The LIKE is only supposed to run as a secondary part of the query. In this case, the LIKE can be pretty fast because MySQL will only run the LIKE on the results of the MATCH as part of the same query. The reason you see LIKE '%$v' is because that is the proper way to match something at the end of a text field (and LIKE '$v%' matches at the beginning). MATCH can't actually determine where something is in the field, so that's where the LIKE comes into play ... it does a MATCH and then filters those results through the LIKE in the same query. A regular LIKE query can be pretty slow, but a MATCH+LIKE query can potentially be very fast. Everything described above is specific to ProcessWire 1.x. I haven't yet fully implemented the $= and ^= search operators in PW2, nor are they documented anywhere. So I'm pretty impressed by your question–you've done research. The plan was that I would eventually implement them in PW2, but they are more specific-purpose, so it just hadn't come up yet. What you see in the PW2 source is for placeholder purposes until it can be finished. I'm not in front of the code right now, but I don't think $= (or ^=) is functional... or if it is in some way, it wasn't intended. It sounds like you are looking for something that matches anywhere in a field, but does a LIKE without a MATCH. This is something that PW doesn't have currently, but I think it may make sense for us to add it? Perhaps as "%=" as the search operator (which nods to the LIKE syntax). True it'll be slow... but we'd use it with that understanding, and sometimes it really doesn't matter if it's slow. I think we can add it pretty easily.

I just added this to the 2.1 source. Once I got it in there and started using it, I realized locks and keys with unrelated purposes are probably confusing. Plus, now that we've had it there for a couple months, I don't know how useful it really is to show the "locked" status of a page in the PageList. What you proposed with showing pages that remove access is a lot more useful to see in the PageList. So I've dropped the 'locked' status and have re-purposed the lock icon to show pages that remove 'guest' access. Also added a corresponding 'unlock' icon that shows pages that add guest access under a tree that's already locked.

I guess that's another way to put it ;D

I've just posted a fix. Strangely, I could duplicate it in 2.1 but not 2.0. Then I discovered I had an update already waiting in the 2.0 source for this particular problem and it just hadn't been added to Git or committed. I must have fixed it at some point, been distracted, and completely forgot about it. But now it is committed in both the 2.0 and 2.1 source. Please let me know if this fixes it for you? Thanks again for letting me know of this problem. https://github.com/ryancramerdesign/ProcessWire/commit/03b60394fddc186aa8cfe3dd9f4de7670dc73c8a I wasn't able to duplicate the image alignment issue that you mentioned. Are you referring to image alignment in the actual TinyMCE editor, or in your site? If it's in your site, note that you have to add your own classes to your site's stylesheet. This is what I have in the default profile, which may serve as a good solution or starting point for further tweaks: /** * Alignment styles that are used by the InputfieldTinyMCE for * positioning images in bodycopy. If you are using this field type, * you may want to include these or similar styles in your site. * */ .align_left { float: left; margin: 0 1em 0.25em 0; } .align_right { float: right; margin: 0 0 0.25em 1em; } .align_center { display: block; margin-left: auto; margin-right: auto; }

Thanks for the report. I was able to duplicate it and am now working on a fix.