Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/28/2022 in all areas

  1. Preventing a page from being moved is not necessarily a straightforward matter of trapping the change in a save hook in the same way as a page edit. A problem occurs if the page is only to be 'blocked' conditionally - when the page path is in some given array, for example. In hooking before page save, the page path is the new page path after the move, rather than before it, so you need to do something like this: // .... In the before page:saveReady hook // $page is the page :) The code below operates when (isset($page->parentPrevious) && $object->parentPrevious != $object->parent) $name = $page->parentPrevious->path . $page->name . '/'; // need the path before it was moved if(in_array($name, $blockedNames)) { // $blockedNames are the ones where we don't want moves // Because this hook operates after the move, we need to reverse the move $page->parent = $page->parentPrevious; // Alternatively, to completely stop the save //$event->replace = true; //$event->return = false; } //... rest of hook This prevents the page being moved, both in the page hierarchy (by dragging) or in the page editor by changing the parent in the settings tab. It is also possible to hook before Page:moveable with something like this /** @var Page $page */ $page = $event->object; $moveable = $event->return; // ... code to set $moveable to false if conditions met $event->return = $moveable; Interestingly, the (not documented?) moveable method is created as a hook by PagePermissions and so is hookable. However, this method appears to catch only the situation where the move is effected by dragging the page in the tree, not when the parent is changed in the settings.
    2 points
  2. When you tested in the fresh PW install, did you also copy all the code in site/templates, site/ready.php, site/init.php from the affected install to the fresh install? Or in other words, can you rule out with certainty that template or hook code might be responsible, especially hooks? I once stumbled over a similar or at least related problem, where all PW queries in the page tree, that are done via ajax returned an error and pages tree stopped working. Then I discovered that an addHookBefore('ProcessHome::execute', $this, 'rootPage') was responsible. In my hook function 'rootPage', I had to do an if($this->config->ajax) return; This is just what came to my mind when reading about your problem. Did you follow the "Optimize" link and which table is this warning referring to? How many entries are there in the DB table "pages"? I can totally understand your frustration and think we all have been there at some point. But, at least for me, all those situations were resolvable in the end. Even if we cannot charge our clients for the effort we put in resolving those issues, these situations can help us to learn and get better at what we are doing.
    2 points
  3. Looking for someone to link a website to an (AWS) S3 server to get videos via presigned URLs. The website is an archive and each archive item (page) is linked to a video. Things to do: 1. You will get VPN-connections to the website and the S3-server 2. Setup a Bucket on the Server 3. Uplaod a Test-File (mp4 file) 4. Link video page to the mp4 test file on S3-server via AWS SDK for PHP
    1 point
  4. Hey @Mats, In this case you're setting view directly on the View object, so you should read it from there as well: // in controller $this->view->setView('buy'); // in view file echo $this->getView();
    1 point
  5. Moderator note: @ngrmm I understand that this thread is aimed at German speaking developers, but to keep the moderation manageable, we only allow English in the forum. Could you please edit the content of your post to be in English?
    1 point
  6. I have been trying to add some hooks to prevent pages from being moved in certain circumstances. It seems (to me) that this is not entirely straightforward. First off, just a simple hook before the page save does not always work. In my use case, the 'circumstances' are when the page path is in some given array. In hooking before page save, the page path is the new page path after the move, rather than before it, so I need to do something like this: // .... In the before page:saveReady hook // $page is the page :) The code below operates when (isset($page->parentPrevious) && $object->parentPrevious != $object->parent) $name = $page->parentPrevious->path . $page->name . '/'; // need the path before it was moved // Because this hook operates after the move, we need to reverse the move if(in_array($name, $blockedNames)) { // $blockedNames are the ones where we don't want moves $page->parent = $page->parentPrevious; $page->of(false); $this->wire()->session->set('bypassSaveHook', true); // to prevent loops $page->save(); $this->wire()->session->remove('bypassSaveHook'); } //... rest of hook This prevents the page being moved, both in the page hierarchy (by dragging) or in the page editor by changing the parent in the settings tab. I also tried hooking before Page:moveable with something like this /** @var Page $page */ $page = $event->object; $moveable = $event->return; // ... code to set $moveable to false if conditions met $event->return = $moveable; Interestingly, the (not documented?) moveable method is created as a hook by PagePermissions and so is hookable. However, this appears to catch only the situation where the move is effected by dragging the page in the tree, not when the parent is changed in the settings. If anyone knows of any smarter way of doing this stuff, I would be interested, otherwise maybe this could be moved to a tutorial?
    1 point
  7. Thanks @gebeer. In reality it's not quite as simple as that because my code is inside a method that is called by six different hooks, rather than in a single hook. However, passing the object argument to that method by reference, rather than by value, means that I can then avoid the unnecessary saves, as you suggest. I'll post an amended version in the tutorials thread.
    1 point
  8. Thanks for sharing this. Looking at the implementation of parentPrevious inside wire/core/Page.php I thnk your solution is perfectly viable and the parentPrevious property was implemented so we can use it in circumstances like these. At which point in your logic are you using the bypassSaveHook session variable to prevent loops, is it inside a different hook to Pages::save? And since you are inside a Pages::saveReady hook, I think you do not need to set $page->of(false) because output formatting is already turned off at that stage. Also you do not need to do $page->save() because this is happening after the hook was executed and the page is saved with the values that you assigned inside the saveReady hook. So the loop most likely is being caused by the redundant $page->save(). Try removing that line and see if you need the bypassSaveHook session variable at all.
    1 point
  9. Eleven years later, but thanks for that, Ryan! It was exactly the explanation that I needed.
    1 point
  10. The latest site of the week reminded me of https://senderkataster.rtr.at/ that I built with a friend some time ago and that I want to share. Tech: ProcessWire (obviously) https://getuikit.com/ (also quite obvious 😄 ) https://tabulator.info/ for all kinds of filters https://leafletjs.com/ for the map https://basemap.at/ using an Open Government Data License Some GDAL command line magic to transform the overlay source data into PNGs that are stored in ProcessWire pages and can then be queried and correctly placed on the map. ProcessWire has been a great platform for that project! If you need help with a ProcessWire project that needs some geo-magic or powerful web maps drop me line 🙂 I'm not responsible for the red background 😅 Show details of a tower Choose a program by name or type and show its radio coverage (not in the screenshot): Expert mode for nerds:
    1 point
  11. Just a quick update this week, as yesterday was a holiday here and it becomes kind of a holiday week with kids out of school. On the core dev branch, the built-in PageFrontEdit module has been updated to support the new InputfieldTinyMCE rich text editor module. In addition. The $sanitizer->email() method has been updated with several new options. These include support for emails with Internationalized Domain Names (IDNs), UTF-8 local parts and an option to validate the DNS of the email domain. Currently all of these options are off by default but can be enabled with a new $options argument. These options will likely be translated to configure options for email fields (FieldtypeEmail) in the next week or so. In addition, a new version of the ProFields Combo has been released and this version also adds support for the new InputfieldTinyMCE module. I'm also working on updates for ProFields Table and Textareas for support of InputfieldTinyMCE as well, but those updates aren't quite ready to post just yet. If you opt to use TinyMCE with PageFrontEdit or Combo, make sure you grab the latest version of InputfieldTinyMCE, as it also received related updates this week. Thanks for reading and have a great weekend!
    1 point
  12. @bernhardI just haven't gotten to it yet, as it requires a PageFrontEdit module update rather than a TinyMCE one. I also have to update ProFields Table, Multiplier, Textareas and Combo to support TinyMCE. Once all of these are done we'll merge the TinyMCE module into the core.
    1 point
  13. Hi, i am trying to add a select options - field to one of my images fields. Usually you create a new template "field-FIELDNAME" and add the custom fields for the images there. I have a textarea field which is visible, but the options field isn't there. Can you help? Ryan has select options in his example: https://processwire.com/blog/posts/pw-3.0.142/
    1 point
×
×
  • Create New...