Jump to content

buddy

Members
  • Posts

    6
  • Joined

  • Last visited

Recent Profile Visitors

1,668 profile views

buddy's Achievements

Newbie

Newbie (2/6)

1

Reputation

  1. Hi all, I've just deployed my ProcessWire-based app to a new web server running PHP 5.4.5, and started noticing this error showing up in the logs: [url]/processwire/page/edit/ Core Error Directive 'allow_call_time_pass_reference' is no longer available in PHP (line 0 of Unknown) The error sometimes will cause a page inside the CMS admin panel to not load (with a blank "error has been logged" screen), but usually hitting back or reload will render the page just fine. The allow_call_time_pass_reference directive in PHP has been deprecated for a while, but finally removed in PHP 5.4, so that's clearly what's causing the error. The problem is that I have no idea why ProcessWire is triggering this error. There's no line number, and from what I can tell "allow_call_time_pass_reference" doesn't appear in any PW source code. Despite that, I think it is somehow the PW code which is causing this, since I haven't seen this error in any of my custom code, and it only shows up while using the PW admin panel. Any guesses? Thanks!
  2. 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!
  3. Thanks Soma, Your suggestion is exactly what I was looking for, and it works perfectly. (And to answer your other questions, the "usual" way was what I saw described in some other forum posts, and no, I'm not working with templates.)
  4. Hi all, I've created a dropdown field on one of my templates by using the usual PageArray method, and now I'd like to select pages with it. The pages that populate the dropdown field have a type and a single value. (Title: Red, color_code: 0xf00) My problem is that it seems that the only way to select is by page id, which seems ugly, because I have to do something like this: $pageIdForColor = [ "0x00f" => 2067, "0x0f0" => 2068, "0xf00" => 2069 ]; $page = $wire->pages->get("parent=/boxes/, color=" . $pageIdForColor["0x00f"]); Since all of my colors are already defined as pages, it would be great if there were a simple way to select by the color_code instead of having to re-create the mapping. I'm imagining something like this: $page = $wire->pages->get("parent=/boxes/, color->color_code=0x00f"); Anyone have any thoughts on how to simplify this? One idea I have is to just drop the PageArray method and code up a custom FieldType with these values fixed in it, since they don't need to be edited very often. Thanks!
  5. Hi Apeisa, thanks for the quick reply. I have it working now. I'm not working within the template file, and the $page->images object does not exist; print_r($page->images); is empty. There is no Image object or ImageArray there. However, it seems like I was making a mistake earlier, because after re-testing my code, $fields->get("the_image_field")->value started working. I'm not sure why it didn't before. Maybe I had a typo or some other mistake. Also, thanks for the tip about not needing the getInputFields call. I've re-written the code like this, and it works: $photo_url = $page->the_image_field;
  6. Hi all, I'm having trouble getting the URL for an image using the API. I have an image field in my template and I've uploaded an image, but I can't access it the usual way that has been suggested on this forum, which would be: $page->images In my code, the page object doesn't have any child called images: $page = $wire->pages->get("/my-page/"); $fields = $page->getInputFields(); print_r($fields->get("some_other_field")->value); //works great print_r($page->images); //nothing here print_r($fields->get("the_image_field")->value); //contains a protected data object which has a child that contains the URL I want So, the image URL is definitely buried within the data, but $page->images simply doesn't exist for me to access it the normal way. Any ideas about what I might be doing wrong? Thanks!
×
×
  • Create New...