NikNak

Members
  • Content count

    72
  • Joined

  • Last visited

Community Reputation

15 Good

About NikNak

  • Rank
    Full Member

Profile Information

  • Gender
    Not Telling
  1. 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
  2. Thanks Robin. Understood about superuser, and agreed - never let a client have superuser access. Kind regards Nik
  3. Awesome - thank you so much. That is exactly what I needed. Kind regards Nik
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. Hi again, I'm now getting an error about needing to upgrade to TLS 1.2 - on both my MAMP and on my live server - but this is a Stripe security thing for me to look into. Thanks for the help Kind r Nik
  14. Yes I did Apeisa. And then tried with the master branch and got the same trouble (after replacing the Stripe Lib files). I've just tried again with the latest PW3 and PaymentModule-PW3 and PaymentStripe-PW3. I've selected Stripe as the active payment module in the base module and also tried selecting both Stripe and Payment module. This was using Wamp and PHP 5.4.4. I tried on a live server with PHP 5.6 and got the same result. By the way - I am using the '?step=process' in the URL. Error: Class 'ProcessWire\Stripe' not found (line 28 of /..blah../site/modules/PaymentStripe-PW3/PaymentStripe.module) Kind Regards Nik
  15. I've been trying to get this to work on a fresh install of PW 3.0.36 and the PW3 versions of Payment base + PaymentStripe When trying your example scritp, it throws an error on line 28 of the paymentStripe.module Stripe::setApiKey($this->secretKey); Error: Class 'Stripe' not found (line 28 of /...blah..../modules/PaymentStripe/PaymentStripe.module) I tried the older versions of the modules but hit the same problem. Kind regards