robert

Hi @Jorge, I think I found the bug causing your error, I mixed up the native _() and the Processwire __() function 😅 Fixed version is on Github, does this resolve your issue? https://github.com/robertweiss/PromptAI

Hi @Jorge, I‘m afk till friday but will have a look when I‘m back!

v1.1 has been released with some bug fixes and a ListerPro Page Action added to batch translate pages using the ListerPro module. Keep in mind that the Page Action module needs to be installed separately.

v1.6 released with one tiny change: the overwrite target field setting is now configurable per prompt instead of globally. This allows you to have some prompts that preserve existing content while others overwrite it, giving you more granular control over AI processing behaviour. Needed the functionality for a client, so I thought it would be a nice addition for the module.

Hey everyone! Just pushed two quick updates to PromptAI with some improvements: v1.4 Changes New "Overwrite Target" option: You can now choose whether AI responses should overwrite existing content in target fields (disabled by default to protect your existing content) v1.5 Changes Multiple template support per prompt: Configure a single prompt to work across multiple templates – no more duplicate configs! Native ProcessWire forms: Refactored config interface to use proper PW form elements Better template selection: Upgraded to ASMSelect for smoother template picking. This was a bit difficult to combine with dynamic JS fieldset creation and involved some brittle DOM hacking, so if anyone knows a simple way to combine Alpine JS and the ASMSelect JS part, I'd be happy to learn As always, please test thoroughly before going live. Bug reports and feedback welcome on GitHub 😊

v1.3 released with added support for Pagefile fields – now you can process documents with AI. This is especially useful for creating summaries, extracting key points, or generating descriptions for uploaded documents. Supported formats are PDF, RTF, Markdown, JSON, XML, CSV, and plain text files.

PromptAI v1.2 is out! New stuff: Repeater field support (including Repeater Matrix) – see the Readme for details Better config format using JSON and IDs instead of names Auto-migration handles the upgrade for you Your existing configs will automatically convert to the new format, so everything should just work. Still worth making a backup though 😄

PromptAI Module Update V1.1: New Config UI & Individual Buttons! 🎉 Hey everyonre, I just pushed an update to the PromptAI module that replaces the old textarea configuration with a proper form interface at Setup > Prompt AI. No more typing template::source::target::prompt manually – now you get actual fields and buttons like a civilized person! 😄 I also added an "Individual Prompt Buttons" option that lets you create separate "Save + [Custom Label]" buttons for each prompt configuration instead of one generic button. So you can have "Save + Create Summary", "Save + Generate Alt Text", etc. and run just the specific prompt you want. Existing configs migrate automatically, so updates should run smoothly. Feedback welcome as always. The module has now been added to the ProcessWire module list: https://processwire.com/modules/prompt-ai/

I created a successor for my module PromptChatGPT (https://processwire.com/talk/topic/28311-processchatgpt/) with the even more creative name PromptAI. It is more or less a complete rewrite based on the Neuron AI framework. Short description: PromptAI is a Processwire CMS module that utilizes AI to process text fields upon saving. The processed text can be saved back to the original field or a different one on the same page. For image fields, the AI can write image descriptions or populate custom image subfields. The main additions are: Multiple prompt support Provider select support System instructions Support for Image fields All infos can be found here: https://github.com/robertweiss/PromptAI Use cases could include text summaries, proofreading, or generating alt texts for images. Happy prompting 😊

Hello everyone, I'm excited to announce that Version 1.0 of ProcessTranslatePage is now available on GitHub: https://github.com/robertweiss/ProcessTranslatePage Please note that there are some breaking changes in this update. I recommend uninstalling and then reinstalling the module to ensure everything works smoothly. You can use the same DeepL API key that you use with Fluency. After installation, you will (hopefully) see two new fields for the language template. However, only the ⁠'translate_locale' field is required for the module to function properly. Thanks for your patience, I hope you find this update useful!

Hi @Ivan Gretsky and @FireWire, Sorry it took me so much time to respond to the big Fluency update. To be honest, I already refactored my module a couple of months ago to work without any dependencies (except the DeepL API), so Fluency is no longer necessary to use it. Since I only did this refactor for one client, I need to remove some customizations before I can push the new version to Github. I don’t expect this to take too long, so I’m hopeful that I’ll be able to release Version 1.0 for you to test tomorrow or thursday 😊. Thanks for your patience!

Yes, this seems to be the problem. ProcessTranslatePage works with the latest Processwire version, but not with Fluency V2 (yet). @FireWiresorry for the long wait, I did not have time to merge your PR yet, but thanks a lot for your effort!

I think I should add some infos about generating a working API key in the readme ?

Ok, I created a new account at Open AI and generated a test API key, then I got the same error message as you. After adding a payment method, still no luck. But then I generated a new key AFTER adding the payment method, and now it works. Could you check if that works for you too?

Hmm, this is weird. Does the error message already show up on the module config page or while saving a ›real‹ page and choosing ›Save + send to ChatGPT‹? For reference, the attached screenshot shows my feedback which works without errors.

Thanks for all of your comments and suggestions. I renamed the module to PromptChatGPT (thank you @gornycreative for the input!). The renamed repo can be found here: https://github.com/robertweiss/PromptChatGPT Additionally, I have included the composer vendor folder by default, which seems to be a better and easier way to distribute modules. Thanks to @wbmnfktr for bringing this to my attention. Regarding the curl/ssl errors, as you have already deduced, these seem to be linked to the external dependency https://github.com/orhanerday/open-ai. Therefore, if the issues you mentioned persist, we should consider creating a new Github issue there. For easier debugging, I have added a ›test settings‹ option to to verify if ChatGPT responds correctly. I have also included a new option to select templates that should include the dropdown option.

Valid point, I have to admit I never really noticed this was the reason for the ›Process‹ in the modules names. Thanks for the hint!

I couldn’t resist the hype and created a simple module using the ChatGPT API to process field values. You can find it on GitHub here: https://github.com/robertweiss/ProcessChatGPT ProcessChatGPT is triggered upon saving, if you select it in the save dropdown. It processes the value of a page field, which can be set in the module config, using ChatGPT. The processed value can be saved back to the same field or to another field on the same page, which can also be set in the module configuration. You can add commands to the value that will be prefixed to the source field content. This way, you can give ChatGPT hints on what to do with the text. For example, you could add ›Write a summary with a maximum of 400 characters of the following text:‹. One of my clients is already using the module to summarise announcement texts for upcoming music events on their website (Let’s face it, nobody reads them anyway ?). If anyone finds it useful, I would be happy to submit it to the official module list.

Translating only changed fields is quite a good idea, I just added it in v0.7 ? New radio option: Write Mode (replaces the checkbox Overwrite Existing Translation) Translate only if target field is empty Translate only changed fields Overwrite all target fields Caution: the »Changed fields«-option support is currently only one level deep. If you change any value inside a Repeater(-Matrix) or FieldsetPage field, the complete field will be translated. If anybody knows how to get the names of nested fields that changed inside the afterPages::saved hook, please let me know ?

@bernhardSure ? Module Config (sorry for the mixed labeling, I have the german language pack installed ? ): Publish + Translate to all target languages at once: Publish + Translate to single languages (on the left side of the arrow: source language, right: all available (aka not excluded) target languages):

v0.6 is released with the following changes: New setting: Source language (thx for the idea to @Ivan Gretsky and for the pull request to @theoretic) Languages for source and exclude can only be selected if they have been defined in the fluency config first I had to do some refactoring of the translation strings and the module config, so please validate/correct your settings after the update to v0.6!

@studioweb I had a deeper look into the page->name feature request and decided to not include the automatic translation of this field. As I suspected in my last post, there exists already a better solution for this ? If you install the module https://processwire.com/modules/process-setup-page-name/ and activate its option ›Update the name of existing pages‹, the name field will be updated in all languages whenever you change the corresponding field (normally title).

@studiowebThanks ? To prevent possible misunderstandings: you’re talking about the $page->name field, right? This is indeed a special case as it is the only translatable system field I could think of. I would suggest the following mechanism: only translate the page name if the target language name is identical to the source language (and therefore: not translated yet) – and allow users to switch it off in the settings to prevent possible conflicts with other modules modifying the name field on save (e.g. ProcessSetupPageName).

Oh cool, sounds good ? Your addition might be a good fit for the open issue by Ivan Gretsky: https://github.com/robertweiss/ProcessTranslatePage/issues/3 – would it be an option for you to fork my repository on Github so we can merge via a pull request?

Just released v0.5 which includes the following new features: Exclude fields: choose fields which should not be translated Exclude languages: choose languages which should not be translated to Show Single Target Language Buttons: Show all target languages as single buttons in the save dropdown instead of having only one button for all translations Thanks to @Ivan Gretsky for proposing these additions!