ryan

I don't think as much about the mathematical stuff (as much as the SQL stuff), so I'm glad you guys are looking at it in this perspective too. Ultimately we're translating to SQL logic and the 'making sense' part is preferable to mathematical rules since selectors are a form of data queries rather than mathematical statements. But ProcessWire selectors are something new and aren't based on any existing standard, so we're kind of defining the standard here, and that's what I really like about these discussions. The more thinking that goes into the details like this the stronger it will be.

I was just reading this post on how to make breadcrumbs in ExpressionEngine (http://bit.ly/hello_crumbly) and how you basically have to resort to a plugin to do it for you. It reminded me of some of the problems I had with EE when I was trying to use it and develop in it awhile back. One being that URLs aren't a primary/unique key to a page, natively in the system. Imagine ProcessWire with only it's root level pages and url segments, and that gives you an approximation of what you have to deal with in EE. I'm not saying it's wrong, but it's a different approach, and one that I found frustrating to work with. The post also made me realize I didn't have anything on the site demonstrating how you might make a breadcrumb trail (other than in the default site profile). It's really a simple thing (at least, relative to EE), so figured I'd post here. : <?php foreach($page->parents() as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } You may want to output those as list items or add some >> signs between items, but as far as code goes, the above is all there is to it. What it's doing is just cycling through the current page's parents till it reaches the homepage. Lets say that you also wanted to include the current page in your breadcrumb trail (which is probably redundant, but some sites do it). What you'd do is just append it to the list of parents that gets cycled through: <?php foreach($page->parents()->append($page) as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } The reason this is so simple is because every page is anchored to a specific URL and those URLs are representative of the site's actual structure. Pages in PW are actually uniform resource locators (URLs) whether on the front end or the back end. Because of that, there's no guesswork or interpretation to be done. In EE and Drupal (as examples) that data does not natively live at a specific URL. Instead that data is off in a separate container and the ultimate URL (or URLs plural) where it lives–and will be presented by default–are not as cut and dry. Yes, you can install plugins or go through strange taxonomic/channelistic/cryptic trials to approximate the behavior in other systems. And yes you can use url segments and pull/render any other pages you want in ProcessWire according to your own needs. But I'm talking about the fundamental and core system differences. This difference goes far beyond simplicity of generating breadcrumbs–it is a factor that translates to simplicity throughout the API.

Thanks -- This logic has been updated in the latest commit.

PW is treating that literally exactly what it says: id != 5780 OR id != 5800 If you read that logic, you'll see that it can't ever exclude pages from that. But it's a bit of a mind game, because I think people actually see this, even though it's not what it says: id != 5780 AND id != 5800 Anyway, the proper way to state such a condition in a selector is: id!=5780, id!=5800 But what is the point of a OR "|" in a negative condition? Considering your example, it seems the "|" in a negative condition is useless. I'm thinking we should have the PageFinder engine consider the "|" (OR) an AND when in a multiple value negative selector ... because this seems like a more natural/expected behavior. I had assumed it must be a bug when first trying it, because I was looking for the same behavior you were until I realized PW was actually doing what it was supposed to... though this behavior seems futile. I'm going to change it unless anyone else wants to weigh in on this or catches some logic I might be missing?

Are there any hidden files in there? try this: ls -alR /site/assets/

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.