prestoav

PW 3.0.165 / Admin Theme UIKit Today's head scratcher! I have 20+ PW sites running on my localhost under MAMP at localhost:8888, many of which are PW 3.0.165 / UIKIt Admin theme. Today I noticed on one site the admin 'View' links in the page tree and the page editor are removing the port number from the URL. so rather than linking to 'localhost:8888/site/page' they are linking to 'localhost/site/page'. To make things even more weird the other admin links ('edit' for example) leave the ':8888' intact. Finally, it's only happening on one site, the others on the same host are fine. I've looked at the .htaccess and there are no rewritebase rules in operation. I wondered if anyone else had seen this and figured out what that may have happened on any thoughts on possible reasons? Thanks, as always, in advance.

Yup, that's it exactly, I have MultiLang installed but only one language (me default installation ready for multilang sites). I'll mark this solved. thanks for the link to that thread @wbmnfktr ?

Hi all, I could have sworn I used to be able to use the site generic 'title' field as a sub field of a repeater field. However I've tried to do this on two 3.0.165 sites recently and, while it will add the title field in the repeater field setup, it wont save the repeater title sub field's content when the repeater is used in a page template and edited. It;'s not a big issue but I wondered if this was a known restriction?

Hi @matjazp, Thank you for your help, I'm not sure I would have tracked this down without that last suggestion to comment our the hidden visibility. Long story short it was my own fault! I built this site a long time ago and, in my naivety back then, added a protection line at the beginning of the main admin.php template that redirected front end users if they were to ever stumble on a real admin page using Fredi (the previous FE editor I was using). That line was redirecting front end users as soon as FEEL was trying to open an admin page. Oddly that wasn't happening with Fredi!?! Anyway, it's now working as expected and it was my fault not the module! Thanks again!

The more I look at this the more I suspect a permissions issue. It works perfectly for the Super User, just not for any other role. Checking the permissions for the 'editor' user like this, just before the call to FEEL to create the edit button: $perms = $user->getPermissions(); foreach ($perms as $perm) {echo $perm->title . " | ";} if ($page->editable()) {echo "Page is editable.";} I get this: "View pages | Edit pages | Delete pages | User can update profile/password | Page is editable." Every piece of evidence is suggesting it should work for the user but it just doesn't unless the user is a super user. ?

Hi @matjazp I'll do that as I'm really curious to see what's going on. It makes no sense that it works for the super user but not other user roles, even when they apparantly have the same permissions for page edit and creation.

Thank you @MarkE, I'll definitely take a look!

Hi Robin, Yes, that was my understanding too. I have been using that for quite a while without issue. The other thing I removed (which also maybe the cause but I don't think to) was the reference to the root page as $pages->get("/"). Maybe that was the 'root' cause?

Thanks for getting back to me @matjazp. That's a shame it's no longer supported. I tried your suggestion of commenting out the check lines in the the .module file and go straight to the line: var editForm = iframeContent.find('form#' + (mode === 'template-edit' ? 'ProcessTemplateEdit' : 'ProcessPageEdit')); But sadly that made no difference. In the .js file it seems to come down to this bit of code failing: if (editForm.length) { if (mode !== 'template-edit') mode = 'page-edit'; processPageEdit = true; } else { editForm = iframeContent.find('form#ProcessPageAdd'); if (editForm.length) { mode = 'page-add'; processPageAdd = true; } else { // close the modal processSaveRedirect = true; setTimeout(function () { $.magnificPopup.instance.close(); }, 100); return false; } } logging editForm.length shows a val of 0. So, the process arrives at this check but has no content to work with.

Finally found the issue! In the template set I was using the following in various places to retrieve the root page: $pages->get(1); In V3 that doesn't work. However, this does: $pages->get("id=1") All works as expected once those were swapped out.

Hi @benbyf If you right click on the image in the CKEditor field and select "Image Properties" then click on the quote marks icon you can edit Img Alt there.

I've done this for a couple clients. @mr-fan suggestion is the one I use to. One installation I've done works like this: Download Library Page (hidden, template = "downloads") - File 1 (template = "download", contains a file upload field called 'pdf_file' 'and sometimes other fields such as 'title' etc.) - File 2 (template = "download", as File 1) - File 3 etc. Then, create a "file_download" field on pages that need the files. This is a Page Reference field with parent page set to the Download Library page and the selector template="download". I use a Page Select Multiple type for this. In the page template you can then do this to get the files foreach ($page->file_download as $fd) { echo "<a href='{$fd->url}'>{$fd->title}</a> } Hope that helps.

This site launched earlier this year (2021) and was the product of about 9 months work between myself and the site owners. It was a ground-up build replacing a Wordpress site. Trinnov are based in France and design and manufacturer perhaps the finest cinema processors and room correction hardware in the world. The project features multi-language, product library, a dealer & distributor locator integrated pulling data from the company's BMS, a full featured blog, a site-wide file library for manuals etc. plus a host of other features and customisations including a contact form that emails to different destinations depending on a combination of product application and enquiry type. I hope you like it! https://www.trinnov.com/

Hi everyone, I'm hoping someone can help here... I've installed FEEL an added the following link in the template: $editArray = array( "class" => "btn btn-primary", "text" => "Edit This Listing <i class='fa fa-pencil' aria-hidden='true'></i>", "fields" => "title,colour,listing_type,vendor,product_type,price,price_original,bin_link,product_has_packing,product_has_manual,product_has_leads,body,page_image,product_image_1,product_image_2,product_image_3" ); echo $page->feel($editArray); When a SuperUser tried to edit or create a page then the system works as it should. However, when a non Super User tries the expected edit button appears and, when clicked, opens the Lightbox. However, at that point there are no fields presented, instead the blue spinner icon appears for a few seconds then the box closes and the page reloads with no page fields presented. PW version 3.0.165 FEEL version 1.4.0 UPDATE Digging into FrontEndLightbox.js it seems the mode is set to 'page-edit' but editForm.length == 0. Looking at the comment in the file this means that: In summary the user is logged, has edit and create permissions for the template in question but FEEL won't let them edit. Anyone see a similar issue or can point me in the right direction?? @tpr All help really appreciated!

Thanks. I might well try the disabling other themes idea moving forward.

Hi all, I've noticed that, when creating new users for clients, the chosen admin theme is not saved. For example, I create a new user select Reno or UIKit as the theme at point of creation and save. When logging in that user for the first time the admin theme is back to default. Changing it again and saving corrects this. Anyone else noticed this or is it a known bug at the moment? CMS V 3.0.156. Thanks!

I've spotted an issue which I really hope can be solved for AoS... Using Reno admin theme with AoS enabled and @ryan's ProDrafts module installed Reno hides the ProDrafts 'Live Preview' link in the admin header . The line in question is: <a href="/admin/page/prodrafts/edit/?id=1">Live Preview</a> See post here: https://processwire.com/talk/topic/25498-solved-prodrafts-reno-admin-theme-admin-on-steroids/ PW: 3.0.165 AOS: 2.0.21 ProDrafts: 0.0.8 Without AoS enabled: And with AoS Enabled Like I say, I really hope this is solvable as it's a very powerful combination! Thanks.

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.

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.

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?

I figured that was most probably the situation but good to know. Thank you.

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.

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.

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.

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!