robert

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!

Hi Roych, thanks for your feedback! I found the bug – I falsely assumed that the default language id in processwire is always 1022 (which is obviously not the case …). I pushed a bugfix to the github repo (https://github.com/robertweiss/ProcessTranslatePage) and changed the version to 0.0.3. Could you try the bugfix and see if it works for you now?

I created a companion module for Fluency to translate all fields on a page at once: https://github.com/robertweiss/ProcessTranslatePage You can find the corresponding conversation about it in the Fluency thread (link below), but I decided to add the module to the official list so others who have a need for this have an easier time finding it.

Thank you, this would not be possible without your excellent module! I just pushed a new version to Github. The module got some additional features: A config page where you can exclude templates and toggle whether you want to overwrite already existing translations The language selection now uses the settings made in the Fluency config instead of having to configure it twice ? Support for more than one target language (I never needed that but thought it would be nice to have in the future) Support for the ProField Table About the performance: I share your concerns, but my client still forced me to do it ? The largest page I tested had 63 fields (25 textfields, 14 file-descriptions, 24 richtext-fields) and took about a minute to translate, so you really have to take care of the php timeout-settings. To bypass that, I added a small external translate-pagetree script to the repository which can be used in the command line, so you can batch-translate multiple parts of the website (or all of it) at once. As this is not tested very well, a database-backup is recommended before trying!

I’m not quite sure if this is of interest for anyone and if this is the right forum for my post, but I got the client request to build a module extension for Fluency which translates all the text fields in a page with only one click. The module is not really ready for public (or the modules section), as it has no config page yet and was only tested in one ProcessWire installation, but maybe it is useful as a starting point for anyone who is in the same situation as me: https://github.com/robertweiss/ProcessTranslatePage The module checks for fluency-translate permissions and adds a ›Translate and save‹-button to the edit-page. It supports all core language fields, Repeater, FieldsetPage the pro modules Repeater Matrix, Combo and Functional Fields. Caution: for now, the (language-)settings have to be manually edited in the hookPageSave-Method (Lines 64–69).

Hi @adrian, I changed the autoload to true according to your suggestion, so the properties will be added to the $page in the admin as well. Now I get the following error message from Tracy Debugger every time I open an admin page (no error shows up in the frontend): The weirdest thing is: when I duplicate my module and change the classname to something else (TestModule or similar), uninstall the original module and install the copy instead, the error is gone. And when if I remove all the code from the original class except the getModuleInfo method, the error is still there. I checked the behaviour in two other installations, they show the same error. Maybe this is some sort of race condition with autoload modules? I tried to understand the OutputDebugger class mentioned in the error, but did not yet figure out what it does or how it can help ? This issue has no priority at all, but maybe you have an idea where I could look further. Debugging the debugger … ?

Hi @adrian, first of all thanks a lot for your fast and nice reply, this community is always so helpful and motivating! 1) Good idea, I never really used it that way, but I definitely will check it out and change the autoload setting. 2 & 3) Thanks for the hints, I changed the code as you suggested. 4) You are right – in combination with Tracy and usual field configurations, the difference is mostly a formatting preference. As I like using Ray in an external window for debugging, the module helped me to always get identical informations in different environments. Another thing which was important to me is the support for ›subfields‹, so that I can immediately see the content of repeater matrix items inside repeaters inside fieldset page fields etc. etc. (you see the point … ?). The third thing is – as you already mentioned – the support for all kinds of fieldtypes in a more or less consistent and simplified way.

I often had the need for an overview of all used fields and their contents for a specific page/template while developing new websites without switching to the backend, so I made a small module which lists all the needed information in a readable manner (at least for me): Debug Page Fields https://github.com/robertweiss/ProcessDebugPageFields It adds two new properties to all pages: $page->debugFieldValues – returns an object with all (sub-)fields, their labels, fieldtypes and values $page->debugFieldTypes – returns an object with all fieldtypes and their corresponding fields // List all values of a pages $page->debugFieldValues // List a specific field $page->debugFieldValues->fieldname // List all used fieldtypes of a page $page->debugFieldTypes I recommend using it in combination with Tracy Debugger, Ray, Xdebug etc. as it returns an object and is only meant for developing/debugging uses. For now, the fieldtype support includes mostly fieldtypes I use in my projects, but can easily be extended by adding a new FieldtypeFIELDNAME method to the module. I use it with five different client installations (all PW 3.0.*), but of course there might be some (or more) field configurations which are not covered correctly yet. Supported fieldtypes Button Checkbox Color Combo Datetime Email FieldsetPage * File FontIconPicker Functional Image ImageReference MapMarker Multiplier Mystique Options Page PageIDs PageTitle Radio Repeater * RepeaterMatrix * RockAwesome SeoMaestro Table Text Textarea Textareas Toggle URL * The fields with complete subfield-support also list their corresponding subfields. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. As this is my first ›public‹ module, I hope I did not miss any important things to mention here.

Hi Adrian, you are absolutely right! As soon as I switch output formatting off, the results are identically. Thanks for the fast clarification ?

What a coincidence! Just one second after my post, I found this topic and horsts answer helped me as well. Thanks a lot, horst! ? I still don’t understand why there were differences between command line and browser, but when I add $img->first()->filename, I get identical results (although the maximum file amount in the imagefield was set to 1, btw).

I’m trying to get the filename of a file in an imagefield via command line, but there seems to be a difference between the API access via browser and via command line. When I try the following (reduced case): $img = $pages->get('/')->name_of_imagefield; var_dump($img->filename); var_dump($img->basename); var_dump($img->url); var_dump($img->path); I get these results: Browser (as expected): filename: full path to file including name (e.g. /var/www/public/site/assets/files/1/filename.jpg) basename: only name without path (e.g. filename.jpg) url: webroot-based path to file including name (e.g. /site/assets/files/1/filename.jpg) path: NULL Command Line: filename: NULL basename: NULL url: webroot-based path to file WITHOUT filename (e.g. /site/assets/files/1/) path: full path to file WITHOUT filename (e.g. /var/www/public/site/assets/files/1/) What am I missing? Or is this normal behaviour and I just never noticed before? The website is running Processwire 3.0.94 with PHP 7.0. Thanks a lot for any help!

Hi Henning, I had similar problems with 1&1 and fixed them by installing PW locally, then moving everything to the server (db via phpmyadmin), changing the config.php with the 1&1 db-credentials and finally adding the following line in the config: $config->dbSocket = '/tmp/mysql5.sock'; Not sure where I found it, but worked for me