bracketfire

This is a great idea, we don't really use the publish/unpublished thing for these pages, but maybe a solution right under me nose ? Thanks!

Occasionally we see an error which leads me to believe the site is trying to serve a page while (due to asynchronous background cron) it's being deleted. This particular page has around 100 fields, so page delete is foreach-ing across the fields. Site is on innodb. Has anyone ever wrapped delete in a transaction or anything to guard against this?

Did you ever figure out this locking problem? I'm seeing the same behavior in our application. Any insight you can share would be appreciated.

Mirza, did you ever figure out this locking problem? I'm seeing the same behavior in our application. Any insight you can share would be appreciated.

I'm running 2.5.3 and hitting an error when trying to sort like this: sort=facility_page.title,sort=end_datetime using the title of a subfield, and getting back Column not found: 1054 Unknown column '_sort_page_facility_page_title.title' in 'order clause' It looks like the fix ESRCH references in this post will fix it. But I'm too much of a noob to figure out which release I need to upgrade to for the fix. Can someone smarter than me look it up?

As part of a move to a new hosting provider, I've upgraded from 2.4.0 to 2.5.3, following the instructions and everything worked perfectly. I couldn't find anywhere the details of how PW knows to make schema changes during upgrades. I'm guessing that there's code somewhere that checks on every page load and calls a routine to make the changes needed for the new version? And that there's an indication in the DB somewhere indicating which version of PW it's been upgraded to? Thought it might be useful to post this question to get it documented for others. Since I'm going to be periodically re-importing the old 2.4.0 database underneath the new 2.5.3 code until "new version go-live", I assume it will make these schema changes each time I do that and subsequently load a page?

I have a PageField that holds a single page. I've been trying to find the proper way to unset it, I've seen an example of using "unset" but that doesn't feel right, or very processwire-ish. Right now, I'm using $facility->region_page = new NullPage(); But this also, just doesn't feel right but appears to work. Is there a best practice for unsetting a pagefield?

Just a quick note for future drive-by readers. For some reason $users = wire('pages')->find("template=user,roles=buyer,sort=email"); didn't work for me, but $users = wire('users')->find("template=user,roles=buyer,sort=email"); did. Not sure why.

This is a great module, appears to work great and is exactly what I needed. I just tripped over something, not necessarily an issue with this specific module, but I'm getting this Notice: Undefined index: HTTP_USER_AGENT in <CUT>/modules/LoginPersist/LoginPersist.module on line 508 When I bootstrap Processwire for use in a backend cron job. It seems like in init() there should be some check to see if Processwire is running in the context of a web site. Not sure the best way to fix it, and I admit most users probably don't bootstrap PW for use in a cron. It's an edge case for sure. Here's what I did: public function init() { if (php_sapi_name() != 'cli') { $this->set('doLoginHook', true); $this->session->addHookAfter('login', $this, 'loggedIn'); $this->session->addHookAfter('logout', $this, 'loggedOut'); $this->_pruneLogins(); $this->attemptLogin(); } } Detecting if PHP is being used via CLI with php_sapi_name() is based off an answer on stackoverflow at http://stackoverflow.com/questions/343557/how-to-distinguish-command-line-and-web-server-invocation Great work on this module!

Not quite sure where to post this, but here goes. I'm building a site that uses the Map Marker and Map Markup (Google Maps) modules to geocode addresses and save the lat/long. Is there a selector to find all pages who's lat/long is within a certain radius of another page? Has anyone done any work on such a selector? Maybe something like: $pages->find("template=Place,center=$page,radius=10"); I've found the math to do this, and if nothing like it exists I'll write it and can contribute it back to the community. Don't want to reinvent the wheel if somebody already has done this. Thanks!

There's a little more to it. A seperate cron launches every minute, checks for auctions that are close (within 5 minutes) of closing, and launches this script in the background for each one. while(true) allows this script to poll the PW page for last minute bids, etc. and when the auction closes it breaks the loop, emails the winner, etc. and exits. So this script isn't actually a cron, it's launched by a cron to watch a specific page for a while, then exits.

I see uncache() now, I guess what's confusing is that there's a page cache and a selector cache. It looks like you are right, in this case where I'm using a simple id=XX query, using uncache() on the specific page is probably enough. And yes, Craig, you are right - this is a loop in a cron job so it's a little different that a normal page generation deal that creates HTML for the browser.

I've got a cron job that bootstraps processwire as shown in https://processwire.com/api/include/ It watches pages in a loop (auctions happening live) and checks fields periodically. while(true) { wire('pages')->uncacheAll(); $auction = wire('pages')->get($auction_id); It appears that without the uncacheAll(), changes to the page (changes made external to this script) aren't picked up by the get(). Is this the best way to assure I don't get cached pages? I found this method by looking at wire/core/Pages.php and didn't see a way to invalidate a certain page or pass an option to get that says to avoid any caching.

Awesome explanation, thanks for taking the time to document this. I'm rapidly acquiring a real taste for this thing they call processwire

I just Googled "Total Dumbass" and my picture came up

Let's say there's page structure like /houses/1-main-st/appliances/dishwasher And 1-main-st uses a template called House.php and dishwasher uses a template called Appliance.php. Then let's say I use a selector to get all appliances, say, with an expired warranty. Then I want to find the house it belongs to. In jquery, you can use "closest('.house')" for example to locate the encapsulating house. Is there a way to select the house in PW? To walk "up" the page hierarchy until I get to the first one with a certain template? I believe I can easily code one based on a technique shown by Ryan in http://processwire.com/talk/topic/2262-exclude-pages-with-unpublished-parent/?hl=selector#entry21087 but I'd hate to re-invent the wheel. Sometime when trying to figure out selectors I find an example in these forums that makes me slap my forehead and say "Of Course! Duh.".

I see when creating a Page fieldtype, under details, you can have the API return either a NullPage or actual null if the page is not found. I'm wondering why anyone would want a NullPage. It seems like the common use case would be if ($page = selector) { $page->stuff... } else { // not found stuff } The documentation states "so that your API code doesn't have to always check that the returned Page is valid before using it", but that doesn't compute for me. I must be missing something. Why would someone operate on an invalid Page? I've searched the forums and couldn't find any examples of the benefits of returning NullPage. Since I'm trying to apply best practices while I learn PW, I just thought I'd ask the community.

I agree with what you've said. In fact, after reading this insanely exhaustive write-up about password reset techniques, http://www.troyhunt.com/2012/05/everything-you-ever-wanted-to-know.html, I think it might be best to send the user a reset link that's only active for a few hours, and have them pick a new password rather than emailing them a temporary one.

I stumbled upon something last night that tripped me up for an hour or so. I'm using 2.3. I've added a field, temporary_password, to the system's User template to hold the temporary one sent when they click forgot password (from the front end). It's label is "Temporary Password". But when editing a User, I see two "Set Password" fields, one is the standard password and one is the new one I added. I had been setting the wrong one by mistake and then couldn't figure out why that user couldn't log in. It looks like for some field types the label set in the field's setup isn't shown? Does a Password field always show "Set Password" ? The Description is shown properly once the field is pulled down, so they can be distinguished now that I know. But it seemed inconsistent that some field show their Label and others appear to show some standard one?

Thanks for this, nik. I also stumbled upon another post today where Ryan talks about the risks of saving $input->post to session, directly. http://processwire.com/talk/topic/1128-session-problem/ Essentially, he argues to store only what you need, after sanitizing it. I tend to agree and will go that route.

Let's say the user submits a form. If I then process the form and return a page, and the user reloads that resultant page, they are hit with the famous "Are you sure you want to resubmit the data" dialog. In other apps I've written, I've avoided this by using the http://en.wikipedia.org/wiki/Post/Redirect/Get (Post Redirect Get / PRG) pattern. Essentially, I handle the CRUD or other database work when processing the POSTed page, then save any necessary values in session and redirect to the same page via a 302 redirect GET. That way the POSTed page doesn't appear in the browser history, and they can reload freely with no side effects, and if they hit BACK they go back to the form and aren't prompted to re-post the data. I'm wondering if others do this and if anyone has any neat processwire-ish ways of handling it. In particular, is it acceptable to save the posted data in session with $session->PRG = $input->post; $session->PRGPAGE = $page->id; so that any values needed in the following screen (to generate a confirmation message, etc) are available from session. In my system Template Files are controllers derived from a base class, so on each subsequent page, if the page doesn't match PRGPAGE, I'd clear the $session->PRG data so it doesn't hang around as the user moves around on the site. Does this make sense? Anyone else doing something like this to avoid POST resubmits?

Thanks for the great response - exactly the information I was looking for!

I'm building an architecture for a PW site where the Template Files are actually Controller classes. In these controller objects, I'm accessing the API with: $input = wire('input'); But I'd really like to be doing it like: $this->input My Controller classes don't currently extend any of the PW classes - But I'm guessing they should (and down the road I'll run into more reasons *why* they should) but don't know if I should extend Page, Wire, WireData, etc. What's the best thing to do, to have access to the API globals that you'd just use as $page in a "flat" non-object/class template file?

Thank you for this quick response. I'm convinced of it's elegance in the common, simpler cases. What concerns me is how PW stores these custom fields (I haven't dug into the schema yet), and how challenging it gets when you have to look up, say "select all auctions whose status is closed and last_modified is greater than some time, and the seller_id is foo order by closed_ts asc". Or doing Joins or using cross-tables for many-to-many relationships. I'm worried when the going gets complicated, do you write SQL directly and how easy is the schema for custom fields to deal with?

I'm planning on using PW for an upcoming project. Normally I plan out the key database tables I need, but now that I've been reading about PW and how it works, I had the usual epiphany. If all of PW is custom fields, and I create a Template to represent a group of fields, then PW "is the database". Is it true that rather than creating a "location" table, I'd create a location template and set it up with the address fields, for example? If so... How far should one take this methodology? Can you go to deep with this and live to regret it? How easy/efficient is it to query custom fields from other backend tools that aren't part of the site? Do you just bootstrap PW and work with the "pages" that represent the "table rows"? How about querying with straight SQL? I guess what I'm trying to ask is, should I go "ALL IN", leveraging PW to the max this way, or build on custom tables in the "usual way" you'd do with other CMS's? Thanks in advance for any advice on this, I'm blown away by how PW works, but a little concerned about going "all in", so to speak.