Hani

My wife says the same thing to me all the time! Here's what I'm working on: I provide a service for realtors in my area that allows them to place a search engine for real estate properties on their website (with lots of functionality for their clients like saving searches, marking favorites, etc.) - the industry term for it is an "IDX System". It's completely functional, however, it isn't using ProcessWire. I'm attempting version 2 of the system with PW as the foundation. (Side note - it was a side project a few years ago and I only have 1 client using it right now, but I'm giving it some focus right now.) Now, our local MLS provides me with all the property listing data which is located in their own database. What I, and other IDX providers, essentially do is pull all the data and store it in our own database so that we can manipulate and search the data however we want. There are actually a few different tables, one for each different property type; residential, commercial, land, rentals, etc. Some of the fields are common among the tables, but some are not. Each property listing in their database has roughly 400 fields/points of information associated with it. Such as: MLS #, Realtor ID, Street Address, Street Suffix, City, State, ZIP Code, # of Bedrooms, # of Bathrooms, Washer/Dryer, Car port, garage, Style, Description, Listing Date, Price, Modification Timestamp, Master Bedroom Area, Master Bedroom Width, Master Bedroom Length, Bedroom 1 Area, Bedroom 1 Width, etc. Obviously TONS of individual pieces of information for each listing. What I have now, in the non-ProcessWire version, are 5 different tables with about 400 columns each. It's not terribly slow since when I pull data, I only pull the fields that I need .Now, that I think about it - you're absolutely right. Most of those fields, while containing data that I need to be able to display, are not fields that I have to ever search. So as diogo and Soma said, serialization and storing the data into a textarea field would be TOTALLY fine. And it would probably cut down on 80% of the fields. If I'm able to cut down on 80% of the fields, then this might not be an issue anymore. But I have never seen your Admin Hotkeys module - that's awesome! I'm totally going to be using it! I thought of doing that too; creating multiple pages for each property listing and splitting up the data - but like you said, I'd still have 800 fields in the system itself and whenever I do need to pull any of the pages to get the data, it would still end up using a lot of memory. Based on all the feedback, it sure sounds like I have! This sounds like a great solution too. But I suppose that since I never really need to search on so many of the fields I currently have, serialization would work for me without much effort. BUT the benefit of this method is that I would still maintain search capability on that data (using selectors) if I really needed it. Right? Those modules sound amazing and I can think of many scenarios where I'll need them. Like Adrian, can't wait to throw my money at you!

I just tried to use FieldtypeConcat instead of implementing my modifications and it didn't seem to work. While I was at it, I decided to make these into modules (compatible with PW 2.3.0). Its out on GitHub: https://github.com/Hani79/Processwire_FieldtypePageWithLabels Tested and seems to work just fine. However, I have a question, Ryan. I ended up simply duplicating the InputfieldPage and FieldtypePage modules and made my changes. I did this rather than extending InputfieldPage and FieldtypePage. Was that the right way to do it? I tried to extend FieldtypePage itself, but was unsuccessful. I was getting the following error: Which was referencing this line: class FieldtypePageWithLabels extends FieldtypePage {

Processwire's performance has always been fantastic for the projects I've used it with - but I'm currently working on a real estate project (converting it to PW) and hitting some performance issues. I have about 800 different fields in PW (crazy, I know) I have a few templates with about 400 fields each (crazy, I know) - all of these fields, with the exception of about 10, are simple text fields. Quite often, pages using these templates have a lot of blank fields. One of the fields is an images field. Several of the MySQL tables I'm pushing over into the PW template/field structure has about 400 columns in them. (Each record is a real estate property listing.) Important note: the site is currently on a shared host, so I'm not completely certain if that is the sole issue for the poor performance or if it is simply the fact that there are hundreds of fields to deal with. Issues I'm facing: Whenever I go to /processwire/setup/field/ (to see the fields), it takes FOREVER to load the page (and sometimes times out). (I know that's a lot of info to load, but what's happening in the background here? Can something be done to make it load faster?) Creating a new page via the API and populating it with data in one shot takes quite a long time. Questions: Can using a VPS single-handedly fix the performance issue? Is there a better way to structure the data rather than having it all in one page/template? (Consider the fact that I have all the data at my disposal when creating a new property record and it all needs to get saved.) Is having that many fields in PW in itself not a good idea? (Meaning, would it be better to leave the data in MySQL - outside of PW - and grab the data using wire('db') and custom SQL statements? I would just hate to resort to creating SQL search queries for all the queries I'd be using. I'd much rather use PW's selectors.)

Ok, apparently I wasn't looking in the right area. (Obviously, I don't know much about mod_security.) I ended up contacting Liquidweb and they helped me solve it. It was a matter of whitelisting some mod_security rules. Thanks for your input, fellas!

So, I turned off mod_security in the .htaccess file, and it didn't solve the issue. So I checked it out and it doesn't even seem to be installed. I'm perplexed!

Thanks, guys. I just got around to upgrading it to 2.3 - and it's still happening. So it probably is mod_security. Thanks for the tips - I'll check that out!

I'm not entirely certain why it's giving that error when a wrong password is provided - but the error message itself is saying that $user is a non-object. Which is strange. Can you try this? if($user->id && $user->isLoggedin()) echo ' logged-in'

I have an issue where after I insert a couple of images (happens with only one as well) at the end of the body field and save the changes to the page, I am hit with a 404 (at the same "edit" URL) and the changes aren't saved. What makes this REALLY strange is that if I put some text after the image, it saves just fine. BUT - it has to be at least 680 characters. Otherwise, it won't save. Also, this happens in PW2.2.9, but not on PW2.3.0. The HTML generated by TinyMCE looks just fine. I tried this on a new page and have the same results I've spent a couple hours trying to figure out what's going on with this - and am left scratching my head. Has anyone ever noticed similar behavior?

I just tested it in 2.3 and you're right. I was able to duplicate the issue, pogidude. I also was able to confirm that the problem exists in the Modules Select plugin created by Ryan. I'll see if I can fix it - but offhand, Ryan - any idea why that would be happening?

Seems like it's an issue with your language settings. There is an error with this part of FieldtypeDateTime.module $this->user->language->isDefault()) Edit: Basically, $this->user->language is returning as a NullPage.

Thanks, Alessio. However, that didn't seem to fix the issue I'm experiencing. It still seems to behave in the same manner. I suppose I should also ask, is anyone else able to confirm that this happens for them too? Or is this unique to my setup? My "section" page is set to allow URL segments of course.

I've enabled the redirect in .htaccess that will add www. to the URL if someone visits the site without it. However, it seems like the redirect does not take into consideration urlSegments and simply ignores them. For example, if someone goes to http://mydomain.com/section/urlSegment1/ They are redirected to http://www.mydomain.com/section/ The section in the .htacess that was enabled are these two lines RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Anyone have any thoughts or a solution? I'm an amateur when it comes to .htaccess.

I really don't see anything wrong with your code. Do you happen to have a live example that I can see what the result looks like? (Feel free to PM me with the URL if you don't want to share it publicly.)

I think the problem you have is that you're using ->get() instead of ->find(). Try this: $slides = wire("pages")->find("parent=/slideshow/, template=slidefeat, limit=3, sort=-date")->images; Edit: A little more info since it seems like you're just getting started. Using ->get() will always return only 1 result (if any matches are found). Using ->find() will return all the pages that match your selector. Edit 2: Actually, I just really looked at your code a little more rather than just glancing at it. You can't really return the images from multiple pages like that. You're going to have to loop through the matching pages and pull the images from each page independently. For example: $slide_pages = wire("pages")->find("parent=/slideshow/, template=slidefeat, limit=3, sort=-date"); foreach ($slide_pages as $slide_page){ $slides = $slide_page->images; // do something with the slides } Without seeing more of your code or a little more information about the page template/structure, that's my best guess at what you're trying to do.

That's fantastic! Exactly what I needed. Thank you, Soma!

Dredging up an old topic - but I'm facing this situation right now. Like Oliver, I'm looking for a way to compare two fields in a selector statement to avoid looping through pages and "collecting" only the ones that have the mismatched field values. It's agreeably inefficient when there are thousands of pages to go through. I'm definitely not a SQL guru by any means, so I had to turn to Google for this one - just in case someone had a solution. Surely, others have faced the same SQL problem before. Lo' and behold, I think there IS a way to do it! Here's an example of the SQL statement that takes advantage of MySQL's CONCAT function: SELECT * FROM movie_musicals WHERE NOT (year_one LIKE CONCAT(`year_two`)) And here's an example fiddle I threw together: http://sqlfiddle.com/#!2/3bed6/1/0 What are the chances of figuring out how to do this with just one PW selector statement? *crossing my fingers*. Or even just a SQL statement to run and have page id's of pages with mismatches being returned ?

That's very strange behavior. I haven't seen that before. There shouldn't be any limitation since this is a simple module that extends a core module. What version of ProcessWire are you using? I'm not sure if anything changed between 2.2 and 2.3 that would have resulted in this anomaly.

D'oh! So simple. Thanks, Pete!

Thanks, Soma! That does the trick to clear ASMSelect fields. I was hoping to not have to use any of the field names in the module, but since this is a very specific module that won't require scaling, I can live with doing it this way.

I just noticed that this approach does not clear values from an ASMSelect Page field. I'll be diving into this to find a solution that works for that input as well. Will post what I end up with.

No problem! Happy to help. I know excactly how you feel - the more you work with ProcessWire, the more enjoyable it gets. Yup - so when you save the booking as a page, the booking date can be used as a selector. So would be a quick example: (untested, written in browser) $m = date('n'); $bookings = $pages->find('template=booking, booking_date>=mktime(1,1,1,$m,0,date('Y')), booking_date<=mktime(1,1,1,$m,0,date('Y'))'); You'd probably want to be a little more specific with the selector (defining the parent page). Gotta rush out the door...

How are you saving each booking? Does each booking have it's own page in PW? If each booking has a date field (that defines the day that is booked), I would think it's rather straightforward. When you display the calendar, you'd just want to grab all the bookings that fall within that month. You'd loop through each of the days in that calendar month and if a booking exists for that day, you wouldn't provide a link to the booking form. Of course, I am making assumptions here about the entire process.

Is there a another way to do it? Although, I'm really not worried about sticking with the syntax I have since it seems stable so far. It doesn't surprise me that it works - ProcessWire seems to be able to handle anything I throw at it! Actually, that was one of the goals I forgot to mention in my original post. All I really wanted to do was "clear old" values (like Pete alluded to) on a page before redefining the values and re-saving the page. (I'm saving new field values in a page, but not all the fields will have one - so I wanted to make sure the old values were cleared.) I've also found that the name/url of the page doesn't get "reset" either - which is great in my case. Although...I would think I would have to redefine the name of the page if makeNew() cleared all the fields. Perhaps it has something to do with the name field not being located on the content tab?

I figured it out - but only because ProcessWire is so stinkin' logical. $p = $this->pages->get('/my-page/'); $p->fields = $p->fields->makeNew(); $p->save(); Bonus: it seems to even retain the page's name. Hope this helps someone out!

Is there a quick way to clear all the values in a page through the API instead of looping through all the fields and clearing them one at a time? I was thinking it would be something along the lines of $page->makeNew(). (I would want to retain the page's name and title, although those can be redefined after clearing all the values.) If not, is there a way to replace an existing page with a new one and retain the existing page's id, name, and title? From my understanding of the description for $a->makeNew() in the cheatsheet, that function won't work out of the box for what I intend to do.