ryangorley

Thanks @markus-th and @wbmnfktr. You've given me good feedback to consider. I had an issue today with the headless WordPress site I referenced above that has me thinking about this differently. In short, the WPGraphQL plugin broke from an update and I decided to try converting what I had over to REST with Claude AI. In addition to a lengthy prompt I fed it JSON of all of the custom fields and GraphQL queries I was using on the site. That worked really well and only required minor fixes to completely rebuild what I already had. ProcessWire has great documentation, has been around for a long time, and can export templates and fields in JSON format. I just need structured data of each page, nothing wild. I'm going to see how well the machine can generate what I need and if it seems repeatable. If anyone cares I can post how it goes. If you're tired of the "LoOk aT WhAt i MaDe wItH Ai mOm!" posts, then I'll keep it to myself 😉

I'm sorry to resurrect this old thread, but it seems to be the most recent and authoritative discussion on this topic. I've been using an open source alternative to Webflow called Webstudio a lot more lately, especially for landing pages and microsites. It has no CMS, but can hook into any Rest/GraphQL API to serve dynamic content/pages instead. I've done that once now for a client using WordPress and the WPGraphQL plugin. I would much rather use ProcessWire as a headless backend for many reasons, not the least being its superb multilingual capabilities which I need. Is anyone currently using any of the solutions suggested in this topic, especially with multilingual content? It seems that some of these solutions have been abandoned. I don't even need an API per se, but just JSON formatted content, so at worst I suppose I can just write page template files to do that. But if someone has a better, tested method, I'd love to hear what you're using. Thanks!

No worries! If no one else has reported this issue, perhaps it's a host specific issue. It's pretty easy to set the plugin up, so not a big deal. Thanks for the fantastic plugin!

Not a burning issue, but when I migrate a site and DB between production and dev I get this error in the console log: fluency.bundle.js:194 [Fluency module API failure] Unexpected token '<', "<!DOCTYPE "... is not valid JSON u @ fluency.bundle.js:194 Promise.catch getTranslation @ fluency.bundle.js:140 (anonymous) @ fluency.bundle.js:2876 Once I uninstall and re-install Fluency it seems to work again. Just curious if you have any ideas what may be causing this issue or if there is an easy fix. If not, again, this isn't a serious problem, just an inconvenience. Note: By migrate I mean that I am running an rsync on the template/asset directories from one to the other and doing a complete DB dump and import.

@FireWire I feel bad, because there is a note at the top of the DeepL documentation page that says Traditional isn't yet available via the API, but I guess it will be at some point. Sorry for the false alarm, and thanks for looking into this!

Hey @FireWire, thanks again for this great module. Quick question. I'm not seeing Traditional Chinese as an option. It was recently added to DeepL. Does that need to be enabled in some fashion on your end?

Thanks @wbmnfktr! Yes, these are using ProCache. I forgot to mention that one, though I worked very hard to ensure uncached pages would be fast upon first visit, which I'm very satisfied with ProcessWire they are.

Hey All, I thought I'd jump on here and share my first 3 ProcessWire sites! LatticeWork (https://www.latticeworkinc.com/) - This one is live but still being actively developed in preparation for targeting an international audience (so current translations need auditing and it's not yet GDPR-compliant). The multilingual capabilities offered by ProcessWire, in contrast to WordPress, were the catalyst for starting my PW journey. The added performance that will be necessary as we deprecate some international sites and push everyone here was another decision driver for choosing PW. Obviously many thanks to @ryan and other core contributors for such an incredibly refined core product that regularly surprises me with features and functionality that I didn't know I was missing. Additional thanks go to @FireWire for the Fluency add-on, @Mike Rockett for Jumplinks, @Wanze for SEO Maestro, @teppo for Search Engine, and again Ryan for Pro Fields. These were invaluable. The Mart Group (https://www.martgroup.com/) - This site was my second to build with ProcessWire, though it was completed first due to its smaller size. In addition to all the prior thanks, I really appreciated RockFrontend by @bernhard while working on this one. Lori H. Cole (https://www.editsbylori.com/) - I probably wouldn't mention this single-page site I built as a favor, except to point out that PW is so lean and easy to work with I was able to give the client the ability to edit their own site without much server overhead or added development time. I did the front-end development work on these, which as a designer/animator hasn't historically been an area I'm comfortable in. ProcessWire has been such a delight to use that it has re-kindled my interest in working more with code. So, in time I hope to get more creative with the front-end coding as well. Thanks!

I'll add, perhaps for @ryan to consider, that an equally good solution would be for ProcessWire to borrow a behavior from elsewhere. In WordPress if I want to reset a slug I just clear the field and save the post. It then auto-populates that field from the post title as it does when the post is first created. In ProcessWire clearing the slug fields and saving the page just reverts the fields to their prior state. A small, but nice feature in WordPress I'd love to see in PW. :)

So, I've bumped into something worth considering. When I added more languages to my client's site the existing pages inherited the untranslated URL slugs from the default language. So I've got to go to the Settings for each page and manually click the translate from English button for each language to pull a translated slug. That's burdensome, but it seemed to be working... until I had to start translating a bunch of blog tags, then some slugs wouldn't translate. I couldn't figure it out until I realized that Fluency must be pulling a DeepL translation from the English slug, not the English title. You'd think it wouldn't matter, but it does. Here's an example: English > French: AI App > Application IA ai-app > ai-app It turns out DeepL translates ai-app to ai-app in every language. I don't think it knows what ai-app means so it just returns it. I don't know how commonly people will run into this problem, but I've been running into it a bit. Sometimes DeepL will return the slug unchanged, sometimes it will provide a slightly different translation than it did for the title. My suggestion would be for the slug translation prompt to use the default language page title when calling for a translation. I could see where pulling the title could create other surprises, such as when someone has the page title "Contact Us" but the slug "contact" they'll be getting longer slugs returned. Still I think that would be preferable to DeepL just silently failing. Maybe others feel differently. It's worth consideration though.

@FireWire Got delayed on my end, but I've uploaded and tested the update. It's working great. Thank you!

Thanks! I'll be able to test that tomorrow afternoon.

Okay, so I'm a little late on the testing side. I love the update! I'm having one issue, which probably has nothing to do with 1.07. The site I'm working on needs to be translated to Traditional Chinese for Taiwan (zh-tw) which isn't currently supported by DeepL and will have to be done manually. However, if I try to use Fluency when this language is added to the site it breaks with a console error: Uncaught TypeError: Cannot read properties of null (reading 'engineLanguage') at HTMLAnchorElement.<anonymous> (fluency.bundle.js:2812:110) Now, I presume this is because the language isn't mapped to anything in the Fluency module config. The behavior I would expect from Fluency is to just skip translations for languages not mapped, but that's not what it appears to be doing. Is that actually the problem, and is it something easily changed?

@FireWire At first glance, this looks great. I'll pull that dev branch version down and test it out as soon as I can. Thanks! Hopefully someone here has a good idea for the second issue. [fingers crossed]

@FireWire I'm still loving the convenience of this module, thanks! I've got a couple questions: When we add new languages to a site soon we're going to have empty language fields all over. If we use "translate to all languages" again to populate these blank language fields any manual edits to existing languages will be overwritten. How easily could the "translate from English" button be added back to co-exist alongside the "translate to all languages" button, so we could just pull individual translations without altering others when needed? Currently when a page is created and I translate the title, I'll have to add a space at the end of each translated title to prompt the page URL to reflect the translation. Would this be difficult to trigger automatically? If these are non-trivial changes, let me know what it would cost to sponsor the work. Thanks!

@FireWire This plugin has saved me so much time with a site I'm building for a client. Is there anywhere I can sponsor you or a way to send a few bucks your way?

@teppo I just wanted to let you know this plugin saved my life today. Thank you for building it! I just became a sponsor :)

@elabx @7Studio Thank you both for these in-depth suggestions and explanations. This has really helped a lot! @ngrmm Thank you also for pointing out this feature as well. What a great a community. I really appreciate you all!

Hey all, I'm coming from WordPress land, where blog posts, categories, tags, and publish scheduling are baked into the platform. ProcessWire is so amazing and flexible, but I'm kind of unsure about best practice for handling this. I'm migrating a site over with 100 blog posts, so I don't want to have to do it twice. This is how I expect things to work: Posts (pages) would be assigned to just one category (e.g. News, Guides, etc.) Posts could have multiple tags (e.g. iPhone Backup, Cloud Storage, etc.), and these would be shared with other posts across categories. An archive page would exist for each category (/blog/news/ or /blog/categories/news/) and each tag (/blog/iphone-backup/ or /blog/tags/iphone-backup/) listing all content. A copy writer could ideally add their own tags and see other tags have been used inside of the tag selector on a post. Categories will be predefined. A date can be selected for when the content becomes visible on the site, and a logged-in user can preview that content prior to that date. Categories: So I would imagine that the best way to handle categories would be to create sub pages of the blog page for each category and then create the posts themselves as children of the relevant categories, right? I'm mostly okay with that, though it's going to lead to longer URLs (/blog/news/this-is-a-somewhat-short-blog-post-title/). Not great for SEO, but acceptable if it's the best solution otherwise. Tags: This is the one I'm lost on. I haven't played with it yet, but I know there is a tag input field. I don't know if it is aware of existing tags so we don't get too much duplication (e.g. iphone, iPhone, Iphone, i-phone, etc.). I know I can figure that out, but if someone knows already and can share it would save me some time. The big question is how do I go about automatically generating archives of all the blog posts that share each tag? Tags need to be shared across categories, so the sub page method wouldn't work as a fallback. Someone must have figured this out, but I can't find anything documented. Publish Date: So I get that I can add a date field and build some logic into the queries to not show pages if today is prior to that value. I imagine I would use the $user ->isLoggedin() method to display the page content if today is prior to that date value as well. I don't love doing things this way because my sitemap (generated by SEOMaestro) is going to list these pages, and they are going to get indexed by crawlers as empty. I'm wondering if there is some better method for handling this functionality. -- Thanks in advance for the advice here!

@FireWire It is working great. Thanks again!

@FireWire Yes! That seems to have removed the error. Do I need to format those exclusions differently, perhaps?

@FireWire I get the same error translating both pages and via the menu. Nothing is reported in the `fluency-engine.txt` log file, however I am getting the following error in the `errors.txt` log each time I attempt a translation: 2023-10-16 14:30:46 freehive https://latticework.freehive.net/panel/fluency/api/translation/ Fatal Error: Uncaught TypeError: str_replace(): Argument #1 ($search) must be of type array|string, bool given in /home/latticework/webapps/latticework-pw/site/modules/Fluency/app/Engines/DeepL/DeepLEngine.php:313 Stack trace: #0 /home/latticework/webapps/latticework-pw/site/modules/Fluency/app/Engines/DeepL/DeepLEngine.php(313): str_replace() #1 [internal function]: Fluency\Engines\DeepL\DeepLEngine->Fluency\Engines\DeepL\{closure}() #2 /home/latticework/webapps/latticework-pw/site/modules/Fluency/app/Engines/DeepL/DeepLEngine.php(305): array_reduce() #3 [internal function]: Fluency\Engines\DeepL\DeepLEngine->Fluency\Engines\DeepL\{closure}() #4 /home/latticework/webapps/latticework-pw/site/modules/Fluency/app/Engines/DeepL/DeepLEngine.php(304): array_map() #5 /home/latticework/webapps/latticework-pw/site/modules/Fluency/app/Engines/DeepL/DeepLEngine.php(71): Fluency\Engines\DeepL\DeepLEngine->addIgnoredTags() #6 /home/latticework/webapps/latticework-pw/site/modules/Fluency/Fluency.module.php(791): Fluency\Engines\DeepL\DeepLEngine->translate() #7 /home/latticework/webapps/latticework-pw/site/modules/Fluency/Fluency.module.php(974): ProcessWire\Fluency->translate() #8 /home/latticework/webapps/latticework-pw/site/modules/Fluency/Fluency.module.php(950): ProcessWire\Fluency->apiTranslateEndpoint() #9 /home/latticework/webapps/latticework-pw/wire/core/ProcessController.php(361): ProcessWire\Fluency->executeApi() #10 /home/latticework/webapps/latticework-pw/wire/core/Wire.php(413): ProcessWire\ProcessController->___execute() #11 /home/latticework/webapps/latticework-pw/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #12 /home/latticework/webapps/latticework-pw/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #13 /home/latticework/webapps/latticework-pw/wire/core/admin.php(160): ProcessWire\Wire->__call() #14 /home/latticework/webapps/latticework-pw/site/templates/admin.php(18): require('...') #15 /home/latticework/webapps/latticework-pw/wire/core/TemplateFile.php(328): require('...') #16 /home/latticework/webapps/latticework-pw/wire/core/Wire.php(413): ProcessWire\TemplateFile->___render() #17 /home/latticework/webapps/latticework-pw/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #18 /home/latticework/webapps/latticework-pw/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #19 /home/latticework/webapps/latticework-pw/wire/modules/PageRender.module(574): ProcessWire\Wire->__call() #20 /home/latticework/webapps/latticework-pw/wire/core/Wire.php(416): ProcessWire\PageRender->___renderPage() #21 /home/latticework/webapps/latticework-pw/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #22 /home/latticework/webapps/latticework-pw/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #23 /home/latticework/webapps/latticework-pw/wire/core/WireHooks.php(1094): ProcessWire\Wire->__call() #24 /home/latticework/webapps/latticework-pw/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #25 /home/latticework/webapps/latticework-pw/wire/modules/Process/ProcessPageView.module(184): ProcessWire\Wire->__call() #26 /home/latticework/webapps/latticework-pw/wire/modules/Process/ProcessPageView.module(114): ProcessWire\ProcessPageView->renderPage() #27 /home/latticework/webapps/latticework-pw/wire/core/Wire.php(416): ProcessWire\ProcessPageView->___execute() #28 /home/latticework/webapps/latticework-pw/wire/core/WireHooks.php(968): ProcessWire\Wire->_callMethod() #29 /home/latticework/webapps/latticework-pw/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks() #30 /home/latticework/webapps/latticework-pw/index.php(55): ProcessWire\Wire->__call() #31 {main} thrown (line 313 of /home/latticework/webapps/latticework-pw/site/modules/Fluency/app/Engines/DeepL/DeepLEngine.php) I rolled the site back to PHP 8.1 in case this was a PHP version specific issue, but it didn't fix it. Hopefully this error helps. Thanks for the help!

@FireWire I'm building my first ProcessWire website, in large part because WordPress has been such a poor solution for clients who need multilingual sites. Your module has the potential to make ProcessWire amazing. Thank you! I have a couple questions: Will this be added to the ProcessWire modules directory at some point to make it easier to apply updates? I've added a DeepL developer API key, which seems to be working well enough to tell me my usage information from withing ProcessWire. I've tested my key using curl and it has returned translations. However I cannot get any translations to actually return to the site (see screenshot below). This does not appear to be browser specific. What suggestion do you have to debug this problem?

I'm a little late chiming in, but I'm building my first PW site and was looking to see if AVIF was supported and found this thread. I likewise am surprised this hasn't been requested more. AVIF is _much_ more impressive than WebP in my opinion. I would be happy if it behaved the same way as WebP support as described here: https://processwire.com/blog/posts/webp-images-in-pw/ I've yet to see an instance where AVIF was a larger image size than the source. Because browser support still isn't there on Edge, I'd want to use it with srcset fallbacks anyway.

I lived in Nederland many years ago and your portfolio made me home sick. :) Clean site and fantastic photography!