Jump to content

Noel Boss

Members
  • Content Count

    169
  • Joined

  • Last visited

  • Days Won

    6

Noel Boss last won the day on December 2 2018

Noel Boss had the most liked content!

Community Reputation

280 Excellent

1 Follower

About Noel Boss

  • Rank
    Sr. Member

Profile Information

  • Gender
    Male
  • Location
    Zurich
  • Interests
    I have a passion for Jesus and the Church and love great development tools – first of all Processwire.

Recent Profile Visitors

1,735 profile views
  1. There is kind of built in support for this; - Edit the admin template and add a text field with the name "page_icon" - Go to the admin page tree, search for your lister pages to edit: – Add the fontawesome icon name without the fa- part… Voila: Thanks to @ryan for pointing me to this solution in a support request… 🙏
  2. I refactored your refactored code 😉 One could also remove the pages that should be excluded beforehand… $this->addHookAfter('ProcessPageList::find', function (HookEvent $event) { $excludePagesByTemplate = ['admin', 'basic-page']; $event->return->find(["template!=" => $excludePagesByTemplate])->each(function ($p) use ($event) { if (!$p->editable() && !$p->addable()) { $event->return->remove($p); } }); });
  3. What does $languages->getLanguage(); return? I have instances where this gives me the correct Language. I also had flacky results with setLanguage and unsetLanguage… Overall, it feels like quite a bit a mess here 😉 I think, ProcessWire would do very good with some (unit)test… Also for the selector engine…
  4. Technically I can, directly in the DB… And it also apparently works… But I don't know in how many ways it could break. Want to rename it, because I want it to be semantically correct and because I don't want to add a new field. I need it to display labels like "en" "de" and I could just use the name to do so instead of adding another field or hardcoding it…
  5. Has anyone tried renaming the default language name from "default" to something else like "en" ? Are there unintended side effects or restrictions or anything else to consider? There is $languages->findNonDefault(); and $languages->getDefault(); that suggest that renaming should be possible without breaking the core, but I suspect, some modules ore maybe even the core are using $languages->find('name=default') or the inverse and thus break things all over the place… Has anyone pulled this off?
  6. Hi everyone 🙌 Is there a way to order the language tabs in the backend? Currently, they seem to be ordered based on the created date (or id?) … ( time passes … ⏰ 🚶‍♂️) Just answered my own question. One can reorder the languages in the page tree under admin » languages or directly in the DB » pages » template_id=54 » sord field. Anyone knows if there are side effects when moving the default language from sort 0 to somewhere higher?
  7. You can just change $page->template->contentType and $page->template->altFilename at runtime… $html = $page->render(); $page->template->contentType = 'txt'; $page->template->altFilename = "Mail.txt.php"; $txt = $page->render(); $count = $this->mail->new() ->subject($subject) ->body($txt) ->bodyHTML($html) ->send(); For me, altFilename actually is enough…
  8. Hi @LostKobrakai – we are diverting from the subject 😉 My business logic is a bit complicated. I have many organisations, and an organisation have different memberships and depending on these memberships, the users assigned to the organusation can view different pages … and the users themselves have different roles inside the organisation and some pages are blocked or unlocked based on the role in the organisation. I could not find any module or core functionality that let me handle this use case with elegance. So what I do is i get all the pages blocked by a specific selector based on language, membership and role (and sometimes login state etc.) and cache the resulting ids based on these attributes [so they are only fetched once per membership-role combo-language until a page matching relevant template or the user or the organisation changes … complicated eh 😉], this needs to happen very early so I don't miss any query operations later on. I then filter using a hook by appending the id's as a id!=1|2|3 selector … thats the most efficient way I found. – I tried most of the modules out there, not sure if I found this one you mentioned @LostKobrakai – I'll have a look at it, thanks! Also, I just recently found the ___getQueryAllowedTemplatesWhere() hook in PageFinder.php … I might investigate this one a bit more… (thats the one Dynamic Roles uses as well) So, back to the topic, I use hooks here, and elsewhere for other purposes inside the init() method and it would be nice to have a consistent and simple way to check if we are in admin or not 🙂
  9. @horst – I need init to bind hooks that can only be bound before ready fires – for example render, or viewable … Therefore, hook priorities don’t help me. I could just bind the hooks anyway, but I only want to bind the hooks, when I really need them… My goal is to not bloat the system with hooks … I use tons of them, but I only wan’t to invoke them wenn really needed. For example. some of the hooks are access related and since PW does not provide a robust and native way to hook into page access features [viewable about the only option, or filtering find queries, both not great options but it's what you get…] I have to be very early in to boot process, sometimes earlier than init ( __construct() ) … These hooks are costly since I have to check for all pages with related pages and then get a blacklist from ID’s that I can then later use filter my results so I don’t get wrong page counts when requesting pages… @ryan it would really be great to be able to hook into the access system on a lower api level… (not directly on sql…) you’ve built some nice modules, but they all are on top of the current system and don’t work for find queries…
  10. Thanks four your suggestions… However, I'm talking about the init() method inside a module, not ready and not render (for render, the page needs to be there, so ready is already fired) – this is early in the boot process, no page and no template is available at that stage… sometimes not even a process… (at least wherever I tested it) – also parent::init throws an error.I am also not talking about the init.php – this might be different… Nope 😉 @Zeka – thats about what I do with the first and the last test from my example, but it feels very much like a hack for my taste… I currently use a Hook to extend wire that looks the following: public function __construct() { $this->addHookMethod('Wire::isAdmin', $this, 'isAdminHook'); } public function isAdminHook(HookEvent $event) { $event->return = false; if ( $this->process instanceof ProcessPageList // Admin Page List || $this->process instanceof ProcessPageEdit // Edit Screen || strpos($this->input->url, $this->urls->admin) !== false // determine from Admin url… || ($event->arguments(0) instanceof Page && $event->arguments(0)->rootParent->id == $this->config->adminRootPageID) // if a page is passed… ) { $event->return = true; } }
  11. 👋 PW Pros… I have some hooks that I need to bind at the init phase (or even __construct) and I was wondering, and I couldn't find a good and simple way to determine if I'm in the admin. Would be nice if there is a reliable short option to do so, but I can't seem to find one… Is there a coherent way to tell this no matter where I am? Right now, I use the following method inside one of my modules: public function isAdmin($page = null) { if ( strpos($this->input->url, $this->urls->admin) !== false || $this->process instanceof ProcessPageList || $this->process instanceof ProcessPageEdit || ($page instanceof Page && $page->rootParent->id == $this->config->adminRootPageID) ) { return true; } return false; } @ryan wouldn't it be nice to have something like wire()->isAdmin(); like wire()->user->isLoggedin(); to tell if we are in admin – very early on (probably even in __construct() phase of modules?
  12. @johndoe can you please open an issue and provide some more info… OS, Browser, Screenshot and if you have any clue, affected css… Thanks!
  13. New Release 0.6.3 – Codename »hehehe« The last release with a "fix" to the login screen actually broke stuff more than fixing it (thanks @johndoe for reporting this). So this is a fix for the fix… Sorry about that. And some improvements to the login screen on mobile devices. Support Forum ProcessWire Modules Repository Gitlab & Issues Added Fullscreen login screen on mobile 📲 Improved notifications on login screen Fixed Fixed Login screen design 🤯
  14. New Release 0.6.2 – Codename »boring« Fixed Login screen design 🖌 Readme 📄 AOS Language Switch overlapping notifications 💬 --- Get Release Notifications ProcessWire Modules Repository Gitlab & Issues
×
×
  • Create New...