d'Hinnisdaël

Members
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

52 Excellent

About d'Hinnisdaël

  • Rank
    Jr. Member

Recent Profile Visitors

989 profile views
  1. d'Hinnisdaël

    True. Many of the recent API updates are about privacy, which is a good thing. But the rollout was more than ideal. And I'd love to go the official way and use their API. But I get emails from clients every other week, asking about invalidated API tokens after they log in from a hotel wifi. And setting up API tokens is quite the hassle. So yeah, it's scrapers for now…
  2. d'Hinnisdaël

    @benbyf To save myself from the headaches, I only use scrapers anymore. No sandboxed accounts, no setup, no invalidated keys every two weeks. instagram-php-scraper has been working great so far. This is all there is to getting recent media of any user id or name: $userid = env('INSTAGRAM_USER_ID'); $instagram = new \InstagramScraper\Instagram(); $account = $instagram->getAccountById($userid); $username = $account->getUsername(); $latestMedia = $instagram->getMedias($username, 10); foreach ($latestMedia as $media) { if ($media->getType() === 'image') { [...] } }
  3. Me again. Sorry for wasting your time Everything is working as expected now. I overlooked the vps permission and only now found it — after stumbling through this support thread.
  4. Great fan of the module! However, I haven't yet gotten it to work for non-superusers. The modal for selecting pages aborts with an error »ProcessWire: Unrecognized path« and »The process returned no content.« Now I guess it has to do with them not having the required permissions to access the root Admin page, but is there another way to allow editors to use the module?
  5. d'Hinnisdaël

    Field exports don't seem to work properly with the module enabled. When exporting a Fieldset (via Setup » Fields » Export), I get the following error: Call to a member function add() on null (MinimalFieldset.module, line 74). $wrapper seems to be unset in this specific context. Uninstalling the module gets rid of the exception. Could you check if you see the same thing (I'm on 3.0.117) or if I just have something misconfigured?
  6. d'Hinnisdaël

    Wonderful! Well done and thank you for taking the time and releasing this. I've been thinking about the exact same thing for a while now. Could you make the vertical spacing optional, via another checkbox maybe? I have quite a few layouts where the secondary column has a lot fewer inputs and would prefer to have them on top.
  7. d'Hinnisdaël

    What do you think about making the module extensible via hooks? I had a client request a sitemap that included videos. Now, methods of storing videos differ: file fields, video URLs, embed codes, and so on. I suspect there's no straightforward way to include videos in the sitemap using just this module. However, implementing this on a site-by-site basis would become simple if there was a way to hook into the sitemap creation process and append different definitions like video or news item yourself. Of course, I could create the whole sitemap from scratch — but your module does a lot of things very well and I'd love to build upon that.
  8. d'Hinnisdaël

    I kept running into the issue of self-invalidating access tokens and wanted the site's content editors to be able to handle the generation of new access tokens themselves. The module, however, limits those functions to superusers. Could you change the module to check for the module-admin permission? It's ProcessWire's internal permission to check who can edit module configurations. It's deactivated by default and has to be created and assigned manually, so there's no additional risk or security concern. On a standard PW installation, it still only applies to superusers. However, it gives people the possibility to allow editors to generate access tokens. So instead of if ($this->user->isSuperuser()) { $href = self::API_URL_AUTHORIZE . '?' . http_build_query($request); $link = "<a href='$href'>" . __('get Access Token') . "</a>"; } it's if ($this->user->isSuperuser() || $this->user->hasPermission('module-admin')) { $href = self::API_URL_AUTHORIZE . '?' . http_build_query($request); $link = "<a href='$href'>" . __('get Access Token') . "</a>"; } (There's a second check somewhere further down). Thanks for considering this. I forked the module for now, but would much rather like this to be incorporated into master.
  9. d'Hinnisdaël

    Would it make sense to add an option to exclude tables from the backup, instead of choosing the tables to include? This would be especially useful with regards to the sessions table. I have a project with a moderate amount of visitors, but 1million+ rows in the sessions table. The backup module fails since the process needs too much memory. If I exclude the sessions table, the export shrinks from 150MB to 30MB, which the server can easily handle. Now, I can already select all tables and leave the table sessions unchecked. However, as soon as I add a field, template, etc., all future backups will be missing that table completely. In that scenario, an exclude option would be the better option. I might just whip up a PR when I find the time, but was wondering if anybody else feels this is necessary or a good idea.
  10. Beautiful, that did the trick. Thanks! Much better than modifying the core search module, and it won't spill over into generic find() calls in the front-end. No idea how I missed the findReady hook in the first place… Final working implementation: // Include unpublished participants in page fields for non-superusers wire()->addHookAfter('ProcessPageSearch::findReady', function(HookEvent $event) { $selector = $event->arguments(0); if(strpos($selector, 'template=participant') !== false || strpos($selector, 'templates_id=76') !== false) { $selector .= ", check_access=0, include=all, status<" . Page::statusTrash; } $event->return = $selector; });
  11. d'Hinnisdaël

    Good point. I've always used it conjunction with some light caching to store the results as JSON.
  12. Unfortunately, this doesn't seem to work for non-superusers. I've been up and down the source of ProcessWire's internal admin search (which powers the page autocomplete input) and it really seems to limit the selection of unpublished pages to superusers. Would be great to have autocomplete inputs respect the Include unpublished setting of a Page field.
  13. d'Hinnisdaël

    For most group-by-property situations, I use Fun with hooks: PageArray::groupBy.
  14. I'm pretty sure that anything beyond basic template selection will not work in autocomplete inputs. I found this comment in the InputfieldPage source regarding custom PHP selectors: Not compatible with PageListSelect or Autocomplete input field types. Also, the field for adding custom code is disabled for autocomplete and page list selects: $field->showIf = 'inputfield!=InputfieldPageAutocomplete|InputfieldPageListSelect|InputfieldPageListSelectMultiple';
  15. From my cursory reading of the source, check_access also seems limited to superusers: // don't allow setting of check_access property, except for superuser if($lowerName == 'check_access' && !$superuser) continue;