Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by MarkE

  1. For the benefit of anyone else wanting their module to be comptible with earlier versions of PW, I suggest you use: $tab1 = $this->wire(new InputfieldWrapper()); not $tab1 = $modules->get('InputfieldWrapper'); Also, do not use plain $tab1 = new InputfieldWrapper(); as the column widths of the contained inputfields will not work properly. Per the PW coding style guide:
  2. Ta. The site is on 3.0.165. @Robin S's module is on 170. Hopefully a new core is out soon and I will move to that. However, I am using this in my ProcessDbMigrate module (full alpha release shortly.... 😁) and I have tried to make that compatible with 3.0.148 (even pre page class days). I'm not sure what the best policy is regarding the backwards compatibility of new modules.
  3. Yes. If I put the same code as the above into the Tracy console on my system, it returns null.
  4. InputfieldWrapper is not a module AFAIK - at least in my v 3.0.165 new InputfieldWrapper() works ok though.
  5. If you find a solution to a question you ask, the best thing is to post the answer for the benefit of others and add SOLVED to the title.
  6. If I split the path into its segments then PW gets it just fine: Odd!
  7. I'm trying to make my ProcessDbMigrate module operate in pre-PW3.0.152 versions, but I've hit a really weird issue which is best illustrated in the following: As you can see, I obtain the path of the current page in the Tracy console, then attempt to find it in $pages->get() but it yields a null page. The same code works fine in the parent page and in a similar page PW3.0.165. Any ideas what might be causing this?
  8. It can really help to use Tracy Debugger to debug issues like this
  9. Is your echo showing the file? I would have used: $directory = $config->paths->assets . "files/1048/"; // files uploaded here via ftp or maybe wire()->config ... depending on context Is 'file' the name of your files field?
  10. Why not just use the browser features with @media print in the css?
  11. I didn’t realise star counts were used in this way. anyway, now 699 😀 Good idea.
  12. Depending on what you are trying to achieve, one approach is to have a page ref field in the category template to ref back to the recipes, then use the ConnectPageFields module to keep them in sync. That then gives you lots of options for viewing and updating.
  13. The approach I actually use for a web app is to start with a class diagram. The classes, properties and methods then become the templates, fields and methods (roughly speaking) in PW, where the methods are added to the TemplatenamePage class. For many<->many relationships which don’t hold data, I often use ConnectPageFields by @Robin S - it’s a really useful module. Looking at the app, I see that of the approximately 50 templates, around 30 have associated Page Classes, so I don’t think that number could be reduced much. I could probably have got away with fewer fields by more intelligent re-use or if I had purchased ProFields. No. I wasn’t aware of it when I built that app. I did spot it later and looking at it again now, I realise that it may have wider application than I first thought. I’m not sure it would have saved a lot for the app in question, though.
  14. Sorry to hear that @Cybermano. I’m away from my desk (and IDE) for a week, so can’t look into it just now. Give me a prod next week if it’s still not working.
  15. I have a web app with over 50 templates and over 150 fields (holiday cottage booking system). I don’t find that a problem, although there are not many users. I use page classes extensively with the templates as I find that is the best way of handling the business logic. Process modules for most of the admin user views. This is mostly a back-end admin system. The front-end public website is a separate PW instance with its own (smaller number) of templates and fields, interfacing the admin system via an availability calendar. There may have been better ways of doing it, as I am still learning about PW, but I find this a manageable approach.
  16. Thanks for your help @Robin S I sort-of get it: $page->save(['noHooks' => true]); just prevents hooks running on Page::save - it does not prevent downstream hooks on Pages::save etc. My hook was on before Pages::save as advised elsewhere on this forum. See image below (ready() is needed to load the hook, debug_backtrace is running in the beforeSaveThis hook on Pages::save). However, if I try $pages->save($page, ['noHooks' => true]); then the hook on Pages::save still runs! EDIT: Ironically, this still only prevents hooks running on Page::save but $pages->___save($page, ['noHooks' => true]); works, as does plain $pages->___save($page); This all seems pretty confusing and inconsistent though (at least to my little brain). Perhaps @ryanor someone with greater knowledge than me could shed some more light on this (and clarify the documentation?).
  17. It was. The code was correct. That's funny - I'll investigate further and post any info. I did a debug_backtrace in Tracy which clearly showed the hook being called despite 'noHooks' - maybe there was something else interfering.
  18. I had been struggling to implement the 'noHooks' option in $page->save(). $page->save(['noHooks => true']) does not seem to work, nor does $pages->save($p, ['noHooks => true']) Then I found the following documentation in wire/core/Pages.php: * - `noHooks` (boolean): Prevent before/after save hooks (default=false), please also use $pages->___save() for call. So $pages->___save($p, ['noHooks => true']) does work. Just thought I'd mention it as it is a bit buried (and a bit unusual). Also, I'm not sure if it is possible to use the noHooks option with $page->save().
  19. I have a membership site with recurring payments. It uses GoCardless (direct debits) - not sure what their coverage is for Austria. The API is excellent. It is cheaper than credit cards and arguably more secure. The way I do it is for the member to authorise a mandate. My site then collects on the due dates using that mandate, so this is technically a series of one-off payments, but I think you can also set it up so that GoCardless will charge automatically on a recurring basis.
  20. Good idea. I used it as a shortcut. I’m just completing the planned functionality of my module, after which some tidying up will follow, so I’ll take the opportunity then.
  21. It may not be a 'proper' fieldtype, but it is very useful and a key part of my ProcessDbMigrate module. However, I have a very slight problem which is really puzzling me. My module gets data from the database and exports to .json files (among other things). I use the standard Field::getExportData() for getting field data. The curious thing is, for certain fields, I get a different result from getExportData() depending on whether it is called from inside my module or from a RuntimeOnly script. For example, the field phits (from the Page Hit Counter module) has visibility 'hidden' (i.e. collapsed = 4). Calling getExportData() from my module (see code below) returns the correct result. $field = $this->wire()->fields->get('phits'); bd($field->getExportData(), 'getExportData in module class'); Calling it from with a RuntimeOnly script (see code below) returns collapsed = 0. $field = $fields->get('phits'); bd($field->getExportData(), 'getExportData in RuntimeOnly'); See pic below for the Tracy debug: Examining the situation in a bit more detail shows the following: Field::getExportData() calls Fieldtype::exportConfigData() viz. $typeData = $this->type->exportConfigData($this, $data); and then merges the data, viz. $data = array_merge($data, $typeData); Fieldtype::exportConfigData() calls Inputfield::exportConfigData(), viz. $data = $inputfield->exportConfigData($data); It is the second call which returns collapsed = 0 rather than collapsed = 4. It is arguable that the array_merge should be reversed - i.e. $data = array_merge($typeData, $data); so that the generic data does not over-ride the specific - not that this really helps, as I have no idea what is causing the problem in the first place. Any ideas? In the meantime, I guess I will need to do a work-round by trying to move the code out of the RuntimeOnly script (note that the actual code I am using is much broader than the 'phits' snippet above - I have just used that to illustrate the problem).
  22. Now solved. For the benefit of others, you need to set the sort property of the repeater rather than use a custom property. i.e. for each repeater page: $subPage->sort = $j; // where $j is the required sort index $subPage->save(); then after all 'subPages' have been set: $page->$repeaterName->sort('sort'); and save the page.
  23. I am editing repeater field subpages for a page using the API. As I edit each one, I assign it a sequence. I then sort them by that sequence, viz: $page->$repeaterName->sort('sequence'); When I look at the page in the UI, the sort seems to have worked OK. However, when I then process the repeaters, the processing happens in the original sequence, not my sort order. Inspecting the page with Tracy (see below), it is clear that the array keys retain the original order even though the displayed order is correct - and it is the array keys that determine the processing sequence. Any ideas how I fix this?
  • Create New...