interrobang

😲 I have no idea how context7's “related skills” are created. The complete setup, including the markdown conversion, is in the other repo https://github.com/phlppschrr/processwire-knowledge-base. The Python code for this is mostly vibe-coded with codex 5.2, and partly with gemini 3 pro. I have to admit that I haven't looked at the resulting Python code, but at least on my computer it works reliably. The repo indexed by context7 currently only contains the Markdown version of the ProcessWire API documentation as Markdown. As long as Ryan hasn't built prompt injecting into his phpdocs, it should be safe. I don't know yet how to best use the repository. I would appreciate input on how to write the skill to make the content usable for an LLM without bloating the context window. Probably the way via context7 is more promising than searching the local md files with grep. By the way, I've also started using gemini to break down the blog articles into individual, uniformly structured snippets with frontmatter metadata. I can imagine that this would be quite good for context7. However, it hasn't been committed yet. Unfortunately, I have to get back to customer work now... Example of a generated snippet:

Done. https://context7.com/phlppschrr/processwire-api-docs

Generates a .phpstorm.meta.php file for ProcessWire autocompletion in PhpStorm. Features Autocomplete wire container keys for wire('...') and Wire::wire('...') Autocomplete module names for Modules::get() and Modules::install() Autocomplete field names for Fields::get() Autocomplete template names for Templates::get() Autocomplete unique page names for Pages::get() Autocomplete hookable methods for Wire::addHook*() Autocomplete page status constants/strings for Page::status(), addStatus(), removeStatus(), hasStatus() Autocomplete field flags for Field::addFlag(), removeFlag(), hasFlag() Autocomplete template cache-expire constants for Template::cacheExpire() Autocomplete Inputfield collapsed constants for Inputfield::collapsed() Autocomplete sort flags for WireArray::sort()/sortFlags()/unique() and PageArray::sort()/sortFlags()/unique() Optional: Field type autocompletion per Page class (when enabled in module config) Usage Default path: site/assets/.phpstorm.meta.php (configurable in module settings). The file regenerates automatically when fields, templates, or modules change (debounced). You can manually regenerate from the module settings screen. Optional: enable "Generate page-class field metadata" in module settings for field type hints per Page class. This is intentionally basic. For richer field stubs, use AutoTemplateStubs. Examples Modules $tracy = $modules->get('TracyDebugger'); // Autocomplete + correct class type for navigation and code insight Wire Container $page = wire('page'); $pages = $this->wire('pages'); $cache = wire('cache'); // Autocomplete for keys like page/pages/cache/etc. Fields $body = $fields->get('body'); // Autocomplete field names, fewer typos Templates $tpl = $templates->get('basic-page'); // Autocomplete template names Pages $home = $pages->get('/'); // Maps to the page class when page classes are enabled Page Status $page->status(Page::statusHidden); $page->addStatus('draft'); $page->removeStatus(Page::statusUnpublished); $page->hasStatus('locked'); Field Flags $field->addFlag(Field::flagAutojoin); $field->removeFlag(Field::flagAccess); $field->hasFlag(Field::flagGlobal); Template Cache Expire $template->cacheExpire(Template::cacheExpireParents); Inputfield Collapsed $inputfield->collapsed(Inputfield::collapsedYesAjax); Sort Flags $items->sort('title', SORT_NATURAL | SORT_FLAG_CASE); $items->sortFlags(SORT_NATURAL); $items->unique(SORT_STRING); Page-Class Field Metadata (Optional) $home = $pages->get('/'); // $home is HomePage (page class) // Field types are inferred from the template fieldgroup // e.g. $home->hero_image -> Pageimage or Pageimages depending on field settings Hooks $wire->addHookAfter('Pages::save', function($event) { // Autocomplete hookable methods while typing the hook string }); Notes Hook scanning reads ProcessWire core, modules, and admin templates to build the hook list. If page classes are enabled, page names map to their page class; otherwise they map to Page. Improvement suggestions and PRs are welcome. https://github.com/phlppschrr/ProcessWirePhpStormMeta

Do you know if we can create our own repo that only contains the Markdown APIDocs and use it for content7, or does it have to be the official repo?

https://github.com/phlppschrr/processwire-knowledge-base

@gebeer I have started developing a ‘processwire-knowledge-base’ skill. To do this, I converted all blog articles and tutorials from the website as well as the API docs into Markdown. However, I haven't tested the skill yet. I think it still needs some fine-tuning. It's still a private repo at the moment, but if you're interested in taking a look, I'm happy to make it public.

@BitPoet Have you had time to look at the PR yet? Is there anything that needs to be adjusted? Has anyone else tested this version besides me? I haven't noticed any problems so far.

Hi all, I just opened two PRs for AutoTemplateStubs. First one adds/extends ProFields stubs (Table, Textareas, Multiplier, RepeaterMatrix, Custom) + some refactoring The second PR adds an optional PHPDoc injection into custom Page classes. It only edits a clearly marked region (//region AutoTemplateStubs ... //endregion). If the marker is missing, nothing is changed. If the class doesn’t exist yet, it creates an empty class with the marker. So it’s opt‑in and hopefully safe. Happy to adjust if needed.

In line with this topic, I recently expanded AutoTemplateStubs to include ProFields Stubs. There should be stubs for FieldtypeTable, FieldtypeTextareas, FieldtypeCustom and RepeaterMatrix (including stubs for all types). I haven't created a PR yet because I wanted to test it myself first, but since it fits so well with the blog post, if anyone would like to help with testing: https://github.com/phlppschrr/AutoTemplateStubs

I think the docs are generated with a custom module: https://processwire.com/blog/posts/processwire-3.0.41-and-a-look-at-api-explorer/

Wow, how time flies. This post is already 9 years old! The old syntax from the last post is now obsolete. But today you can do much more. I just looked at the file along with claude.ai and here is a new version. Edit: I've added all the core hooks and status codes to this file. Could be useful sometimes. But there's more, here's a little module that adds a few things to an extra phpstorm.meta.php. After installing the module you get suggestions for $fields->get('') // suggests existing field names $templates->get('') // suggests existing template names $modules->get('') // suggests existing module names + all hooks defined in /site/modules/

My main wish for ProcessWire 4 would be a generally more modern admin theme (e.g. with Ajax-Save unpoly/htmx style) and that at least fields that are also used in the frontend (FormBuilder) no longer have a jQuery dependency. On the subject of jQuery, it would also be great if the updates announced last year could also be activated for live pages in the next major release.

@ryanwill the updated jQuery and jQuery UI versions become standard in the next master? In a customer's pentest, only the outdated jQuery Ui library was criticized, but I'd rather not not enable $config->debug = 'dev' on the live site. Especially since this would not help in this case either, as the old Jquery UI version is loaded on the login page despite debug = 'dev'.

I just took a look at the source code and saw that in WireFileTools::render() all variables are added to data() of the rendered TemplateFile. You can get an array of the variables in your rendered file by $this->data(). Docs for data(): https://processwire.com/api/ref/wire-data/data/

for interest I asked chatgpt if this can be done in a single selector. here is the answer:

I have more and more customers complaining that they can't upload webp images. I understand that webp is not the ideal master image format, but neither is jpeg. The webp browser support is also so good now that it would not be necessary to generate jpeg/png versions from webp.

I don't know a solution using TinyMCE but I used a textformatter in a similar case. I used TextformatterPstripper.

Hi @ryan. The updates from FormBuilderFile sound great and I could very well use that in my current project. Is there any news when you will release this? Will the field also support drag and drop uploads? That would be even better ?

Thank you both, unfortunatelly I can't test your suggestions right now, because the site is still using PW 3.0.150, which doesn't has these options. Upgrading PW to the latest dev broke my site, so I had to return to the old version for now. But I could solve my issue for now by quoting the value in the selector. After updating PW I will try your suggestions. pages()->get("template=$templateName, parent=$parent, title=\"$value\"");

For an import script I need to match existing pages by page title, but some of the titles include a pipe. I cannot find a selector to get these pages. I have no idea what else to try. $title = "test | test"; // Non of these selectors get my existing page: pages()->get("template=edition, parent=3997, title=" . sanitizer()->selectorValue($title)); pages()->get("template=edition, parent=3997, title=$title"); pages()->get([ 'template' => 'edition', 'parent' => 3997, 'title=' => sanitizer()->text($title), ]);

The more I think about it, I am sure we need a core solution. Even if we hook into every Inputfield::processInput method we know of, there will still be custom inputfields which we will miss. And if you populate your pages by api Inputfields are not even used and the hooks are never called. UTF8 normalization should be buried somewhere deep in the core: Probably every mysql query and all user input should be normalized automatically. Currently this is not possible with hooks alone as far as I know. Btw, I just found another lightweight library which provides a fallback function if normalizer_normalizer is not available: https://github.com/wikimedia/utfnormal

Beware, a textformatter doesn't help with your search issue, as the texts in mysql are still the same and not normalized.

To be honest, I just googled a bit, I probably don't understand more of this than you ? Btw, Wordpress is discussing this now for 6 years: https://core.trac.wordpress.org/ticket/30130 Also, I don't know if this normalizer function is usually available or not – there are polyfills, but then all gets complicated. I am not sure if just saving is enough or if the fields need some changes tracked. Better test before re-saving 1000s of pages.

Without much testing this hook works for me (in site/ready.php). But I think utf normalizing should be part of the core text sanitizer, so other texts (like image descriptions) are normalized too. function normalize_UTF_NFC($string) { if (function_exists('normalizer_normalize')) { if ( !normalizer_is_normalized($string)) { $string = normalizer_normalize($string); } } return $string; } $wire->addHookBefore('InputfieldTextarea::processInput, InputfieldText::processInput', function (HookEvent $event) { /** @var Inputfield $inputfield */ /** @var WireInputData $input */ /** @var Language $language */ $inputfield = $event->object; $input = $event->arguments(0); if ($this->languages && $this->languages->count > 1) { foreach ($this->languages as $language) { $input_var_name = $language->isDefault() ? $inputfield->name : "{$inputfield->name}__{$language->id}"; $input->set($input_var_name, normalize_UTF_NFC($input->$input_var_name)); } } else { $input_var_name = $inputfield->name; $input->set($input_var_name, normalize_UTF_NFC($input->$input_var_name)); } $event->arguments(0, $input); });

WTF?! Sorry, you are right, this is not useful.