Jump to content

MarkE

Members
  • Posts

    425
  • Joined

  • Last visited

  • Days Won

    5

MarkE last won the day on April 8

MarkE had the most liked content!

Recent Profile Visitors

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

MarkE's Achievements

Sr. Member

Sr. Member (5/6)

168

Reputation

  1. It can really help to use Tracy Debugger to debug issues like this
  2. 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?
  3. Why not just use the browser features with @media print in the css?
  4. I didn’t realise star counts were used in this way. anyway, now 699 😀 Good idea.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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?).
  10. 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.
  11. 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().
  12. 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.
  13. 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.
  14. 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).
×
×
  • Create New...