Jan Romero

https://news.ycombinator.com/item?id=35659963 which one of you is this? 😉

Unfortunately I have nothing to contribute, but I tested your exact code on a PW 3.0.183 installation of mine and it worked as expected, so maybe the problem lies somewhere else?

@zoeck you’re right, disregard everything I’ve said in this thread. It appears I have bought too many ProFields for myself 😅

Yeah, but you can only renew for that price continuously. If you let the year elapse you have to pay full price to get another year, although I believe Ryan has made individual exceptions to this. At least that’s my understanding. IIRC the renew button is only there during the support period.

No, afaik that’s the way. I think it’s a fair enough deal. It definitely is for commercial use while still being somewhat affordable even for hobbyists. I mean, it’s a lifetime license for unlimited sites and the ProFields are awesome, you can’t go wrong with that. You can also get the “subscription” where you pay a heavily discounted yearly renewal. Or you could try asking Ryan nicely 😉

Go to Modules -> Configure -> AdminThemeUiKit. There will be a section called “Masthead + navigation” which you can click to open. Then under “User navigation label format”, where it currently says “{Name}”, enter “{title}” instead. Or any other valid template string you like, obviously. The field pretty much tells you what to do. Of course this only works if your user template has fields for the things you want to display. As you will notice, other admin themes have their own settings, so if you allow users to change themes, you’ll probably want to make equivalent changes to all of them. However, AdminThemeReno doesn’t use the same template string system and AdminThemeDefault has no setting for this at all.

Long time no WillyC! Also, I agree.

You can find the name of the admin by looking at the page with ID 2 in the database. Since you have access to the filesystem, you can also just echo $config->urls->admin somewhere. To reset the admin password, put this into a template and execute it: $u = $users->get(41); $u->of(false); $u->pass = 'hunter2'; $u->save(); 41 is usually the superuser who installed the site. If it isn’t you can try to find the account by selecting one with the role “superuser”.

HTMX already sends headers to identify itself with every request it initiates, so you could just put something like this into your config.php: $config->htmx = isset($_SERVER['HTTP_HX-Request']); The other headers seem useful, too: https://htmx.org/docs/#request-headers

HTMX will see the hx- attributes on your element and send a GET request to yourdomain.at/trigger_delay with the value of the input named “q” whenever it is triggered. Whatever the server sends as a response, HTMX will put in the div at the bottom (HTMX calls this “swapping“). Or something like that. I’m not familiar enough with HTMX’s defaults and the trigger syntax to be sure that your code will definitely work. Looks good though. The important parts happen in /trigger_delay, obviously. That is in keeping with HTMX’s whole raison d’être of mostly sticking to doing things on the server. What’s sticking out to me is the url of your endpoint “/trigger_delay”. It looks like this is supposed to be a page that returns search results or type-ahead suggestions, so I would expect something like “/search”.

There is this setting, but I’m not sure whether it will redirect or 404 if the undesired option is requested.

Okay, so, I didn’t think this should happen and indeed it usually doesn’t, but it definitely happens… sometimes??? This is the code I used to test it initially, just at the top of my home template. I visited the page, checked the UrlSegments in the admin and there they were: header('content-type: text/plain'); $page->template->urlSegments = array_merge($page->template->urlSegments, ['hello', 'world']); die(); I tried looking into core/Template.php but nothing seems suspicious… No idea what’s going on but I can reproduce the behaviour on two separate installations, one running 3.0.208 dev and one 3.0.191 dev. I’m not going to investigate this further and blame it on a module or a dumb hook I have set up, but I’m weirded out.

You can use this to change the template settings’ valid UrlSegments: https://processwire.com/api/ref/template/url-segments/. Be aware this persists the change immediately, without having to call $template->save()! You can also use property syntax: //Add UrlSegments “login” and “logout” to whitelist of current page’s template: $page->template->urlSegments = array_merge($page->template->urlSegments, ['login', 'logout']); If you have this requirement, it’s probably worth checking out the relatively new URL hooks: https://processwire.com/blog/posts/pw-3.0.173/

If I’m not mistaken that should be 47,672,401,706,823,533,450,263,330,816 combinations, so… seems sufficient? GUIDs are 128 bit tokens and they’re used for computer things, so for something like this that only needs to work on a human scale it shouldn’t be a problem to go a couple of billion times smaller. Especially if you rate limit against guessing. I wouldn’t ask for the phone number since anyone who intercepted the SMS would know that anyway. Shipment tracking things usually ask for my post code before showing my address, maybe that’s worth considering?

I imagine this may also be achieved without an additional database field using FieldtypeRuntimeMarkup: https://processwire.com/modules/fieldtype-runtime-markup/

Ah yes, my bad, you would have to make the groups mutually exclusive by adding the condition “does not have Type1” to the second one. Unfortunately I don’t think this is possible with FieldtypeMulti fields…

Have you tried Or-Groups? https://processwire.com/docs/selectors/#or-groups $pages->get("template=store_template, (equipment_ref.title='Equipment2', type.title='Type1'), (equipment_ref.title='Equipment2')"); I think this should work for you?

Maybe show those loops you already have, because I for one am unable to figure out what’s going on here in the first place? I suspect you mean Equipment2 here? So matching the equipment is kind of a fallback in case equipment AND type can’t both be matched?

Double slashes used to “just work” but they redirect to the clean url since 3.0.212. Haven’t looked into the code, I suppose the query string gets lost along the way?

@@byte the code you posted is vulnerable to SQL injections, because you're concatenating raw strings from the request into your SQL query (as @zoeck said). Even if it's just an example you're not using in production, I'd prefer if you didn't post it like that, because people might copy it.

Yes, it’s not going to pick up changes to the Fields, because behind the scenes you’re actually adding the Field to the Template’s Fieldgroup. Can’t figure out how to get added fields, but getting removed fields seems to work reliably: foreach(wire('templates') as $template) { /** @var Template $template */ $template->setTrackChanges(Wire::trackChangesValues); $template->setTrackChanges(true); $template->fieldgroup->setTrackChanges(Wire::trackChangesValues); $template->fieldgroup->setTrackChanges(true); } wire()->addHookBefore('Templates::save', function (HookEvent $event) { /** @var Template $template */ $template = $event->arguments(0); bd($template->getChanges(true)); }); wire()->addHookBefore('Fieldgroups::save', function (HookEvent $event) { /** @var Fieldgroup $fieldgroup */ $fieldgroup = $event->arguments(0); bd($fieldgroup->getChanges(true)); //says NULL for added fields, because the previous value of the added field was no field, works well for removed fields bd($fieldgroup->getItemsAdded()); //gives all fields in the set for some reason bd($fieldgroup->removedFields); //this seems to work well }); If you have a use case for this there may be opportunities for PRs here. For example it doesn’t seem reasonable to me that removing a field tracks the change as "removed:<fieldname>" (plus the field itself as the old value) while adding one tracks as "add" without the field name (and no old value, because it was an add).

I just tested this: //ready.php /* Turn on tracking of changed values for all Templates. * Couldn’t find a hook for this, so I’m just iterating * all templates on every request. Should be fine? * Both calls to setTrackChanges() are needed. */ foreach (wire('templates') as $template) { /** @var Template $template */ $template->setTrackChanges(Wire::trackChangesValues); $template->setTrackChanges(true); } /* Dump tracked changes when Templates are saved, or * do whatever with them */ wire()->addHookBefore('Templates::save', function (HookEvent $event) { /** @var Template $template */ $template = $event->arguments(0); bd($template->getChanges(true)); //var_dump($template->getChanges(true)); }); This doesn’t get changes to a template’s fields, but you can probably do something similar with Fieldgroups and Fields themselves.

Hi, by “static pages” do you mean statically served HTML files generated outside of ProcessWire? Or do you want to add a blog to an existing ProcessWire site? I see you’ve been here for several months, so I’m assuming you’re somwhat familiar with PW. It should be a breeze to get a blog going. At its barest, it’s just a template with a title and a body field. For categories, there are different approaches you can go with, depending on how structured you want your data to be. Some blogs just have free-form textual tags, some have fixed categories that work like subdirectories, or anything in-between. Is there anything in particular you’re thinking about?

I’m gonna say Virtual Parents?

Hi @e0f! Skimming the latest replies in this thread it sounds like that should be possible with @thausmann’s prototype version: https://github.com/timohausmann/IcsGenerator/tree/multievents You can keep the .ics files around as static files that you only update when something changes (say, by hooking Pages::savedPageOrField) or you can just build them live for each request as you would any other page. Where do you want these files to live exactly? If these calendars are supposed to be private to each user, you’ll need to figure out how to authenticate requests originating from your users’ calendar apps. That may or may not be the biggest hurdle in this endeavour, since they’re probably not going to send the session cookies ProcessWire normally uses. Do you struggle with anything in particular?