Leaderboard

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).

Field that stores one or more references to ProcessWire pages with additional data in field context. Values are editable via page edit modal of the referenced page provided from the field if module AdminPageFieldEditLinks is installed and "Enable link to create new pages?" is checked in field settings. Requirements: AdminPageFieldEditLinks >= 3.1.4 https://github.com/kixe/FieldtypePageContextData https://processwire.com/modules/fieldtype-page-context-data/ Use case example: The planning of the Tonmeistertagung in the CCD (Congress Center Düsseldorf) from November 3rd, 2021 to November 6th, 2021 is in the finalization phase. The conference consists of a conference part and an exhibition. The planning is done via a separate frontendless PW instance. There, all companies (pages) that are active at various events are kept in a pool. Changes (address, logo) can always be done there. For the exhibition of the current conference in November, the exhibitor-companies (pages) are selected via a page reference field. A stand number must now be assigned to each selected company (page). We had originally solved this using the Profield FieldtypeTable. However, this had the disadvantage that each entry again made all companies available for selection and did not recognize which were already selected in a previous table row. The new field type now allows the value (company's stand number) to be assigned to a Company (page) in context to a specific Pagefield living in a specific page. https://tonmeistertagung.com/en/exhibitors/exhibition/

I've pushed a fix. The separator must be translated into a real line break (expected by the Inputfield). I changed the translation to "\r\n" instead of "\n" only, which should work cross platform. Continue to use the string '\n' in the field settings. Please update to version 1.0.1. Could you please give feedback if it works? The pipe '|' you mentioned is already reserved to separate an option 'value' from the option 'title' (@see SelectableOptionManager). I prefer to handle the setup according (very close) to the expectations of the inputfield. ProcessUser and possibly some other processes for editing system pages are not supported. In the special case of ProcessUser, the GET-Parameters forfield and forpage are removed from the url of the modal window for whatever reason. Any idea? The module is still in an alpha stadium. Thanks for testing and feedback.

This is amazing! I have missed this functionality in ProcessWire for a while already. Installation Install AdminPageFieldEditLinks: https://processwire.com/modules/admin-page-field-edit-links/ Install FieldtypePageContextData (this module) Create a new field of type "Page Reference Context Data" When setting up the field: in tab "Details" enter configuration in "Additional page fields in Pagefield context". You can see many examples here https://github.com/kixe/FieldtypePageContextData in tab "Input" select "Enable view/edit linnks on selected pages?". If you don't see this field the module AdminPageFieldEditLinks is not activated in tab "Input" when changing the label field: you can also use the additional context fields as label in the page reference. Symply change your label to a custom label and define it like so: {title}, {_customfield1}, {_customfield2} assign the field to your template Screenshots When installed and configured correctly you see the page reference like normal. But now you can click it and edit the page in a modal. This modal also contains a new tab "Pagefield Context Data" (the name of the tab can be changed in field settings). Bugs found so far On Windows: separating option values for select by \n is not working correctly. Maybe use | instead? (as that's how ProcessWire separates fields) for the user template the tab "Pagefield Context Data" is not being displayed Very well done. This is SO useful! ♥

@AndZyk, I don't think this is entirely accurate. Maybe things have changed since I last read the thread but below is the quote from @ryan with respect to his thoughts on a layout / page builder: https://processwire.com/talk/topic/25129-weekly-update-–-12-february-2021/ So, it is not a matter of lack of interest but more about 'lack of expertise', albeit with willingness to support it on the PHP (ProcessWire) side ?. By the way, I could have offered to take lead on this but until a certain module is released (getting very close now! ?), I don't have much time for anything else ?.

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ę! Спасибо! ありがとうございます！ 谢谢你

Well, yes and no. Two migration modules already exist in ProcessWire, but neither suited my needs: “Migrations” by @LostKobrakai seems effective but quite onerous to use and has been deprecated in favour of “RockMigrations” RockMigrations by @bernhard is simpler and has a nice declarative method: migrate(). However, it is ideally suited to “headless” development, where the API is used in preference to the Admin UI. This is great for professional PW developers, but for occasional developers like me, it is much easier to use the UI rather than just the API. In addition there @adrian's ProcessMigrator which is designed for migrating page trees. Concept I wanted something to achieve the following: To allow development to take place (in a separate environment on a copy of the live database, or on a test database with the same structure) using the Admin UI. When finished, to permit a declarative approach to defining the migration and implementing it (again in the UI). To allow testing of the migration in a test environment on a copy of the live database. To allow roll-back of a migration if installation causes problems (ideally while testing rather than after implementation!). To provide a record of changes applied. Although not originally intended, the module I developed also allows the selective reversion of parts of the database by exporting migration data from a backup copy. Also, if changes are made directly on the live system (presumably simple, low-risk mods – although not best practice), it allows reverse migration to the development system in a similar fashion. I should emphasise that what I have built is more of a 'proof of concept' than a fully-fledged module. The code is pretty hacky and uses some stuff outside of the module itself. Lots of validation is missing. However, I have used it successfully in a number of small tests and a medium-sized live migration. If there is sufficient interest, I will tidy the code and make it available, but it would still need input from better coders and PW-savants than me to make it into something more widely usable. EDIT: Please note that the module has moved on a bit from this original post - the design has changed somewhat to make it more robust and flexible and additional features have been added. Please see the help file for full details. I still consider it to be at alpha stage, however, so use with care - test before making migrations and always take backups first. Design The module has the following principal components: A PW module “ProcessMigrateData”, bundled with a bootstrap migration in the same ProcessMigrateData folder, to be placed in the site/modules folder; A Page Class “MigrationPage” to be placed in the site/classes folder; Php files migrationActions.php and migrationControl.php to be placed in the site/templates/RuntimeMarkup folder (and migrationActions.js to be placed in site/templates/RuntimeMarkup/scripts). There are also a methods which need to be put in class DefaultPage and a functions in the init.php file. The module requires the FieldtypeRuntimeMarkup module. Migration definitions are held in .json files in the ProcessMigrateData/migrations/{migration name} folder (I might move this). This folder contains up to 2 sub-folders - “new” and “old” which each contain a file called a migration.json file, which defines the scope of the migration in terms of fields, templates and pages, and also one or more of fields.json, templates.json, pages.json and remove.json. The first 3 of these files contain the field, template and file definitions within the migration scope and the remove.json file simply lists fields, templates and pages to be removed. These migration files are mirrored by pages of template “Migration” under a parent /migrations/ of template “Migrations”. The mirroring happens in two ways: If a new migration is created in the module (from the Setup -> DB Migration menu), then initially no json files exist. The json files are created, after the scope of the migration is defined on the page, by running “Export Data” from the eponymous button. If json files exist, but there is no matching migration page, then the latter is created by the module on accessing the DB Migration admin page. In this case, we are in the “target” database so there is no “Export Data” button, but instead “Install” and/or “Uninstall” buttons. Migrations therefore either view the current environment as a “source” (type 1) or a “target” (type 2). Installation The module creates templates called Migration and Migrations and a page below the root named ‘migrations’. Open the admin page “Setup -> DB Migration” to create a migration. One (“bootstrap” is already installed) and cannot be modified. The pic below illustrates the DB Migrations page in the source environment. The status of a migration (as a source page) can be ‘pending’ or ‘exported’. ‘Pending’ means either that the migration data have not yet been exported or that the current export files differ from the source database. On opening this page in the target environment, the individual Migration pages (type 2) are created from the definitions in their respective /new/migration.json file. The pic below illustrates the DB Migrations page in the target environment. In a target environment, a migration status can usually be ‘indeterminate’, ‘installed’ or ‘uninstalled’. ‘Indeterminate’ means either that the migration has not yet been installed (so no ‘old’ files containing the uninstall definition exist yet) or that the current state matches neither the ‘new’ or the ‘old’ state. ‘Installed’ means that the current state matches the ‘new’ definition and ‘uninstalled’ means that it matches the ‘old’ definition (i.e. it has been actively uninstalled rather than not yet installed). When carrying out development work, you keep a note of what fields, templates and pages you have added, changed or removed. The module does not track this – it is a declarative approach, not a macro recorder. Also, it does not handle other components such as Hanna codes and Formbuilder forms. These come equipped with their own export/import functions. You can update a migration page as you go along, rather than keep a separate note of changed components. The migration page also allows you to document the migration and add any number of “snippets”. These snippets do not do anything, but can be a convenient place to store (for example) Hanna code exports for pasting into the target environment and help to make the page a comprehensive record of the migration. See example below: Note that migration pages just define the scope of the migration. It is entirely feasible for other parts of the dev database to be changed which are outside this scope and which will therefore not be migrated. After sync'ing code files to the target environment, the new migration will be listed on the setup page. On the migration page, in the target environment, there are “preview” buttons to see what changes will be implemented. The migration can then be 'installed'. See example of the migration page in ‘installation’ mode below: That's the gist of it, but inevitably there are complications. Happy to discuss and share further if there is interest in this.

Update - 24.12.2021 After long days of reconsideration and experimenting I will deprecate the current state of Symprowire. I decided to get rid of my trys to integrate the whole Symfony experience as it grew pretty large pretty fast. Whats left you may ask? Well, the project is not dead. I am currently refactoring the whole setup to just use SymfonyHttpFoundation and Twig. I have a working proof right now, but have to polish some things first. The whole setup will come as a simple composer package to get called via a controller.php template file. Much like WireFrame. As you can see in the picture we will use the normal ProcessWire Workflow and just use the normal PageRender process. You as a Developer will get in control if to use the Setup for a particular Template or not. Looking forward to publish the proof. Cheers, Luis Debug Dump WIP 25.12.2021 Symprowire is a PHP MVC Framework based and built on Symfony using ProcessWire 3.x as DBAL and Service-Provider It acts as a Drop-In Replacement Module to handle the Request/Response outside the ProcessWire Admin. Even tough Symfony or any other mature MVC Framework could be intimidating at first, Symprowire tries to abstract Configuration and Symfony Internals away as much as possible to give you a quick start and lift the heavy work for you. The main Goal is to give an easy path to follow an MVC Approach during development with ProcessWire and open up the available eco-system. You can find the GitHub Repo and more Information here: https://github.com/Luis85/symprowire

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!

Hummm ... are you talking of the module one should not say the name ? Happy to know it's getting close to be released as the last sneak peek video got me really excited about Padlopper 2.

I made this post yesterday:

@AndZyk Here's a new fieldtype I have been working on for the past weeks. These draggable blocks are defined by developer using custom templates, and they are fully stylable. The module is quite far from being production ready, but I wanted to share this, since I think this might be something you're looking for ? Proper teaser video will come after I reach the first milestone in development process.

Thanks for the comments @cjx2240. Sorry it has taken so long to reply. I have done quite a bit of work removing various bugs (there were quite a few!). I have also extended the functionality considerably to include a database comparison feature (allows draft migrations to be created based on database differences). There is also the capability to run custom code alongside the migration via hooks. The help file is now (roughly) indexed and available at https://metatunes.github.io/DbMigrate/help.html. The new version (0.1.0) is at https://github.com/MetaTunes/ProcessDbMigrate. You should be able to replace the files in your ProcessDbMigrate directory with the new ones and 'refresh modules' to upgrade. Please let me know if any of the snags you hit have persisted after the update (or any new ones encountered) and I will try and resolve them more quickly next time! I'm hoping that this version is a passable 'alpha' as opposed to the previous 'proof of concept' and will look to submit it to the modules directory if it seems sufficiently robust.

Release RC1 v0.2.0 -> https://github.com/Luis85/symprowire/releases/tag/v0.2.0-rc-1 added Session Handshake to integrate PW Session into Symfony added $page, $pages, $input, $session, $modules, $users as member to AbstractController added Symprowire autowire Services outside of userland into /lib/src and added own Namespace for the lib added Repositories (Pages, Modules, User) to the lib added UserRepository to HomeController::index() as Dependency Injection for Demonstration / as Example

Good day, @ryan! I'm in! As for now I always used Repeater Matrix for content builders as @Jonathan Lahijani, my first approach would be to develop additional features on that side first. So lots of us already using this pro module could do it even better. I started a topic in Repeater Matrix forum to gather wishes you could help us with. Everyone else interested, please contribute!

As threatened in Ryan's announcement for 3.0.139, I built a little module for sliding toggles as a replacement for checkboxes. Styling of the input is CSS3 only (with all the usual caveats about older browsers), no JS necessary, and may still be a bit "rough around the edges", so to speak, since I didn't have much time for testing on different devices or brushing things up enough so I'd feel comfortable pushing it to the module directory. But here's the link to the GitHub repo for now: InputfieldSlideToggle Fieldtype and Inputfield that implements smartphone-style toggles as replacement for checkbox inputs. The visualization is CSS-only, no additional JS necessary. Status Beta, use with caution Features / Field Settings Size You can render the toggles in four different sizes: small, medium, large and extra large. Off Color Currently, "unchecked" toggles can be displayed either in grey (default) or red. On Color "Checked" toggles can be rendered in one of these colors: blue (default), black, green, grey, orange or red. Screenshots Some examples with checkbox label View all Size and Color Combinations Small toggles Medium toggles Big toggles Extra big toggles