Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

76 Excellent

1 Follower

About prestoav

  • Rank
    Sr. Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Ely, Cambs UK
  • Interests
    Consumer tech, guitars, rock 'n' roll, classic cars

Recent Profile Visitors

2,429 profile views
  1. Yup, you were spot on Jan, thank you. The blog_tag field had been removed form the template in PW. Once restored the admin started working again. I'll mark this solved and raise a bug report for the module. Thanks again.
  2. Hi Jan and thanks for replying. I just checked the site and there is no field in the template with that name. There is one in the site, added by the module, but it is not in use in any template or assigned to any template in PW.
  3. Hi everyone, PW version 3.0.123 I've recently tried to upgrade the Blog module in an installation from 2.4.0 to 2.4.5 and now get the following errors when trying to visit Blog > Posts in admin: Fatal Error: Uncaught Error: Call to a member function count() on null in /MYSITE/site/modules/ProcessBlog/ProcessBlog.module:1299 Stack trace: #0 /MYSITE/site/modules/ProcessBlog/ProcessBlog.module(1421): ProcessWire\ProcessBlog->renderItemsSummaries(Object(ProcessWire\PageArray)) #1 /MYSITE/site/modules/ProcessBlog/ProcessBlog.module(1989): ProcessWire\ProcessBlog->renderItemsList(Object(ProcessWire\PageArray)) #2 /MYSITE/wire/core/Wire.php(380): ProcessWire\ProcessBlog->___executePosts() #3 /MYSITE/wire/core/WireHooks.php(723): ProcessWire\Wire->_callMethod('___executePosts', Array) #4 /MYSITE/wire/core/Wire.php(442): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessBlog), 'executePosts', Array) #5 /MYSITE/wire/core/ProcessController.php(333): ProcessWire\Wire->__call('executePosts', Array) #6 /MYSITE/wire/core/Wire.php(380): ProcessWire (line 1299 of /MYSITE/site/modules/ProcessBlog/ProcessBlog.module) This error message was shown because: you are logged in as a Superuser. Error has been logged. I can see posts in Blog > Dashboard and all seems to work still on the front end. Anyone else seen this or know of a fix?
  4. I figured that was most probably the situation but good to know. Thank you.
  5. The client's IT engineer found the issue last night. Their new live server had 'apache mod_security' enabled and that was preventing the AJAX response from getting through. As soon as it was turned off the AJAX response was received and image uploads started working. I'd be interested to see if anyone has had this issue and if it's considered bad practice to have this turned off long-term.
  6. Hi there, I'm hoping someone can help here. I've just moved a new site from my development server account over (where the site was working fine for the client to edit content pre-launch) to the client's final hosting account and the live site is all fine. However, while most edits can be done without an issue, image uploads in admin cannot. I know this has been an issue before but, having trawled the posts about it and suggested esolutions I still can't resolve it on their host. PW Version: 3.0.123 PHP version: 7.3.20 max_execution_time 160 max_upload_size 256M GD Library is enabled Looking at the console data it looks like the AJAX request from the image upload is getting a 403 error which is suggesting a permissions issue? First we get this on console: ?id=1169&s=1&c=1:1 Uncaught SyntaxError: Unexpected token < in JSON at position 0 Then, the AJAX request: https://*******/admin/page/edit/?&id=1169&InputfieldFileAjax=1 Gets a 403 according to Chrome Dev Tools > Network XHR. Also, the response is empty. Can anyone point me in the direction of the directory that deals with this and what the permission should be to allow it or indeed any other fix / area to investigate? Thanks so much for your help.
  7. OK, I think I found a way in, that is to read the DB more directly for the possible values. I noticed from the original thread about the FieldTypeSelect module @ryan mentioned it stored the options as non-relational values. So, with a bit or trial and error I managed to get the values out. Note that they are stored as a single text string with options separated by the "\n" that comes from the admin input field (I'm guessing). So to get an array of the values for the Select filed called 'listing_types' you can do this: // First let's get an array of the possible values $field = $fields->get('listing_type'); $lts = explode("\n", $field->data["select_options"]); // Now lets show them foreach ($lts as $lt) { echo $lt . "<br />"; } Note also that, as Ryan points out, if the select values in the field have been changed at any time then there may be pages with this field set to values that no longer appear in the array above. You could, I supposed, look at all the set values for pages and build an array that way but this solution works for me. I hope this is helpful.
  8. OK, I think I have an idea why might this me an issue. The field uses the older 'FieldTypeSelect' field type rather than 'FieldTypeSelectOptions'. Maybe the getOptions() method is not available for the 'FeildTypeSelect' type? Is there a way to migrate from one to another would anyone know? In admin for this field it's not possible to change the type to Select Options but I can create a new field of type 'Select Options'. Or does anyone know the method for the 'FieldTypeSelect' type to retrieve the options? Thank you!
  9. Hi everyone, PW v 3.0.165 I have a select field called 'listing_type' with three options. I'm trying get all values for the select to show on a page. First I have this in the template that grabs the field: // Get Listing Types $field = $fields->get('listing_type'); $fieldtype = $field->getFieldtype(); echo "Field title: " . $field->name . " Fieldtype: " . $fieldtype . "<br />"; This seems to work and I get "Field title: listing_type Fieldtype: FieldtypeSelect" on the page exactly as I'd expect. However, as soon as I add the getOptions line to get the field like this: $field = $fields->get('listing_type'); $fieldtype = $field->getFieldtype(); echo "Field title: " . $field->name . " Fieldtype: " . $fieldtype . "<br />"; $listTypes = $field->type->getOptions($field); I get this error: Error: Exception: Method FieldtypeSelect::getOptions does not exist or is not callable in this context (in wire/core/Wire.php line 544) Looking the exception report this seems to be the issue: Wire->__call('getOptions', Array) Anyone have any ideas why I'm getting this error? Thanks in advance.
  10. Perfect! Thank you. I can't believe I missed that!
  11. Hi all! I'm building a historical page of past events for a client using a repeating field per event and including a Datetime field to input of the date. However, the earliest year that is presented is 2010 (i.e. ten years prior to today). Some of the events the page needs to show have earlier dates than that (starting 2000). Does anyone know a way to change the default choice for this field type? I can't see anything in the field settings. Thank you in advance!
  12. Sorry for the late reply, that works a treat!!! Do you know if there is a similar way to set the tools as default as I couldn't see that in AOS? For example I'd like these tools as default in the editor bar: Format, Styles, -, Bold, Italic, -, Superscript, Subscript, RemoveFormat JustifyLeft, JustifyCenter, JustifyRight, JustifyBlock
  13. Hi all and thanks for the great work on PW! One thing I find I have to do on any new site is add the Justify plugin to textarea fields as it is such a widely required feature for text headings in content. ANy chance this could be added to the core an automatically be installed on new textarea fields using CKEditor? Thank you!
  14. Hi PSY! Thanks for this. Really helpful! I ended up getting it working once I found the missing PWlink plugin and have disabled some formatting tools too!!!
  15. Thanks again dragan. Console was a good call as it looks to be an issue with a missing pwlink plugin. Reloaded that then disabled it and all is working! Thanks for your help!
  • Create New...