Jump to content

NikNak

Members
  • Content Count

    75
  • Joined

  • Last visited

Community Reputation

17 Good

About NikNak

  • Rank
    Full Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. For anyone having a similar issue, I finally resolved the issue after reading this post... https://processwire.com/blog/posts/pw-3.0.111/ Adding: $event->name = $pages->names()->uniquePageName($event->name) before: $event->save(); sorted it. Many thanks Nik
  2. Thanks for the suggestions... It isn't a browser caching issue for sure. The module Bernhard kindly suggested, just shows that it redirects to itself endlessly (and not back and forth between different urls). For a specific problem page, I have gone into the db and removed all page path history entries for that page id (rather than download modules), but the problem isn't resolved. This leads me to another possibility... The pages here are named with the page id (ie /whats-on/past-events/5336/ is the full path). Looking at how you can now use any shortcode url that features the page's id, I wonder if pw is seeing the pages name, and seeing it as a shortcode, and redirecting it to the same url. In which case, why is the problem resolved by me manually moving the page to a different parent and then back again, in the page tree, rather than doing it via the API? (However, I noticed is that my page moving script doesn't create a corresponding entry in the page path history.) My tests seem to be inconclusive... some pages moved by my script cause redirect errors and some don't, despite being the same types of page and undergoing the same process. V confused... as this was all working fine for a couple of years. Many thanks Nik
  3. Hi This script for moving past events to a different parent has been working fine for a few years, but in the last few months it has resulted in the moved pages having re-direct errors on the front end (ERR_TOO_MANY_REDIRECTS). If I move the pages manually it is fine... so I am wondering what is causing this now. Would I be correct in assuming this is something to do with Page Path History. (I have updated the wire folder a couple of times and I am currently on 3.0.127 Dev.) Any help gratefully received. $old_events = $pages->find("template=event, parent=1039, include=all"); foreach($old_events as $event) { $event->of(false); $date = date("Ymd", $event->get("date_end|date_start")); if ($today > $date) { $event->parent=2388; $event->save(); } $event->of(true); }
  4. Without this module, I am now struggling to find a way to get an image cropped to a particular ratio, that retains the full resolution of the original image. ie - have a cropped image that is as good as it can be at a particular ratio. From that master, i would then make variants. Using CropableImage3 this is not possible - as all defined crops are pixel based rather than ratio based - and not dependent on the original size image. This therefore restricts the flexibility of generating a subsequent scaling of the image from the best master possible. Horst's suggestion of uploading a large image to start with and cropping it to the right proportion at high res and then scaling, is impractical in day to day situations for my use, as you can't always impose that kind of restriction on your client's images. I had hoped that if I turned upscaling off, then perhaps I would be able to set a very large crop setting, and the cropping would just be made as large as possible. Anybody managed to find alternatives to the conundrum this has left, if you want to retain maximum flexibility in the automated scalings of your images. ? Cheers Nik
  5. Thanks Robin. Understood about superuser, and agreed - never let a client have superuser access. Kind regards Nik
  6. Awesome - thank you so much. That is exactly what I needed. Kind regards Nik
  7. Thanks - but if you want to get the id without hard coding it. In other scenarios you use the $page->id which returns the id of the current page being edited. How do you return the id of the current user being edited? Kind regards Nik
  8. Hi again If you are editing a users page at a url like "/admin/access/users/edit/?id=3718" I was trying to access the id 3718, so I could find other pages related to this id. I wasn't trying to get the current $user Sorry for not being clear. Kind regards Nik
  9. Thanks Robin - I was indeed considering this. The RuntimeMarkup module doesn't scope the current $user being edited though - it only works on normal pages. So I think this counts this option out. I didn't realise that $page wouldn't return the current user being edited. Kind regards Nik
  10. Thanks Kongondo - it's just me being thicker than usual - no problem with the description ;-) I assume this means that you cannot self reference fields on a $user page being edited. EDIT: The below solves what I was trying to do - thanks Kongondo $process = wire('process'); $u = $process->getPage(); $id = $u->id; return $id;// will return 40 for guest, 41 for superuser, etc... //return $process->className();// would return ProcessUser. Useful to know if you are using the field elsewhere and want to do different things based on context // return $u->email;// etc... Kind regards Nik
  11. I've done some more testing. The module is working on normal pages whereas I was initially trying it out on $user pages, where it failed. Kind regards Nik
  12. Thanks. I tried the simplest of things, and namespaced it too, but couldnt get any output other than an error. Not to worry - I'll do more testing. Many thanks Nik
  13. Hi Robin Thanks for your hard work on this. One thing I noticed was that if you do not restrict the actions to a role, then none of the restrictions are applied at all. For example, I want to hide the trash buttons for everyone, including superusers, but by not selecting a restriction by role, none of the modifications are made for anyone, and all the buttons and functionality is in place as if you weren't using the module. Kind regards Nik
  14. Hi Kongondo I have tried your master and dev versions with PW 3.0.36 and only get errors. Using your example code or something simple like 'return $page->parent->title;' gets the resulting error: Only strings and integers should be returned by your custom code! Check if your code is valid. 'return "hello";' works - but thats not so useful. I am running php 5.4.4 - might that be the issue? Kind regards Nik
  15. EDIT: The LimitPageTable module seems to offer the ability to remove the trash icon from PageTable. I'd still be interested if anyone thinks this approach could be improved though Hi I'm looking into using Stripe to take membership payments for a society. ie - once per year, so not lots of transactions. The process all works fine, but I am not sure of the best way to structure storing the transactions records in PW. My initial thought was to create a pageTable for payments and add this to the $user template. So each time a payment is made, a new page is created (in a payments folder under admin section) that logs the transaction, and this is then added to the pageTable list in the $user admin page via the API. This way, all transactions for the user are easily visible to the admin. All adjustments to these records would need to be by the API and not by manual editing. I like the idea of each transaction being a page. The trouble with this method, is that I do not want the administrators to be able to remove these entries from the pageTable, as they can currently via the trash icon. I can set the actual transaction page itself to be un-editable - but this doesn't stop its removal from a pageTable. If you set the visibility of the pageTable field so it is un-editable (locked), it then only shows you a list of page id's (ie, no pageTable layout) - so the listing becomes meaningless to the administrator. So my question is.... Does this approach seem to make most sense (if I can remove the trash icons in the pageTable listing) - or should I try a different approach for storing this data. It needs to make life easy for the administrators of the site. Many thanks Nik
×
×
  • Create New...