MarkE

Starter
  • Content Count

    47
  • Joined

  • Last visited

Community Reputation

9 Neutral

About MarkE

  • Rank
    Jr. Member

Recent Profile Visitors

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

  1. MarkE

    Unfortunately, quite a few modules (including Form Builder) use modals.
  2. I've noticed that both the Reno and UIkit admin themes are responsive when accessing pages, but this doesn't apply to modals. If viewing on a relatively small screen (say iPhone 5), part of the modal is always off-screen. Is there a fully responsive theme anywhere? If not, what would be required to achieve it? Or is this a pipe dream? Thanks.
  3. It seems to me that access control in PW is powerful but quite complex. Does anyone know of a tutorial/blog etc. that covers these complexities. I particular, how to make sure that the end result achieves the required access control. From what I have learned so far, a number of things interact: • Whether a page is published, unpublished or hidden • The access given to users of a template • Field level access – both global and as over-ridden in a template • Whether or not a template has an associated php template file • The output formatting of a page, set in a php script (false can disable field-level access controls) These need to be considered in combination to determine what is the actual level of access in any situation. Is there any way of getting an overview of all this? For example, if there is no guest access to a template then that restriction will also apply to any API invoked by a guest action which requires access to a page instance of that template. The only way I can see to allow API access but to prevent direct access is to allow guest access to the template, but not provide a template php file. Is this secure? Also, if fields have restricted access (e.g. no guest access), then any API invoked from the front-end (including webhooks) will not be allowed to see the contents (this is achieved by blanking the contents in formatting). Over-riding this can be achieved either by setting the relevant option on the Access tab of the restricted fields, or by turning off output formatting for the affected page just before accessing it (e.g. $p->of(false); ). See discussion at
  4. MarkE

    Yes. I just mentioned it because it is very big and full of things like <span class="tracy-dump-indent"> | | </span><span class="tracy-dump-key">fuel</span> <span class="tracy-dump-visibility">protected</span> => <span class="tracy-dump-object" ... I have no idea what it does.
  5. MarkE

    ... just having a root around - I seem to have 12mb session file - is that normal?
  6. MarkE

    It seems to be all pages. It was fixed after a reboot last time. I'm inclined to blame windoze - that's the usual source of my problems. Meanwhile, I'll turn Tracy off until I need it then reboot again...
  7. MarkE

    Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 33764184 bytes) in M:\xampp\apps\processwire\htdocs\site-ncog\modules\TracyDebugger\tracy-master\src\Tracy\Helpers.php on line 133 Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 10530816 bytes) in Unknown on line 0
  8. MarkE

    Thanks, but as you say - it ought not to be necessary. Anyway, today it is working
  9. MarkE

    It seems to make no difference which panels are enabled (or even none). However, unchecking the "Show debug bar" removes the error from the front end or back end accordingly.
  10. MarkE

    Just got this error message: Fatal Error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 25956352 bytes) (line 27 of M:\xampp\apps\processwire\htdocs\site-ncog\modules\TracyDebugger\tracy-master\src\Tracy\assets\Bar\panels.phtml) Any idea what might have caused it or how to fix it? I uninstalled the module and the error went away. After re-installing it, the error came back. The message at the bottom of the screen reads: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 10563584 bytes) in Unknown on line 0
  11. MarkE

    Maybe I am missing something, but I do find it hard to get an overview of what data a given user can access, including via the API. Having fixed the problem in the OP, a different part of the same code then gave problems: When run from the backend this works fine and finds all the relevant children. However, the webhook, coming in as guest returns an empty array. I checked and removed any access restrictions with no luck. I also changed the code to this (i.e. removed the selectors): if (wire()->session->webhook) echo('This mandate details - Title: ' . $this->title . ' Id: ' . $this->mandateId . ' Num of children = ' . $this->numChildren . '<br/>'); $osCollections = $this->children; // was find("template=Collection, paymentStatus!=paid_out"); if (wire()->session->webhook) echo('Number of collections found = ' . $osCollections->count() . '<br/>'); This resulted in the following response to the webhook: This mandate details - Title: Mandate Id: MD0004TV8F2YP3 Num of children = 24<br/>Number of collections found = 0<br/> So $this->numChildren is correct, but $this->children is empty FWIW, here is the print_r output immediately afterwards: ( [hooks] => Array ( [PageArray::render] => MarkupPageArray->renderPageArray() in MarkupPageArray.module [PaginatedArray::renderPager] => MarkupPageArray->renderPager() in MarkupPageArray.module ) [count] => 0 [total] => 0 [start] => 0 [limit] => 0 [selectors] => parent_id=2661, sort=sort, status<1024 )
  12. I've been implementing the ideas in the excellent tutorial: https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ I really like having a class to mirror certain important templates as it makes organising and structuring code more intuitive (to me) and avoids the need for many hooks. A key aspect of this is the ability to define a Page Class Name for a template, so that any pages with that template will automatically have the correct PHP class. To do this, you need to enable the advanced mode in the site/config.php and then edit the event template in the backend, under the system tab. However, I have a couple of issues that trouble me: The system tab carries a warning "Please note that all of these system settings are intended for ProcessWire system development (not site development). Use them at your own risk." Why is this? I assume that the term "ProcessWire system development" is intended to mean website apps (I am building a club membership site) as opposed to simple websites, and is not referring to the development of the Processwire system itself, but why the health warning? Is it still beta? What are the risks? The behaviour is not quite as I expected. If you create a new page with a template which has a pageClass then a hook after "save" shows the following: after entering the new page title and name and saving the "Add New" form, the page content is displayed. The page has presumably been saved as the "after" hook executes and shows that the template and custom pageClass have been assigned to the saved page, but the PHP class is still shown as Page, not the custom class. after the second save (of the page content), the hook shows that the PHP class is correct - the same as the custom pageClass. Is the behaviour in (2) intentional (and if so, why)? If not, is it a bug, or just unavoidable for some reason? (I also note, BTW, that the page id seems to be 0 after the first "save").
  13. MarkE

    Thanks for that. Reading the explanation (i.e. that the contents are masked by output formatting), I wonder whether it is better to over-ride this for the field in general or just in the specific use case (the webhook). I tried inserting $os->of(false); and the problem was fixed It seems to me that if there is only one use case to fix, this approach may be better than generally allowing the API access. However, it's nice to have the choice and this episode once again proves how well-designed PW is (even if its features are not immediately apparent to relative newbies like me!).
  14. MarkE

    ... so I disabled the direct running from the webhook and left the save hook in place. The idea being that when the webhook updated the page, the save hook would then run. Which it did, but still exhibiting the same problem... ... might it be something to do with whether the method gets initiated from the front end (webhook) or back end?.. ... Aha! - looks like the missing fields have additional access restrictions. The webhook, coming from the front end is treated as "guest" so the fields are not visible to it. So I think I may have found the cause - just need to find a solution now
  15. MarkE

    Hmm. I moved the code into a new method so that I could invoke it from the browser via a save hook or externally via a webhook. If I invoke it from the browser it works OK, but if it runs from the webhook then the problem persists. And I can't see how Tracy can help in the webhook case (which is why I dumped the vars to the page body).