FireWire

@bartelsmedia Back with good news a year and a half later... I am working on a ProcessWire DeepL integration. I just posted details about it today with a full rundown, screenshots, and an alpha version download. This thread stuck with me and I kept checking back with DeepL to keep tabs on their API availability and as of spring 2020 they are allowing subscriptions from within the US. It only costs $5.49 per month and is worth every penny. I'm going to be launching a new website for our company in the next few weeks so I'll be using it in production and refining it. Really glad this came in time for that project because it's going to save a lot of headaches! If anyone wants to spend a couple of bucks on an API subscription, download the module, and help out with testing it would be great to get feedback. Read more about it here on this post

Hello community! I want to share a new module I've been working on that I think could be a big boost for multi-language ProcessWire sites. Fluency is available in the ProcessWire Modules Directory, via Composer, and on Github Some background: I was looking for a way for our company website to be efficiently translated as working with human translators was pretty laborious and a lack of updating content created a divergence between languages. I, and several other devs here, have talked about translation integrations and the high quality services now available. Inspired by what is possible with ProcessWire, I built Fluency, a third-party translation service integration for ProcessWire. With Fluency you can: Translate any plain textarea or text input Translate any TinyMCE or CKEditor (inline, or regular) Translate page names/URLs Translate in-template translation function wrapped strings Translate modules, both core and add-ons Installation and usage is completely plug and play. Whether you're building a new multi-language site, need to update a site to multi-language, or simply want to stop manually translating a site and make any language a one-click deal, it could not be easier to do it. Fluency works by having you match the languages configured in ProcessWire to those offered by the third party translation service you choose. Currently Fluency works with DeepL and Google Cloud Translation. Module Features Translate any multilanguage field while editing any page. Translate fields in Repeater, Repeater Matrix, Table, Fieldset Page, Image descriptions, etc. Translate any file that added in the ProcessWire language pages. It's possible to translate the entire ProcessWire core in ~20 minutes Provide intuitive translation features that your clients and end-users can actually use. Fluency is designed for real-world use by individuals of all skill levels with little to no training. Its ease-of-use helps encourage users to adopt a multilanguage workflow. Start for free, use for free. Translation services supported by Fluency offer generous free tiers that can support regular usage levels. Fluency is, and will always be, free and open source. Use more than one Translation Engine. You may configure Fluency to use either DeepL, Google Cloud Translation, or both by switching between them as desired. AI powered translations that rival humans. DeepL provides the highest levels of accuracy in translation of any service available. Fluency has been used in many production sites around the world and in commercial applications where accuracy matters. Deliver impressive battle-tested translation features your clients can count on. Disable translation for individual fields. Disable translation for multilanguage fields where values aren't candidates for translation such as phone numbers or email addresses Configure translation caching. Caching can be enabled globally so that the same content translated more than once anywhere in ProcessWire doesn't count against your API usage and provides lightning fast responses. Set globally ignored words and text. Configure Fluency to add exclusionary indicators during translation so that specific words or phrases remain untranslated. This works either for specific strings alone, or present in other content while remaining grammatically correct in translation. Choose how translation is handled for fields. Configure Fluency to have buttons for either "Translate from {default language}" on each tab, or "Translate To All Languages" to populate every language for a field from any language to any language you have configured. No language limits. Configure as few or as many languages as you need. 2, 5, 10, 20 language website? Absolutely possible. If the translation service you choose offers a language, you can use it in ProcessWire. When new languages are introduced by third parties, they're ready to use in Fluency. Visually see what fields and language tabs have modified content. Fluency adds an visual indication to each field language tab to indicate which has different content than when opening the edit page. This helps ensure that content updated in one language should be updated in other languages to prevent content divergence between languages. Render language meta tags and ISO codes. Output alt language meta tags, add the current language's ISO code to your <html lang=""> attribute to your templates that are automatically generated from accurate data from the third party translation service. Build a standards-compliant multi-language SEO ready page in seconds with no additional configuration. Render language select elements. - Fluency can generate an unordered list of language links to switch between languages when viewing your pages. You can also embed a <select> element with JS baked in to switch between languages when viewing your pages. Render it without JS to use your own. Manage feature access for users. Fluency provides a permission that can be assigned to user roles for managing who can translate content. Track your translation account usage. View your current API usage, API account limit, and remaining allotment to keep an eye on and manage usage. (Currently only offered by DeepL) Use the global translation tool. Fluency provides translation on each field according to the languages you configure in ProcessWire. Use the global translation tool to translate any content to any language. Use Fluency from your templates and code. All translation features, usage statistics, cache control, and language data are accessible globally from the $fluency object. Perform any operation and get data for any language programmatically wherever you need it. Build custom AJAX powered admin translation features for yourself. Fluency provides a full RESTful API within the ProcessWire admin to allow developers to add new features for ProcessWire applications powered by the same API that Fluency uses. Robust plain-language documentation that helps you get up to speed fast. Fluency is extremely easy to use but also includes extensive documentation for all features both within the admin and for the Fluency programming API via the README.md document. The module code itself is also fully annotated for use with the ProDevTools API explorer. Is and will always be data safe. Adding, upgrading, or removing Fluency does not modify or remove your content. ProcessWire handles your data, Fluency sticks to translating. Full module localization. Translate Fluency itself to any language. All buttons, messages, and UI elements for Fluency will be presented in any language you choose for the ProcessWire admin. Built for expansion. Fluency provides translation services as modular "Translation Engines" with a full framework codebase to make adding new translation services easier and more reliable. Contributions for new translation services are welcome. Fluency is designed and built to provide everything you need to handle incredibly accurate translations and robust tools that make creating and managing multi-language sites a breeze. Built through research on translation plugins from around the web, it's the easiest and most friendly translation implementation for both end users and developers on any CMS/CMF anywhere. Fluency complements the built-in first class language features of ProcessWire. Fluency continues to be improved with great suggestions from the community and real-world use in production applications. Big thanks to everyone who has helped make Fluency better. Contributions, suggestions, and bug reports welcome! Please note that the browser plugin for Grammarly conflicts with Fluency (as it does with many web applications). To address this issue it is recommended that you disable Grammarly when using Fluency, or open the admin to edit pages in a private window where Grammarly may not be loaded. This is a long-standing issue in the larger web development community and creating a workaround may not be possible. If you have insight as to how this may be solved please visit the Github page and file a bugfix ticket. Enhancements Translate All Fields On A Page Compatibility with newest rewrite of module is in progress... An exciting companion module has been written by @robert which extends the functionality of Fluency to translate all fields on a page at once. The module has several useful features that can make Fluency even more useful and can come in handy for translating existing content more quickly. I recommend reading his comments for details on how it works and input on best practices later in this thread. Get the module at the Github repo: https://github.com/robertweiss/ProcessTranslatePage Requirements: ProcessWire 3.0+ UIKit Admin Theme That's Fluency in a nutshell. The Module Is Free This is my first real module and I want to give it back to the community as thanks. This is the best CMS I've worked with (thank you Ryan & contributors) and a great community (thank you dear reader). DeepL Developer Accounts In addition to paid Pro Developer accounts, DeepL now offers no-cost free accounts. All ProcessWire developers and users can use Fluency at no cost. Learn more about free and paid accounts by visiting the DeepL website. Sign up for a Developer account, get an API key, and start using Fluency. Download You can install Fluency by adding the module to your ProcessWire project using any of the following methods. Method 1: Within ProcessWire using 'Add Module From Directory' and the class name Fluency Method 2: Via Composer with composer require firewire/fluency Method 3: Download from the Github repository and unzip the contents into /site/modules/ Feedback File issues and feature requests here (your feedback and testing is greatly appreciated): https://github.com/SkyLundy/Fluency/issues Thank you! ¡Gracias! Ich danke Ihnen! Merci! Obrigado! Grazie! Dank u wel! Dziękuję! Спасибо! ありがとうございます！ 谢谢你

Having a rough go with performance and figuring out how to diagnose issues. I noticed that as I was building out a template that the load times on my local dev environment continued to get slower and slower. Basically slower than browsing the internet. I recently picked up the Pro DevTools modules and started working from the Profiler and the results have been pretty bad. I'm using the Twig Template Engine. It is taking ~1.5 seconds for the server to render the page before returning anything to the browser. I started to work backwards through my code and I cannot find where there would be issues that should be causing this much of a slowdown, I wasn't able to get speed differences by disabling modules and I don't think that I'm running anything that would conflict. I went through my templates and partials and started commenting out loops. I have a few loops on the home page to render picture grids, a blog feed, and navigation in both the footer and the header. There aren't any calls to modules or special functions that are happening inside these loops. When studying the output of Profiler there's no indication that anything is booting up during the page rendering process either. By commenting out all of the loops it dropped the render time from ~1.5s to .3-.5s, which is still slow for ProcessWire. I've attached two screenshots of the Profiler output for comparison. Everything below the cutoff in the picture had zero execution time. I'm not experiencing any slowdown on other local sites. Appreciate any help! Currently running: ProcessWire 3.0.164 Master TemplateEngineFactory v2 TemplateEngineTwig v3 PHP 7.3.13

Changing the method visibility fixed the issue. I don't know how I overlooked it. This is officially the most embarrassing thing I've posted on any support board... ever. Ha! That was totally an accident as I've written other page classes and minded the private/public declaration. Hope this ends up helping others! Thanks!

Hey all. I'm having an issue with the new custom page classes feature which is a fantastic tool. I am running into a recursion issue when attempting to call a custom page class. I have a class called BlogPostPage.php (for blog-post.php) which contains a method called getSummary(). That method gets a summary field or truncates the body in it's absence. I've attached photos of the template code, custom page class code (which I've simplified for testing), and the PW output error. There is no recursion in the getSummary() method. This error occurs whether I output multiple blog posts in a loop or if I output one blog post with no looping in my template code. In use: ProcessWire 3.0.164 dev PHP 7.3.13 I am also using the Template Engine Twig module which has not caused any errors or issues thus far. Many thanks!

^This guy! Big thanks to that effort on your part. Another reason to love the PW forums... Here's something that would be pretty great- a companion to the Modules directory that serves to be a repo for snippets like this. I know there are a lot of people whipping up fixes for odds and ends that never got a proper module, are a module but need more work to integrate, or don't need one at all to work. Like a place for pure ProcessWire gists- or even just a directory of links to gists. If you want to whip that up and reply with it that would be great ?

Well- I live in California and I heard about the CCPA (California Consumer Privacy Act) and had to look it up. When I found the rules it put in place I remembered why- the requirements for entities having to comply with it are well outside of most companies. (Sharing the details here for anyone who stumbles upon this thread). Businesses that earn $25,000,000 or more a year in revenue Businesses that annually buy, receive, sell or share personal information of 50,000 or more consumers, households or devices for commercial purposes Business that derive 50% or more of its annual revenue from selling consumer personal information Basically- Google, Facebook, Twitter, etc. are located here in California and this was targeting them. Apart from that politicians in America and the states within it basically dilute legal measures or do nothing at all. We're lucky in California we even got that. I also had to look up the EU-US privacy law and from what I understand that was basically the U.S. telling the EU that their privacy laws do not protect any American citizen in the EU (surprise). You're totally right about American companies operating with respect to actual EU citizens though.

Never knew about that module. Good share. Outside of having the manually coded implementation, an integrated approach would be great for those who aren't strong back end developers and wouldn't be comfortable digging into hooks. There is value in the behavior. One of the big draws of PW is it's raw power combined with ease of use which puts this kind of feature within the hands of developers like you and I but beyond many others. I couldn't find this module being listed anywhere that could be found. Is it something that you put together? If it's used by someone then having proper attribution is something that would be a good practice to keep going (myself included). Thanks again for the share.

100% don't think it's pedantic. I think this needs to be part of the conversation for developers who look to implement features that are truly needed for a website to function well while considering security. As a dev in the U.S. we have a data free for all over here- but one day I might build a site/app with an international focus- other devs as well.

I think @wbmnfktr may have a good point on scalability and load handling. It's curious because they have been around long enough to break into the American market and their performance is so good that I'd have expected an acquisition by now. Very odd indeed. Whether technical, financial, or bureaucratic, the fact stands that they've been around long enough to go into the American market- they just haven't. If they're citing tax purposes either it's a f****-off answer, or they're just trying to do it now. I'm an American and I run VPSs in the EU with a subscription model which would be similar. There's too many variables here to even guess.

You only have to send the domain, so your GET request would be: https://open.kickbox.com/v1/disposable/mailinator.com I'd write a server side validation script that makes a call to that endpoint and also have that script return data to AJAX requests. You get server side validation as well as a way for your client side validation scripts to make an AJAX call to your own server so your user's IP address is never exposed to a third party site either. If you wanted maximum privacy for your users.

That looks like it's only good for Payoneer to Payoneer payments where both parties have an account. Kind of a bummer- I had already started working on a module before I ran into this problem. I'll pick it back up if/when the service becomes available in the U.S.

I always prefer an API when available to keep the information up to date and future friendly and The link @bartelsmedia posted looks like it's dead. This repo maintains an updated list, but also provides a link to an API that lets you check a domain on-demand. https://github.com/ivolo/disposable-email-domains The API is simple, send a GET request here https://open.kickbox.com/v1/disposable/{DomainOrEmailAddress} and it will return a JSON response like {"disposable": true} (or false) I think that using a live service is preferable to relying on PW to continually update an internal database unless there's a special use case. Integrating this feature into the Pro form-based modules would be great.

I looked into this and one of the limitations that their website does not say is that this API is not available to anyone purchasing access from the U.S. This basically is a dealbreaker for a lot of people and the implementation would mean it's limited to a very small number of people. Modules essentially would only be useful to someone that can purchase using billing addresses in the EU. I briefly considered some sort of credit card fraud... but passed haha. I was really interested in DeepL and went to sign up for the API to get access to it and only found out that I couldn't buy access to it when I went to enter my CC information. Very disappointing that they did not say this anywhere on their website (I checked). I spoke with them this week so the information is up to date on this finding. I sent an email to their staff and they said they are working on making it available outside of the EU but that it isn't due to "tax reasons". They didn't give any sort of timeline so until some point in the future this would only be available to users there. Big bummer.

That's a great idea. I'm going to add some information to the configuration screen with recommendations and information on that as well. Would this benefit from creating a post in the Modules/Plugins forum since this one is in the Module/Plugin Development forum? I initially wanted to see if there's any critiques or feedback that showed it wasn't ready for primetime but I think it is.

Hey everyone- We recently had a need come up for a website. After launching our website the company hired an SEO specialist who is doing some significant work revising and optimizing content. To help enhance this process I wrote a very simple module that automatically submits the website's sitemap.xml file to Bing and Google when a page is published, or when a page is saved that was already published. As for our reasoning- there's a lot of information available as to why submitting your sitemap regularly can be beneficial. In classic Google style their official documentation says that there "is no guarantee" that submitting a sitemap alone will trigger a re-indexing by Google's bots. That said, devs have done tests where there is a strong correlation between a sitemap submission and activity by Google bots on that website. Google has stated that there is no limit or cap on the number of times you can submit a sitemap so there is no penalty for triggering this for every change. For more details and the hard science visit this excellent article https://trevorfox.com/2018/09/ping-sitemaps-search-engines/ 2021 Update! This module has been rebuilt almost entirely to perform even better and cover more events that can affect sitemap.xml data which makes it more effective for your SEO performance. Previously the module submitted the sitemap.xml URL when a page was saved but has now been expanded to encompass any event that potentially modifies your sitemap and does it more intelligently. These events include: New page is published - New URL created Existing page is unpublished - URL no longer available Existing page is saved - Content on page may have changed Existing page is moved - URL has changed Existing page is deleted - URL no longer exists Existing page is restored - URL is now available ProcessSitemapSubmit also: Checks if sitemap.xml exists/is available Logs submissions and results to sitemap-submit log Allows for the sitemap URL can be specified, defaults to yoursite.com/sitemap.xml Templates can be excluded for pages created/saved that should not be submitted to search engines Hidden pages do not trigger a submission. Supports Bing and Google As always, I'd never share a module with the community that I haven't used in production but I still ask that you test and ensure that it works for you. The repo for this module has a notice that it is still in development but I am going to bring it to a release and add it to the Modules directory soon (i.e. when I have a spare minute). This module should have little to no risk and the best way to test is to check the sitemap-submit logs for successful submissions. I am a big fan of the Sitemap module by @Mike Rockett and use it on all of my sites. The Sitemap module uses caching to deliver your sitemap.xml file efficiently. I've worked with Mike to update his module so that it allows ProcessSitemapSubmit to clear it's cache and deliver the latest changes to search engines. This module is aware of Sitemap and works with zero configuration out of the box. To get this functionality in tandem with ProcessSitemapSubmit, please update the Sitemap module on your site. The Sitemap module is not a requirement for this module to work as long as your website has an available sitemap.xml to submit. Check it out. https://github.com/SkyLundy/ProcessSitemapSubmit Feedback and bug reports welcome!

@horst Thank you for that code. I was able to ensure that the language was being delivered properly. It turns out that the tech managing our in-house web server had very very aggressive caching enabled through Nginx and purging the entire site's cache fixed the issue. The issues that were coming up didn't look like a caching issue so it was odd. Had odd URL issues and redirect looping. General recommendation to everyone is check with your server admin when all hope is lost...

I do remember checking that the URL was enabled on the Home page so it should be available on all of the children pages as well- which has been what I've experienced before. Thanks for the code snippet- I'll start with that to start troubleshooting.

Hello everyone. I have a multi-language site that has an issue with redirecting the user to the default language if they are not logged in regardless if they have visited a url for another language. When I am logged in I am able to visit either language fine. When I'm not logged in I get a 302 redirect to the default language. Example: /es redirects to / if I'm not logged in.

Good to know. $this->getLangFromCookie() returns a string and is shared by other methods in the same/other classes. I could probably refactor it to work directly with the language object, but I'll have to come back to that sometime. Appreciate that info.

Added that to a comparison and that did the trick! Here's the method after adding your trick: private function doInitLocalization() { $page = wire('page'); $user = wire('user'); $input = wire('input'); // Get/set user language from either browser or cookie $user->language = $this->getLangFromCookie() ?: $this->getValidBrowserPrefLang(); $urlSuffix = str_replace($page->url, '', $input->url(true)); $userUrl = $page->localUrl($user->language) . $urlSuffix; if ($_SERVER['REQUEST_URI'] !== $userUrl) { header("Location: {$userUrl}"); } } getLangFromCookie() checks if the user has visited previously and selected a language from a dropdown. getValidBrowserPrefLang() gets the language pref sent by the browser, if it exists as a language in the CMS, returns the value. By setting the language for the user this checks against what the browser request asked for/server is delivering vs. what the CMS knows it should be delivering. If they differ, then redirect. This is executed in _init.php so any point of ingress is checked for url vs. preference. Thanks @kongondo for introducing me to $input->url and the good idea for direction. Thanks @Soma for concluding my head->desk marathon. Your solution is the simple one I couldn't see.

That sets the user language properly but getting the $input->url(true) still gets the non-localized version of the URL so it doesn't redirect to the translated page. It loops and fails the redirect. Also the language move has been a little rough because using the code below seems to lead to a possible solution but is where I was hitting the paging/GET issues. $languages->setLanguage(-lang str here-); // Also sets the language as a $user->language assignment does $page->localHttpUrl($user->language); // Returns the proper localized URL, but does not include pagination or GET vars I've seen many posts in the forums about redirection to a language and all of them use $page->localUrl($user->langauge) and none consider GET vars. Multi-language documentation says that the $page->localUrl() will automatically adjust to pagination but I haven't seen it. Would still have to manually build GET vars.

Yeah, I'm not explaining my situation well enough and it's becoming a little more complex. I'm working on abstracting localization to a class where one of the methods is used to redirect the user to their preferred language. That preferred language is either the language preference they have set in their browser, or a language cookie that was set last time they visited and selected a language via a select dropdown in the nav. That said, since the method is run on page load it will not have any access to specific pagination instances because they don't exist yet. I read the link above and didn't see a solution that covers all of the bases and the module reference in a link to another post is no longer maintained, so I am going to write a custom implementation. Here's my solution: Language detection will be tied to a unique session variable. On page load, the script checks for that session variable, if it exists- it exits because the language has been checked/redirected if necessary on ingress already. If no language session variable exists, then compare the destination URL against the URL of that page for their preferred language. If the URLs do not match then build a new URL The destination URL is checked for page numbering using $input->pageNum(), if > 1 then create a URL string for that. Any GET variables are extracted and rebuilt into a string- this preserves any possible incoming variables like UTM trackers. Get localized URL for user's preferred language, re-add page number, re-add any GET variables that existed. Set unique language session variable, then properly redirect to the localized page using the build URL. I kind of wish that there was a built in method that could wrap most of this up and preserve URL details while redirecting to a given translated page, but this should work and also only redirect once. I may be over-complicating this but it's what I've got. I really appreciate your help!

So I figured out the source of the issue. I wrote some code that detects a user's preferred language either from their browser language setting, or from a cookie that is created when they have visited and chose a language last time. If a preferred language detected and the current page URL does not match it, it will redirect to the same page but in the proper language. My problem is finding a way to get the URL that includes the pagination to compare. Right now my idea is to use $input->pageNum to build the URL myself... is there a way to get the URL including the page number? Lesson learned...

Indeed I have. Page numbers enabled, url segments disabled.