All Activity

Hi everyone! Just wanted to get a general feel on the documentation pages of the new website, is anyone else finding troublesome that the main sections of the documentation are now collapsed? Weren't these sections "less collapsed" or maybe I an hallucinating (i know it's in fashion) ? Wouldn't it just be better to have all of this expanded, in a big chunk of text? I really feel it makes it hard to use the documentation pages, wouldn't it just make more sense to have submenus under the API variables? Here's a quick mockup of what I think could be a more pragmatic layout:

Revisiting this topic again... I want to use vanilla CSS as much as possible moving forward, but I'm trying to find a "base" from which to start. This base would come with an opinionated way of organizing files, a reset, breakpoints and perhaps stub-out certain components and use all the latest CSS features. I can't seem to find anything like that and that's also pretty recent. Any suggestions?

👍Then use "Schlagwort / Schlagwörter".

Hmm, interesting. Thanks @pideluxe I actually have Tags reserved for a different part of the Module. So just to recap Tags = used for front end display like you probably already understand. Tagging images in an images field. Labels = similar purpose but used for Library organisation in the admin area

Actually, we use "Etiketten" just for physical labels. One could use "Schlagwort / Schlagwörter" or "Tag / Tags" for more tech-savy users.

Thank you in advance! Nothing is urgent, of course :)

I'll change that as soon as I've time.

BTW is this the best translation for Label and Labels? Google seems to suggest a few variations Label → Etikett Labels → Etiketten P

Hi If you are using 1.19.50 Beta, you may have experienced 2 translation issues. These are fixed and scheduled for the official 1.19.50 release, but if you're stuck, please DM me. German language CSV import fails with 'Undefined array key' warnings German translation: glossary fix — Label → Etikett, Labels → Etiketten Vielen Dank fürs Lesen, i believe 🙂

ok... it seems that this is not the problem, and we've moved on.

I am trying to learn php and "proper" dev practices (terminal, git, staging). My background is in no-code apps, but I have a solid knowledge of HTML and CSS. I started building a personal site on Neocities, very nice, but I realised that I needed a CMS. ProcessWire has been fabulous so far, while I've been creating files on my live hosting (LOL). I'm using Ai to help guide me through the "proper dev" practices, and honestly, it's been great. But now we're stuck. I'm trying to load my site locally. I've been getting various errors, blank screens. Ai insists that I need bootstrap.php and I need to get a fresh install of PW. When I look at the files in PW, there is no bootstrap.php. This page https://processwire.com/docs/front-end/include/ mentions bootstrapping, but no mention of the "missing" bootstrap.php file. Any ideas?

Nice! Thanks for the quick implementation! I'll give it a try and test a bit.

hi, wow, being french, a night later, i was about to say well the solution would be to create a custom field relying on pw getSelectablePages and something like tom select that allows lazy loading in the select but what @Jonathan Lahijani made is simply awesome!!! have a nice day

I must say, I really like this field. Wow... I'm impressed with GPT 5.5 and Codex CLI.

I made a few LOT more updates and I think it's ready to share for testing. I'm attaching it here as a zip for now (v88), but will publish to GitHub when I think it's ready. Edit: I have not really tested this as far as the configuration options go. My focus was mainly on functionality and UX. Obviously, don't use this on a production site, only test sites for now. Edit: it now works well in both Konkat (aka Default) and Core (aka Original) admin theme. InputfieldPageModalSelect-88.zip

Another verge large update with all the UX stuff: https://youtu.be/Xu6O84oUQKU

@jploch Good idea! It's been added.

@DrQuincy Here's a video of a concept field I made called InputfieldPageModalSelect. Let me know your thoughts and suggestions!

I agree with this. A new type of multi-select inputfield for page references for advanced use cases would definitely help. I know Shopify has some unique, purpose-built multi-select fields (like when choosing products/variations). But it doesn't let you search options that have been specifically selected. I didn't see anything generic from CMSes like Payload, Statamic, CraftCMS, Kirby or Laravel Filament. Have you seen anything in any other systems that solves this well?

Yes, that's great, I have used that, thanks. I'm particularly interested in managing 100s to 100s of references.

Hi, if your page reference field is used for a single page selection, you may choose "page auto complete" in the input->input field type select, it is ajax powered and works very well 🙂 the only big difference is that you have o know at least 2 or three letters of the page title you're looking for it works great too with a hook (custom php code) allowing you to select several parents, templates and so on if needed have a nice day

I just wanted to check this is okay before I roll it out. I'm pretty sure it is but I wanted to be sure. Let's say you have: Parent page [template=parent] Child page [template=child] In the back end site tree if I want Child page to be viewable and editable by the current user but I don't want Parent page to show in the site tree. If I remove all view permissions for template=parent but allow for template=child, will they still be able to view Child page and edit it (if I supply them with the direct link)? I stupidly asked AI this question and it's adamant permissions are inherited regardless so if you can't view a parent there's no way at all to view the child. 🤔

For the record: this seems an issue that started occuring in 3.0.265. All previous versions have not resulted in this problem. We are now sticking to the master branch only.

From a database perspective page reference fields should scale quite well and there's always the option to build a custom table managed with hooks if you need something ultra fast so you have control of the indexes. But, in the admin, is there any field type that scales well? I've tried them all out and from what I can see, all page reference field types and input types, do not have the option to show your page references in a searchable, paginated lit loaded by AJAX; they all go in a single list. I can imagine this getting problematic once the number of page references gets moderately big. Is there such a thing? What do you do if you have 100s of references, 1000s of references or more? At what point are the standard page reference fields no longer an option?

A Jumplinks successor would be awesome…