teppo

Necessary disclaimer: just like you, I also mean zero disrespect, and I get that this is a topic where opinions matter, and so on 🙂 I agree with your point about that the admin should stay out of the way, and I do also share some of your concerns regarding current admin theme. But that being said, I must admit that I quite like the current colour theme: it's pleasant, professional, not at all childish (in my opinion), and brings just the right amount of personality to the theme. Also I personally find a black/gray/white colour theme rather boring — unopinionated for sure, but also boring. On the other hand one thing that I do dislike about Admin Theme Uikit is the noise created by separator lines. And, as it happens, your theme suffers from exactly the same issue: to my eyes it's still way too noisy. Opinions, right? 🙂 Anyway, this is a topic that is definitely worth discussing further. Also Ryan has been extending our ability to customize and build upon the Uikit admin theme lately, and I'm quite interested to see where that road takes us. I feel that with some additional tweaks and customization options it could become a solid starting point. And if that could finally resolve the age-old problem with modules having to support multiple admin themes that all work differently, all the better. (Loosely related note: I seem to recall that there was some reason why Tailwind's original gray colour set was blue-gray. For whatever reason that type of thing works better for my eyes. There are probably better examples, but Craft CMS makes extensive use of gray/blue-gray/blueish colours, and their admin looks very pleasing to me. It's not opinionated, but it's also not impersonal or boring.)

First off I would recommend re-reading this part of the hooks documentation: https://processwire.com/docs/modules/hooks/#conditional-hooks. If we take a closer look at your second code example, here's what it's trying to do: Add hook after the saveField() method of the Pages class has been executed ... but only if the first argument to saveField() contains string value "snipcart_item_image" Now, if you look at the definition of Pages::saveField() ... * @param Page $page Page to save * @param string|Field $field Field object or name (string) ... you can see that the first argument is actually a Page, not a string. In other words your condition doesn't really much sense here — what you're probably looking for is the second argument, which is the name of the field as a string or Field object. The conditional hooks documentation explains how to access a specific argument: $wire->addHookAfter('Pages::saveField(1:snipcart_item_image)', function($event) use($item) { Note: as you can see from the second @param definition, saveField() can receive either a string or an object. If there's a way to target both with conditional hook format, it's something I'm not aware of. I'm afraid that you're making things a bit complicated for yourself by trying to use the conditional hook syntax; it's an advanced feature that has it's use cases, but it's often easier to just hook into some method and "return" if the arguments are not what you are looking for. But, alas — there's a potentially much bigger problem here: when you save a page, ProcessWire doesn't call saveField() for each field individually. I don't know in what context you're trying to make your hook work so I can't say right away how you should write this hook, but I'd be interested to know if you gave my earlier example a try... and if so, did it do anything? If you're trying to change the value right before the page gets saved in the admin, you most likely should be hooking into Pages::saveReady. Or you could hook into Pages::savePageOrFieldReady if you also want to catch single field saves 🙂 Edit: keep in mind that even if you hook into Pages::savePageOrFieldReady, the field name (second argument for said method) is only populated if a single field was saved. The value is not going to be there if an entire page was saved. If you take a look at my previous reply and change it the code sample to use Pages::savePageOrFieldReady, it should actually be pretty close to catching both "full page saves" and single field saves.

This sounds eerily familiar. Some situations where this might happen are if you have a "start" specified in your selector, if page numbers are not enabled for the template, or if you have multiple pagers resulting in some kind of conflict. If nothing else helps but $input->pageNum has the correct value, you could perhaps go at this the other way around — not tested, but if you instantiate MarkupPagerNav manually you can try to force the page num: $results = ** a somewhat complex search that returns a pagearray ** $perPage = 20; $results->setLimit($perPage); if ($input->get->f) $input->whiteList('f', $input->get->f); if ($input->get->l) $input->whiteList('l', $input->get->l); if ($input->get->a) $input->whiteList('a', $input->get->a); if ($input->get->t) $input->whiteList('t', $input->get->t); $pager = $modules->get('MarkupPagerNav'); $pager->setPageNum($input->pageNum); $pagination = $pager->render($results, [ 'nextItemClass' => 'next', 'previousItemClass' => 'previous', 'currentItemClass' => 'current', 'separatorItemClass' => 'separator', 'numPageLinks' => 5 ]); $start = ($input->pageNum-1) * $perPage; foreach($results->slice($start, $perPage) as $item) { // render the thing } echo $pagination;

Hey @kongondo! I know this project is at a very early stage, but it does seem promising. I also like your ideas about the data structure, though I'm not entirely sure I fully get it yet (might require a more hands-on example of the data vs. schema vs. database structure part). At this time I really only have one question: do you currently see this as a potential commercial module, or something that you would consider open sourcing? I get that it's very early, and I want to stress that there's absolutely nothing wrong if you think it'd be better suited for commercial release. That being said, I see this kind of tool as a pretty massive undertaking, and thus something that could benefit from larger community involvement. I for one would definitely be interested in contributing in some way, assuming that would be an option. Anyway: a very interesting project — keep up the great work! 🙂 Just wanted to point out that I don't really see this as an issue. If we take WordPress as an example, they've always had UI's that (for similar reasons) step out of the regular Admin: Customizer from the core, for an example, as well as various plugins (Ninja Forms has a very distinctive full page form editing GUI), and in my opinion that works just fine.

You could remove it directly from the database, but in this case I would recommend another route that is likely easier: Comment out or remove the ___uninstall() method from NewsletterSubscription.module. Uninstall the module — this should now work as expected. If you no longer need the "newsletter" role, go to Admin > Access > Roles and remove it manually.

@dotnetic, thanks for the clarification, but I must admit that I still see this mostly as a bad thing. I believe this would work best if issues were actively discussed by both users and maintainers, and/or maintainers were so busy that they were forced to focus only on those issues that attract a considerable number of new reports from users on a steady basis. In our case that's, in my opinion, not the case: an issue or feature request can be valid even if it hasn't received comments, or been acted on by Ryan, in months -- if not years. Anyway, that's just my take on this. It's not a bad idea per se, I just don't see a lot of value in it in our specific context 🙂

I can see how that might be useful in some cases, and it would definitely be useful if it could be triggered by "needs more information" label or something like that (i.e. unreproducible issues where the original author is no longer responding) but since that doesn't seem to be possible, in our case it sounds like mostly a bad thing. This would either end up closing actual issues / feature requests, or authors would need to start posting pointless "bump" comments periodically 🙂

Version shouldn't matter, since this change has occurred on the YouTube side. If neither of these sites is using HTTPS, then I'd suspect that it's a caching thing: Textformatter Video Embed stores embed codes in the database, so if that other site has fetched the code via HTTP while it was still possible, it'll continue to work until you clear said cache from the database. Google has in the past also deprecated features in weird ways, so that they've kept working for existing sites/domains but not for new ones, though I doubt that'd be the case here 🙂

Just gave it a try and this is the response I get from YouTube when not using HTTPS: { "error": { "code": 403, "message": "SSL is required to perform this operation.", "status": "PERMISSION_DENIED" } } Happens on 3.0.148 as well as 3.0.165. The way TextformatterVideoEmbed is set is that if it doesn't get a proper response (one with "html" key) it won't do anything, so this is technically expected behaviour. That being said, I don't see any reason why this module should use the HTTP protocol even if the site itself does, and since YouTube no longer seems to allow that it's definitely not the right thing to do. I've opened an issue for this for @ryan: https://github.com/ryancramerdesign/TextformatterVideoEmbed/issues/16 🙂

I have a lot of thumbs-upping to do... 🙂 Anyway, I couldn't find related request right away. I know this has been requested and discussed on various occasions but I assume it's not such a common need that anyone would've yet opened a request for it in the "new" repository, or perhaps those asking about it here or googling for this found an earlier answer and figured that it'll be unlikely to change. Here's a new request: https://github.com/processwire/processwire-requests/issues/376.

Just my five cents (or fifty, looking at the length of this answer): There is zero interest here to move ProcessWire away from what it does now, or somehow get rid of the way it handles structured data. Absolutely zero. If you're worried that someone wants to thrash the system we now have and replace it with a Gutenberg clone, fear not: that will not happen, period. Now, as you've pointed out, there are different use cases. Almost all the sites I build and clients I work with nowadays require a "builder" approach: flexibility in terms of laying pages out. CKEditor goes to some extent here, but it's riddled with issues, and honestly the experience can be pretty horrendous: image management in particular is a lacklustre, and embedding any type of dynamic content (or anything CKEditor doesn't handle itself) gets difficult/technical (short codes with params etc.) A couple of reasons why comparing what we're doing to what WP is doing with Gutenberg makes little sense: In WordPress Gutenberg is going to replace the "classic editor", and it's also going to replace a lot of other built-in tools (such as menu management GUI) in the long term. The ultimate goal there is a "full site editor". This has very little to do with what we're discussing here. WordPress has never (natively) provided custom fields. Instead they have predefined fields and (freeform) page meta. ACF and similar plugins that make custom fields possible are popular, but page builders are even more so. It makes sense for the core team to extend the core with the tools that most users seem to want. I could get into the reasons why Gutenberg reviews are so bad — such as there being a lot of history, a lot of resistance to change, a lot of misunderstanding, likely mostly developer votes while the feature itself is aimed more at content editors, and so on — but I won't. My point is that improving the ability of ProcessWire to handle flexible layouts is not going to take anything away from those who don't want or need that. ProcessWire has many things that some users don't need or use. For an example, I've never used front-end editing for client sites. It's a feature I don't need, so I don't use it. It's as simple as that 🙂 I'm going to cherry-pick one thing from this list: "I want to protect the entire site" 🙂 I've worked on many completely non-public sites. While I believe I get the reasons @ryan has for not allowing the home page to be non-public, I would absolutely love for this to change. Even if it required a hook or config setting, that'd be a very nice addition. Currently I'm doing this with custom code, but there are some negative implications and I'm always a bit worried that it'll break: first of all it's (my) custom code and if something changes there's always a slight possibility that it won't work as expected, and second of all it needs to be done with hooks (to protect assets and make sure that nothing can interfere) and can thus sometimes get a bit complicated. TL;DR: if there was an option to somehow protect the entire site so that all non-authenticated requests (home page included) result in a login request, I'd be one happy user 🙏

Just a quick heads-up that the hook I mentioned is now implemented in the latest release. There's a new method called ProcessChangelogHooks::shouldLogPageEvent() for this, and all the existing checks have been moved there as well: /** * Should we log this Page event? * * @param Page $page * @param Field|null $field * @param string $operation * @return bool */ protected function ___shouldLogPageEvent(Page $page, ?Field $field, $operation) {

Seems related: https://github.com/processwire/processwire-issues/issues/1300.

If you check ProcessChangelogHooks settings, there are already options for ignoring specific roles and users, so the part about ignoring "guest" user is doable. Permission based filtering is not available, and I'm not entirely sure if it should be; perhaps a hook would be a better solution for this kind of granularity 🙂 Anyway, I'll keep the live filtering option on my todo list, as it seems like a useful addition.

Makes sense to me. It's removed in the latest release, though I also had to add a new label text before the input so that the meaning is still obvious. Just to clarify: you mean that there would be a new filter option for displaying only users with specific role / permission? If so, this does sound like a good idea. I'll add it as a new enhancement issue for now, it'll require a bit more thought (the filter GUI probably needs a bigger overhaul soon).