Jump to content

d'Hinnisdaël

Members
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

61 Excellent

About d'Hinnisdaël

  • Rank
    Jr. Member

Profile Information

  • Location
    Vienna, Austria

Recent Profile Visitors

1,352 profile views
  1. You're right in that it's nearly impossible to tell which page to edit just from the URL. I think the only reliable way of getting the correct edit link is to render the admin bar server-side using wire('page'). No need to make it overly complex, I guess, by going the JS route. If somebody decides to do partial content replacement in their frontend, I feel like that's just something they have to take care of themselves by including the admin bar in the list of replaceable containers. The more I think about it, the more I feel like my case applies to that rule as well. If I want the links to force a full reload instead of a replacement, I need to configure my frontend accordingly. My only remaining gripe is probably the logout button that shouldn't be an anchor 🤡 As far as I know, it wouldn't make a difference since most libraries don't care too much about accessibility and tend to define their own cancellation methods (data-no-turbolinks="true", etc.).
  2. @teppo Those are some good points. I agree the admin link itself and the edit link should stay anchor tags. Create, browse and logout, however, aren't semantically speaking links since they potentially have side effects (create, logout) or only trigger module JS (browse). There is one case that will create pages by merely following a link: when a template is configured to use the »Name format for children« setting in order to skip the page-add step. In that case, a new empty page is created every time the link is opened. I use that setting on most templates, that's probably why I noticed. The logout could be implemented using just a form and a submit button, using the form action for the logout URL. Not sure if ProcessWire currently supports custom redirect URIs after logout or if you might have to hook into the logout process for that. Turbolinks in particular switches out the whole body, but the problem here is that since there's no actual reload, stylesheets and scripts stay active on the page, so you mostly need to make sure that you don't cross between frontend and backend with any of these libraries, whatever part of the HTML they switch out. I've found a hacky solution by canceling any AJAX page visits if the URL matches the ProcessWire admin URL, but that means the frontend code needs to have a 3rd-party backend module in mind, which feels wrong.
  3. @teppo I just installed the module but noticed all links are anchor tags, which is a bit problematic since these links can be triggered involuntarily by scripts or browsers prefetches. When combined with frontend link preloaders (e.g. InstantClick) or browser prefetching (e.g. Google Chrome Page Prefetch), this results in newly-created orphan pages or mystery logouts. Is there a way the module can be updated to use buttons instead? This would also make it work better with libraries like Turbolinks or Barba.js which intercept link clicks to load them via AJAX and switch out the response body. I'd gladly create my own theme to do that, but figure this is also a security issue, so it might be best to tackle this at the root level 🌝
  4. Doesn't LazyCron hook into ProcessPageView::finished to avoid this exact problem? What I've done in the past to avoid long-running requests is to merely use LazyCron to trigger the time-intensive action via curl or wget, making it asynchronous.
  5. Very nice — I'm really impressed about how this is coming along. I particularly like how you manage to pack as many features into it while successfully staying within ProcessWire's visual language. I wish I had a little more time on my hands to try it out in depth and give useful feedback. That sounds like a logical next step to me: using LazyCron to auto-fetch certain data. While it will increase complexity in the short term, it will probably make your job a lot easier in the long run and make for a better experience using the module.
  6. This looks great! I've set up my fair share of Snipcart sites, but never bothered to abstract any of it into a module. So thanks for making this available in whichever form you're comfortable with, free or paid. My Snipcart styles have usually been very tightly linked to the site stylesheets (shared SASS variables and mixins) and ended up in the global site stylesheet. Maybe the stylesheet URL input shouldn't be mandatory for sites that already have the Snipcart CSS embedded? Just a thought.
  7. 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…
  8. @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') { [...] } }
  9. 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.
  10. 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?
  11. 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?
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...