Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by psy

  1. [solved] And so it happened again but this time it was same but different. Two weeks ago, all worked perfectly according to the LRP recipes. Today the fe user wouldn't log in??? I could login to the protected pages as superuser. Checked all the advice given in above and other posts. I had not changed anything on the site and nothing recorded in the logs, Tracy Debugger etc. The only hint was in the Chrome browser dev tools that the LoginRegisterPro init() function wasn't loaded. I'm using MarkupRegions and on the latest versions of PW and LRP and PHP 8.1 My bad, I had in my template code: <region id="regHeadCSS" pw-append> <?php $loginRegister->renderStyles() ?> <?php $loginRegister->renderScripts() ?> </region> Should have been: <region id="regHeadCSS" pw-append> <?= $loginRegister->renderStyles() ?> <?= $loginRegister->renderScripts() ?> </region> OR: <region id="regHeadCSS" pw-append> <?php echo $loginRegister->renderStyles() ?> <?php echo $loginRegister->renderScripts() ?> </region> Still don't understand why it worked originally but all's well that ends well
  2. Try in your template: <?php // assuming 'matrix' is the name of your repeater matrix field if($page->hasField('matrix') && $page->matrix->count > 0) : echo $page->render('matrix'); else: echo $page->body; endif; ?>
  3. I'm familiar with $files->render and use it reguarly to include snippets in templates, passing PW vars to the snippet file. Came across a head-scratcher today. In my included snippet, I pass a PW WireArray as a var. I tried lots of variations in various browsers, all with the same result: When logged in as admin and viewing page, everything displays correctly When not logged in, ie guest user, only the included snippet HTML wrapper displayed on the frontend, not the output logic generated within the snippet The page has no viewing restrictions and the file permissions on the server all look good. Using: ProcessWire 3.0.234 PHP 8.1 Suggestions on how to fix or pointers to the documentation I may have missed, welcome. TIA psy Solution: The $files->render call was a red herring. The problem arose with my $pages->find selector. The requested page template is quite complex with a page reference field within a repeater and the parent page hidden from lists and searches. Seems PW struggled with all the complexities involving the repeater field filtering on a page reference field, especially when the page's parent was hidden, and user permissions. In one variation, the selector returned all the correct page ids as a string, despite not specifying same in the selector. Finally got it to work by making life easier for PW, ie: <?php $currency = 'USD'; $things = $pages->find("template=thing, page_thing_type.id=1040"); // get all the published pages with a template of 'thing' and page reference field id of 1040 $things->filter("rptr_currency_and_msrp.page_currency.title=$currency" ); // reduce the PageArray based on the repeater field's page reference field's title $thingItems = $page->getMythings($things, $currency); // do stuff with the filtered PageArray in a page class $files->render('inc/my_things',['lines' => $thingItems]);?> Now all displaying correctly for guest users and tested in multiple browsers.
  4. ChatGPT found MutationObserver and helped me solve a similar issue, ie modifying ajax-loaded page content on a 3rd party SaaS platform πŸ™‚
  5. I developed at multi-lang site in Australia with the default lang as English UK. One of the other lang choices was English US. It all worked perfectly until the live site was moved to a US host. Now the lang switcher (as per documentation) gets confused between the two. It appears to default to English UK but in reality is defaulting to English US. When using the lang switcher, it even gets the lang names & flags mixed up. It's also breaking some javascript. When the js tries to identify the English US lang via the URL, it simply cannot with the WireException "Unknown language". I've tried changing the SET_LOCAL and HTML to en_us with no effect. Other langs on the site work perfectly. Any and all suggestions on how to fix most welcome Solution: There were 3 things causing problems: 1. Typo from me in the default language title field. πŸ€¦β€β™€οΈ This resulted in the wrong language name displaying in the language switcher 2. My language names for English US and English UK did not match the name values in @Sebi fab AppApiPage.module resulting in "Language not found" for en-us. English UK being the default wasn't affected. Changed them to match, ie: $languageCodes = [ // 'en-gb' => 'english-united-kingdom', 'en-gb' => 'english-uk', // 'en-us' => 'english-united States', 'en-us' => 'english-us', ] 3. In @Wanze great SeoMaestro module, line 157 of the PageFieldValue.php class assumes that the language names are the language codes, eg en-us instead of English US resulting in incorrect alternate hreflang meta tags. I changed it to: // $code = $language->isDefault() ? $defaultLang : $language->name; $code = $language->isDefault() ? $defaultLang : $this->wire('pages')->get(1)->getLanguageValue($language, 'name');
  6. Thank you all. Great advice as always. πŸ™‚ Obviously didn't explain my scenario clearly. I have a page template that includes an inline <script> that uses js fetch to connect to the AppApi module. Works great. The authorisation token is hardcoded to the AppApi token for dev purposes. Not good for real world. The site doesn't use VITE or Heroku or other platforms. It's plain old JS. I would like to: Change the inline script to a js file called in the template Hide the AppApi PHP session token from the browser output <?php ?> <script> const MyApiCall = async (url) => { let connect = await fetch(url, { method: 'GET', credentials: 'same-origin', mode: 'same-origin', headers: { 'x-api-key': 'is3434343axxxxp3662OB', } }) let result = await connect.json() return result } </script> I'm investigating https://www.npmjs.com/package/dotenv-webpack and struggling. @Sebi are you able to help? While my case includes AppApi, am sure others must have similar issues connecting PW via JS to endpoints that require (secure) authorisation in the http header. Cheers @psy
  7. I've built a PW web app that integrates as a plugin to a SaaS app and it's working really well though I have a bit of final bug-ironing to do. One thing I've avoided addressing is implementing node dotenv. There is a javascript api method that calls on the PW AppApi module. It needs the AppApi token. The call is behind numerous logins, permission checks etc. However, for safety's sake, I would like the token to not be visible in the page source. Have any of you implemented node modules in PW? How did you do it and where did you put the .env file? Is there an alternative to node to achieve the same result? I've created a custom module to do many of the functions - should I put reference to node in the module's composer.json? Thanks in advance Cheers psy
  8. Untried, but have you experimented with font-size: clamp(min, optimum, max) and wrap: no-wrap in the CSS?
  9. @bernhard Yes, I was bit off topic. πŸ€¦β€β™€οΈ Apologies. And yes, I did find the whole translation system confusing and/or tedious. Haven't had to translate modules but when I do, I'll use your RockLanguage module πŸ™‚
  10. Learnt the hard way that translations were a nightmare, both backend and frontend. Exuberant client wanted site in 15+ languages. There was a frontend language converter process module that relied on InputfieldCKeditor. Didn't work for me as the new preferred HTML inputfield uses TinyMCE. So I did a thing... Built my own module to convert all page active multilang fields via Google Cloud Translate. Works well and admin has the choice to enable/disable on page save. But currently has client-specific limitations and handling things like repeaters requires PW knowledge. It's frontend only. Happy to collaborate with another PW dev to make it viable for all and add to Download Modules. Let me know if you're interested.
  11. @Denis Schultz so that's all I need? Just a header?
  12. I've set up a page to receive responses to events from another app's webhooks and it's working fine. The sending server needs to receive a http response of 200 before retrying. When the set number of retries fail, the web hook will be disabled by the sending host. From what I've read, often the 200 response will be returned auto-magically by the receiving host (in this case, PW). Doesn't appear to be happening. The sending host keeps retrying. I'd like to deliberately send the success response back to the sending host and I suspect https://processwire.com/api/ref/wire-http/send-status-header/ will be in the mix somewhere. Just not sure how to set it up. So far I have: <?php namespace ProcessWire: $phpInput = @file_get_contents("php://input"); $payload = json_decode($phpInput); if(!$payload->scope) exit(); // not valid BC webhook // need to send the 200 response here to let BC know the response was received successfully Guidance much appreciated. Cheers psy
  13. Thank you for investigating @wbmnfktr πŸ™‚ I had tried re-saving in different formats without success. It was only when I made one image bigger and it uploaded that I realised the file size was triggering the issue. @netcarver's suggestion of a ModSecurity issue with the web host was 100% and nothing to do with PW.
  14. @netcarver Using PW 3.0.210 and nothing special in .htaccess other than ProCache directives, https only and <IfModule mod_mime.c> AddType image/webp .webp </IfModule> Strange that it only happens on small images. No problem at all on larger image file sizes. I changed the default image quality from 90% to 100% in case that made the file invalid but no difference. All PHP image processing modules seem OK. As for ModSecurity, yes it's on a shared host that has ModSecurity. That's been a nightmare on many occasions for other things. I have the web host on speed dial. Good call to check that one.
  15. There are many forum topics and suggested solutions to problems uploading images in PW admin. I've read all I can find but none address the problem I'm experiencing. It's consistent and repeatable. I have an image field in my template (duh!) and I can successfully upload any images with an approved image file type that has a file size over 10kb. Any images (png or jpg in this case) with file size of <10kb fail with the following error: I have even taken one of the small images, given it a bigger canvas in Photoshop, converted to PNG/JPG and successfully uploaded it. I could also hack it and make all my images bigger then use the api/image variations to reduce them on frontend output but that's not the point and a lot of unnecessary effort and wasted disk storage. Suggestions on how to fix the underlying problem most welcome. TIA Solved Thanks @netcarver for suggesting it may be a ModSecurity issue. Nailed it. Web host whitelisted my IP from their (obscure) rule and the uploads worked perfectly πŸ™‚
  16. Nothing in this post since 2020 then a client got this today... Similar to above comments, I'm convinced it's just a nasty extortion threat and should be ignored. Form is in Formbuilder iframe and full of all ProcessWire & FB sanity checks. Site is functional and no obvious hacks. Told client that if it was real, they should feel privileged to be the first ever recognised PW hack victim. Also feeling a bit chuffed that this little, local Aussie site was found on the global hacker network.
  17. OMG solved! 🀞 When I was digging into wire/core/WireHTTP I think the file got corrupted, maybe during an upload to my dev server (yes, still staging) Replaced it with a new copy and site is working again @netcarver truly appreciate your help and patience.
  18. @netcarver I tried that on the frontend and it worked but now every time it has to wire a new page, or in admin perform some http task, it fails. My error logs are filling up fast
  19. @ryan any ideas? Nothing that involves https works, eg admin 'Save' functions, frontend redirects.
  20. Have uninstalled: TracyDebugger LoginRegisterPro (not used anyway) Very few other modules in use and still the error, admin & fe 😞
  21. @netcarver Thanks for your input. Site doesn't use any hooks Searched Google, forum but not repo. Will do so now. There was an old post that was vaguely similar but didn't have an answer. See link below Turning off the error may hide the error message but, you're right, it will totally obscute the real issue.
  22. I've been working on a a new site for weeks. $session did it's normal, wonderful stuff until today when it didn't - boom!!! $session now occasionally holds vars from one page to another. The killer is $session->location or $session->redirect. Before redirecting, the page crashes with: I went back to basics with the default theme: Using ProcessWire 3.0.212 dev PHP v8.1 (tried 7.4 & 8.0 too) Error occurs in Chrome & Firefox Editing modules, eg turning TracyDebugger on/off also triggers the problem Error occurs in front and back end. Often, clicking on a link to a different page clears the error but $session still screwy. Have no idea why PW suddenly stopped correctly wiring $session. Is this a bug? Am I doing something wrong? Help & ideas on how to fix gratefully accepted. Solved: Upload a fresh copy of WireHTTP to my server. Previous version may have been corrupted in transit.
  23. Solved! Instead of re-using the same $http object I'd used for multiple previous GET requests, I created a new one, ie $postHttp. Postman had "no-cache" as a header.. Thanks again for the tip @netcarver
  • Create New...