Jump to content

thetuningspoon

Members
  • Posts

    662
  • Joined

  • Last visited

  • Days Won

    3

thetuningspoon last won the day on May 18 2020

thetuningspoon had the most liked content!

3 Followers

About thetuningspoon

  • Birthday 11/03/1986

Contact Methods

  • Website URL
    https://si.design

Profile Information

  • Gender
    Male
  • Location
    CT, USA
  • Interests
    Design, Programming, Tiny Houses

Recent Profile Visitors

13,281 profile views

thetuningspoon's Achievements

Hero Member

Hero Member (6/6)

564

Reputation

5

Community Answers

  1. Watch out with this. If you're running a cli script or cron job, the SERVER_NAME will not be set and you may end up running it on your live database instead of your development!
  2. This has been an intermittent issue for me with PW as long as I can remember.
  3. @Noel Boss For some reason this doesn't work with your change from using add() to using $page->set() (PW 3.0.178). I got it to work and figured out a way to clear the orphans message: $field->setOrphans(new PageArray()); $page->{$field->name}->add($page->children('include=all, check_access=0')); I also added include=all and check_access=0 to make sure all children get added. Here's the resulting full hook method: /** * Fill pagetable fields with children before editing…. * * @param HookEvent $event */ public function addChildrenToPageTableFieldsHook(HookEvent $event) { $field = $event->object; // on ajax, the first hook has no fieldname if (!$field->name) { return; } // get the edited backend page $editID = $this->wire('input')->get->int('id'); if (!$editID && $this->wire('process') instanceof WirePageEditor) { $editID = $this->wire('process')->getPage()->id; } $page = wire('pages')->get($editID); // disable output formating – without this, the ajax request will not populate the field $page->of(false); // you could also insert a check to only do this with sepcific field names… $field->setOrphans(new PageArray()); // Clear out the "orphans" notice $page->{$field->name}->add($page->children('include=all, check_access=0')); }
  4. We've been playing around with findRaw but it looks like it doesn't support getting fields from the parent page like it does for page fields. Any chance we can get that feature added? 🤞 😇
  5. This sounds fantastic. A couple of our clients have been wishing for something like this and have tried using the clone/copy feature to try to achieve it, but then have issues such as the CkEditor fields pointing to the wrong page's files. Would this feature resolve that issue?
  6. Seems like it should be mentioned somewhere that the pageFileSecure settings only works with files added after it is enabled.
  7. Glad you're finding it useful! You are correct--I don't believe I ever added support for the read-only state of the various inputfields. Feel free to submit a pull request if you do work on this.
  8. Posted by: <?php if($page->insight_author): ?> <a href='<?= $page->insight_author->url ?>'><?= $page->insight_author->title ?></a> <?php endif ?> , <?php foreach ($page->insight_author->roles as $role): ?> <?= $role->staff_role ?> <?php endforeach ?> I would suggest something like the above, though there are certainly other templating styles. Like @monollonom said, I'm not exactly sure what role represents or how that is structured.
  9. @ryan I'm trying out the new join feature within a regular page selector. I believe you mentioned that it is possible to join subfields of page fields. I'm wondering if you can explain that in a bit more detail. Does this still all happen within a single SQL query? If I want to join the id and the title of a page in a page reference field, which of the following is the proper way to do this? $pages->find("template=foo, join=pageField|pageField.title"); $pages->find("template=foo, join=pageField.title"); // Can I join pageField.title without also joining the pageField? If so, would I still have access to the page id? $pages->find("template=foo, join=pageField.id|pageField.title") // Is joining pageField.id the same thing as joining pageField? I could answer these questions for myself if I knew of a good way of checking which data has already been loaded in the resulting page. What is the best way to double check what field data is already loaded on the page objects after performing a find (in order to make sure the join worked properly)? Edit: I just realized I wasn't thinking clearly when I wrote this. Being able to join subfields of page reference fields would require loading those pages as their own separate page objects, which would always include the page ID, name, modified, and created dates. I am still wondering whether doing either join=pageField or join=pageField.title would actually cause those pages to be preloaded as part of the find, or whether it would only lazy load them when first requested, per the normal PW behavior.
  10. This is great. Is it possible to hook after trash/delete in the page editor in order to redirect somewhere other than the page list now? This was something I had need to do in a recent project and had to do something pretty hacky to achieve the effect.
  11. No changes here. There's only so much that can be joined in one query per field, so autojoin is not always possible, especially on multi-value (FieldtypeMulti) fields with lots of values. It should be possible on most Page reference and options fields though, so long as they don't have huge amounts of selections. If there's need for it though, I may be able to have fields (where applicable) store a cache of data (like FieldtypeCombo does) that can be autojoined. I recall that in the past auto joining multi-value page fields would fail quietly and simply result in bad data being returned (like a single page instead of all pages). Can this be changed so that it throws an exception (or at least skips trying to auto join it) if you try to auto join a field that can't be auto joined? That would help avoid nasty issues for programmers who aren't familiar with the internal workings here.
  12. @Robin S That looks nice and clean. Would this actually make it appear non-editable, or just prevent the values from being saved?
  13. Here is a cleaner and more thoroughly tested version, which eliminates some of the code duplication. The Field::viewable hook is no longer needed. I'm not sure why the Field::editable is still necessary, but it doesn't work without it. /site/ready.php /** * Implements a custom page-edit-edit-fields permission. By default, all fields will be view only when the page-edit permission is granted. Adding the page-edit-edit-fields permission makes all fields on the page editable. * This could be accomplished by implementing access settings on every field of the template, but this makes it much easier. * * Individual field access settings, if enabled, will override this feature. */ $this->wire()->addHookBefore('Field::getInputfield', function(HookEvent $event) { $page = $event->arguments(0); if($page instanceof User) return; // Exclude any field types we don't want to make uneditable by default $excludedFieldtypes = [ 'FieldtypeFieldsetClose', 'FieldtypeFieldsetOpen', 'FieldtypeFieldsetTabOpen', 'FieldtypeFieldsetPage', 'FieldtypeFieldsetGroup', ]; $field = $event->object; $context = $event->arguments(1); $user = $event->wire('user'); if($context || in_array($field->type, $excludedFieldtypes)) return; // If the current user does not have page-edit-edit-fields permission, disable edit regardless of the field's roles if(!$field->useRoles && !$user->hasPermission('page-edit-edit-fields', $page)) { $field->setRoles('view', [$event->wire('config')->guestUserRolePageID]); // Set all roles to have view permission by passing in the guest role $field->setRoles('edit', []); $field->addFlag(Field::flagAccessAPI); $field->addFlag(Field::flagAccessEditor); $field->set('useRoles', true); $field->set('disabledByHook', true); } }); /** * Only the above Field::getInputfield hook should be required since it sets $field->setRoles('edit', []); but for some reason the main content tab will still appear editable unless we add this hook */ $this->wire()->addHookAfter('Field::editable', function() { $return = $event->return; $field = $event->object; // If the current was field disabled by our other hook then reflect that here as well if($field->disabledByHook) { $return = false; } $event->return = $return; });
×
×
  • Create New...