Leaderboard

TL;DR: My mistake. I didn't read the docs. Hi all, My app is getting different data when querying a field from the API than the data in the same field in the CMS view. Obviously this is very weird, and should not be happening. Looking at the database showed that the problem is being caused by two rows in this specific field_ table having the same pages_id with different data. One of the fields has sort=1, and the other sort=0, which is the only clue I have as to why this happened. The CMS view is grabbing the row with sort=1, and the API gets the one with sort=0 (just mentioning in case that's significant, though probably it's not). This problem is easy enough to fix, but I'd like to make sure that it never happens again. I added this field recently in what I think is a normal way, and I haven't been doing any direct manipulation of the DB. Any ideas on what might have cause this so that I can avoid the problem in the future? Thanks! Update: Okay, so I see how the duplicate rows are getting created. Every time I change the value of the field in the CMS view, it creates an extra row, with sort=1, sort=2, etc. I should mention that the data for this field is another page_id, since I've created a select dropdown dialog using the PageArray method. Is this really the normal behaviour? It effectively means that after the first time that I change the value of the dropdown, I never see it through the API when I select on that field, since it seems to select the oldest version (sort=0). Update 2: Okay, I was curious as to why this DB table would even have multiple rows for the same pages_id, and that led to me realize that it's to support multiple select. I changed the field setting to "Single Page", and now it works normally. Strange, though, that multiple select would be supported with a single select dropdown box, since the behaviour behind the scenes becomes invisible. Update 3 - Fixed: Okay, I now see that the 'input' tab of the field settings clearly states "Select one that is consistent with the single page vs. multi-page needs you chose in the 'details' tab of this field." My bad!

Check out the thread Custom Login, I think that'll be useful

I would also go for a structured page tree and see the page tree as the main repeater. Edit: need some sleep.. so also what I wanted to add you could keep the structure ...->book(page)->runtime(repaeter-range). So if the level of information becomes 1 dimensional use a repeater there i.e. runtime has a repater for range. Book1 ->Runtime1 ->Runtime2 - range1 - range2 Book2 ... Also depends a lot on how you want to be able deal with these data. Maybe some thought about what you want to be able to do with it later i.e. if storing data in json format or comma separated strings, you'll have hard time to filter content based on that. Using a page structure will, at the best, let you use simple PW selector queries to filter or search the data.

Hi Ryan, I've recently updated to 2.2.5, and now my custom login scripts won't login any users that are not Superusers. I'm using this script http://processwire.c...gin/#entry11290 that had been working perfectly in 2.2.3. Is there anything that changed with regards to how users get logged in via the API, or perhaps something I could have accidentally set in the admin to cause this? Users can still login in as expected from the native /processwire/ login. Update: This turned out to be some weirdness with Shibboleth (3rd party authentication) and not PW. It took me a minute to untangle what was happening. Sorry for the false alarm.

Hi all – Yep, Wikipedia is finicky about case. I've just now tweaked the Toolbelt template so that link goes through wikipedia/special:search, which will ignore case and link to the page if it exists – the link works fine now. Also, it's possible to just rename the page with the "rename" link in the edit dropdown – I'll fix that now too. Cheers – peter@toolbe.lt

Okay, I updated this to 1.0.1 to search recursively for files under the /site/templates/js and /styles folders - this is available from the modules directory as v1.0.1. I thought I'd work on v1.0.2 which lets you specify starting folders further up the tree whilst I'm at it but have hit a snag. It works fine, but when you change the path and hit save the drop-downs don't update their path unless you save the module a second time. Anyone have any ideas why you'd need to save the module twice for the config page to be able to use an updated value?

I would agree with this if the jQuery inspiration wouldn't be advertised on PW's homepage. In jQuery, something like parent($selector), would mean that you are selecting only $selector from all the results returned by parent(). This could bring some confusion to jQuery users starting with PW. I noticed that parents() works on PW to get all the ancestors of a page. I would say parents($selector) makes all the sense.