Leaderboard

Me too. You can solve this (from a technical point of view at least) by using language-alternate fields. Combine that with @bernhard's great suggestion to sync settings between your language fields and you should be all set. The only thing you're not getting from that is the cool tabs system LanguageTabs provides. I am always extensively tagging both templates and fields. With the tags, you can even have some of them be collapsed by default. This retains all the overview I need.

Hi @wbmnfktr I think generic layouts should cover more functionality and showcase features. Skyscrapers - A perfect illustration of map integration. Add to this the skyscrapers of Hong Kong (554 skyscrapers) and add Chinese language in the frontend. I think the multi-language functionality in PW is the best of any CMS. I had a client who wanted a website to have the following languages: English, Greek, Russian, Chinese. The only problem was finding a font that has all the lettering. I love ProcessWire's multilingual tools. The Shop - is a simple store layout for simple products. No taxes or shipping, just an order cart and that's it. It's a seed on which a big tree can grow later. Admin dashboard in backend - This functionality is available in many CMSs. A typical layout will show beginners how easy it is to customize the backend to suit their needs. Making an appointment - is a booking system for anything. This is a pretty common task that happens when you need to book a hotel, buy airline tickets from make an appointment with a dentist. This kind of layout will be useful to many people. I proceed from the premise that typical PW installations should show the functionality and flexibility of this system. Of course, ProcessWire's capabilities are much broader and constantly evolving. I have tried to point out only the key needs. What else can be illustrated? For example, flexible customization of access levels and user roles.

If you want to support the development of my PAGEGRID module you can find it now on Kickstarter. You can donate here. Thanks for your support!

Padloper 010 Padloper 010 (aka Padloper 2 version 010) is ready for download. Requirements PHP>= 8.2.0 ProcessWire>=3.0.200 Maintenance Padloper 010 is mainly a maintenance release: Fixes money rounding bugs found in Padloper 009 (and earlier). Adds the Money for PHP Library to handle monetary values in an easy and powerful way. Fixes money math issues when prices include tax. For the sake of internal maintenance, reorganises files and directory structure. Money Matters Specifically regarding 'prices include tax', and I will be adding this to the docs, it is important that you display your prices in the frontend in a way that doesn't confuse consumers. This is not unique to Padloper but a general e-commerce issue. This means making careful decisions around displaying unit vs total prices as well as whether to include notes about potential rounding pence/cents issues in your shop's policy documents. Due to rounding issues (pence, cents, etc) when it comes to money, especially if quantity is more than 1, the math might look off. I.e., (item * quantity) + tax IS NOT NECESSARILY EQUAL TO (item + tax) * quantity. See this article for a thorough discussion. Breaking Changes There are a few unavoidable breaking changes due to code rationalisation. API Some API had to be changed for maintenance and usage simplicity reasons. This affects checkout, cart and discounts. For instance: <?php namespace ProcessWire; # OLD API $checkout = $padloper->checkout; $response = $checkout->render($options); # NEW API // $response = $padloper->render($options);// this will be deprecated in a future release $response = $padloper->renderCheckout($options); ########## # OLD API $cartRender = $padloper->cartRender; $content = $cartRender->editCart(); # NEW API $content = $padloper->editCart(); ########## # OLD API $cartRender = $padloper->cartRender; $content = $cartRender->viewCart(); # NEW API $content = $padloper->viewCart(); HOOKS Backend hooks rename: // OLD NAMING FORMAT PadloperProcessRenderXXX e.g. PadloperProcessRenderOrders // NEW NAMING FORMAT PadloperAdminRenderXXX e.g. PadloperAdminRenderOrders Other hooks rename: // OLD NAMING FORMAT PadloperXXX::methodName e.g. PadloperUtilities::getProductWeight, PadloperCart::getProductPrice // NEW NAMING FORMAT Padloper::methodName e.g. Padloper::getProductWeight, Padloper::getProductPrice Upgrading Replace all files (not overwrite!). This is because some files have been deprecated, renamed or moved. Safest way to upgrade is to get rid of all existing Padloper files and folders under /site/modules/Padloper/ and then copy over the new 010 files and folders then do a module refresh. New Features The two new features are: $padloper->money(); More information will be added to docs. Bank Name as a property (bankAccountName) in the return value of $padloper->getShopBankDetails();. See request in this topic. Next Steps As mentioned in Padloper 009 topic, the focus now will be the documentation. Any questions or issues, please let me know. Thanks.

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

I wrote this a while back for my company's internal documentation and just realized it might be a benefit to others on the forum, so here it is! Checking whether a field was changed To check whether a specific field was changed you can do $page->isChanged(‘field’). This can only be done before Pages::save, since the save clears change tracking by default. Getting the values of a page before they were changed, from within a hook before Pages::save Method 1: The hacky way $clone = clone($page); $e->wire('pages')->uncache($clone); $oldP = $e->wire('pages')->get($clone->id); $oldP then represents the page and all its values as they were before any changes were made. Again, this will only work for hooks that run prior to Pages::save. Method 2: Using change tracking to get the old values If change tracking is set to track values, then the above is not necessary. In this case, calling $page->getChanges(true) will return an associative array of fields that changed and each field's prior value. Note that the value itself is also an array, since it is designed to be able to track multiple changes over the course of a single request/response cycle. Tracking of values is turned off by default (for efficiency sake), and there is no global switch to turn it on and off. To enable tracking of values, you must call $page->setTrackChanges(Wire::trackChangesOn | Wire::trackChangesValues) before any changes are made to the page that you want to track. Here is an example of how you can enable value tracking in ProcessWire's page editor: $this->addHookBefore("ProcessPageEdit::execute", null, function($e) { $p = $e->pages->get((int)$e->input->get('id')); if($p->template == 'event-registration') { $p->setTrackChanges(Wire::trackChangesOn | Wire::trackChangesValues); } }); Running hooks on both page saves and field saves Please note that using the following hooks is preferable if you want the hook to run both when individual fields are saved as well as the whole page: Pages::savePageOrFieldReady https://processwire.com/api/ref/pages/save-page-or-field-ready/ (for before a save) Pages::savedPageOrField https://processwire.com/api/ref/pages/saved-page-or-field/ (for after a save) Getting changes in a hook after Pages::save Note the $changes parameter passed to Pages::saved and Pages::savedPageOrField allows you to check which fields were changed during the save, even though the save is already completed. Using this is sometimes preferable to using a Pages::saveReady or Pages::savePageOrFieldReady hook since you don’t have to worry about the page cache or something else in your code preventing the original save from completing. A $values array is also provided, which is populated only if change tracking is set to track values (see above) Page cache issues when hooking before Pages::save Page cache issues may occur when you try to save another page inside of a before save hook (Pages::saveReady or Pages::save). A page save normally clears the entire page cache, which means any page fields on the page you were originally trying to save will have their values reset. So if you have to save another page inside of a before save hook, just use $page->save([‘uncacheAll’ => false]) to prevent the cache from being cleared. Preventing hooks from running on a particular save To prevent any hooks from running on a particular page save, you can use $pages->save($page, [‘noHooks’ => true])

I'm using https://intelephense.com/ and paid for it as it is so useful, but the free version is great as well!

Here's a good stack overflow article discussing exactly what I am trying to say: Is it reliable to use the IP address to identify a user on your website? - Stack Overflow

These things are so easy to do with RockMigrations: <?php // site/migrate.php $defaults = [ 'type' => 'image', 'maxFiles' => 1, 'descriptionRows' => 1, 'extensions' => 'jpg jpeg gif png svg', 'maxSize' => 3, // max 3 megapixels 'icon' => 'picture-o', 'gridMode' => 'grid', // grid, left, list ]; $rm->createField('your_image_field1', $defaults); $rm->createField('your_image_field2', $defaults); $rm->createField('your_image_field3', $defaults); You can then set custom labels for your fields or you can even set custom properties either in migrate.php overriding the defaults or via GUI as template context override. PS: If the fields already exist you CAN use ->setFieldData() instead, but ->createField() will work as well. PPS: If you need to change a setting just change the setting in the defaults, save the file and refresh your web broser!

Here are some additional feature ideas: - The feature to define the TinyMCE-configuration of all your TinyMCE fields in a "parent"-field is so great - how about if we could have that with more fieldtypes? In my sites, I have tons of fields, which change from time to time, and as one can't use fields more than once on a template, I have e.g. image_single_1, image_single_2, image_single_3. It would be great to change all those e.g. image fields at once, by just changing a "parent field". Please tell me, if I missed that feature, if it already exists ? - Nearly all my sites have to be MultiLanguage sites, and therefore, a multilanguage image field would be great. I know Language-alternate fields, but a "real" field would be really great. The most complex project, I am working on, has currently 10 languages. When creating and maintaining all the needed fields, this is a lot of work, which could be much easier with a multilanguage image field. - As I am still working with (nested) RepeaterMatrix and Repeater fields, keeping track of fields which are really used or not used is a complicated, as simple fields often are displayed as "in use" on some pages, while those pages are not "real" pages, but system pages of repeaters. I hope you know what I mean. The feature suggestion in this case is to extend the display of fields on the fields admin page so the relations between the fields are somehow more comprehensible. - Also, the fields list get's confusing, if you have some hundred fields – the UI could be refined somehow, to make the fields list easier to work with.* * I'll try to start a thread about naming fields, because I tend to change my naming scheme with every project, because I try to find the perfect one - which I did't find yet. Perhaps you are willing to share your naming schemes. I am sure someone already invented the perfect scheme ?

Thanks @Tiberium. Good to know I'm on the right track. Seemingly, crawlers mostly don't send the header in question and thus won't be affected by my implementation anyway. Also, I'm always sending hreflinks for all languages available and thus, crawlers shouldn't be blocked. @HMCB you have to decide your strategy based on what your site will do. If language is location-agnostic, just use two-letter language codes and just respect the language headers sent (e.g. with my snippet). If you are more region-oriented, go with your suggestion. Also, ProcessWire allows you to serve the default language on a path other than / (e.g. /en-us/). For this, just change the name of the homepage. Here is an example of a German page's settings tab for the homepage. The German version gets served at / and the French version at /fr/: Here is the same page with settings changed. German is at /de/ and French is at /fr/. With this, ProcessWire will issue an automatic 301-redirect to /de/ when the root (/) is requested: Remember these settings aren't set in stone once you started your project. You can change them at any point if you want.

Hello There @ryan just wanted to add my concerns here. I am not an "advanced" developer, i just develop sites or conduct experiments on my own personal website thats been running PW for a very long time now. That being said, i have read through this tread and i have become a little worried that PW would be going away from it´s root that made me many years ago fall in love with it. I am concerned that many of the more advanced users of the CMS want´s to take it to a more complicated place instead of keeping PW simple for us beginners to pick up and use wich is why i love it. As a laymans dev i can actually understand most of the API and what i can use it for. Ryan have made some posts in this tread that makes me feel calmer that the core simplicity is not going to go away. I also feel that many of the more advanced devs are missing the point of PW simplicty and why not everything should be in the core. There is modules for a reason,, want something special?, then create a module. Reasons PW appeal to me: 1. It´s API made sense from the start, logicaly and was adopted fast by my Authistic brain. 2. It´s does not interfere with how i want to render my website. 3. It´s has a great admin backend that should not confuse anyone. 4. PW is not WP. Thank you all.

I took a look at StaticWire. It's truely a basic SSG, but IMO it's rather a local tool not intended for use in hosting environment. It's okay if You have some hundreds of pages, but what if there's 1000+ of them?.. Generating a lot of static files at once can take too much memory and time, so personally I opted for a lazy static pages generation. Here's my module doing exactly this: https://github.com/theoretic/StaticPages It's open source, and it's free.

Hello @theoretic, have you tried StaticWire? https://processwire.com/modules/static-wire/ I have used it once for a locally hosted website for a exhibition, but it worked for me as a basic SSG. For online hosted websites I always use ProCache, which is AFAIK similar to a SSG : https://processwire.com/store/pro-cache/#procache-is-for-speed-and-seo Regards, Andreas

Hey @ryan first of all let me thank you for ProcessWire in general and for all the work you put into it! Also thank you for mentioning me and my modules. Unfortunately I can second what @jploch said, that it's very hard to offer commercial modules in PW, but that's a topic for another post as this one has gotten very long already ? NOTE: Sorry, this post got very long, but I think it covers some important concepts and I think some of the concepts can really push PW forward on the web-application front. I think it's important to understand the details, so I ask you kindly to read carefully and try to understand the bigger picture ? In this post I'd ask for clarification about what you said about custom page classes attaching their own hooks: I think the phrase "everything necessary" might be worth considering here. A class ideally just has one responsibility. Page instances are there to provide an interface to one page's content and be swapped in and out of memory on demand. When there are things like hooks going into a Page, that changes the role completely. If you start doing this a lot on a large site then it may affect scalability. Maybe it's fine for one individual installation or another, however. I didn't want to believe that, because everything that I've built over the last few years relies heavily on the concept of "MagicPages" which is a feature of RockMigrations and which basically turns every custom page class into an autoload module where you can add hooks that are related to that pageclass. This concept makes maintainability of the whole project a lot easier imho. Before I invented that concept I had quite complex applications and they had hundreds of lines of code in /site/ready.php or /site/init.php; ---------- first some background, later the tests ------------------ ---------- the tests ------------------ ---------------- Very, very long story short: @ryan I'd appreciate if you could explain in more detail why you think it is bad to put - what I'd call - pageclass-related code into pageclasses? Also I'd like to invite you to re-think if it is really bad to have things like "getPageListLabel" in the pageclass. I think this is a great to have these methods and I really enjoy having "editForm($form)" as a shortcut for ProcessPageEdit::buildForm if($page->template == ...) and so on. At the very minimum I'd love to have an init() and a ready() method where we can add hooks as we need them. Thank you very much for reading. I'm sorry for the length, but I hope there was maybe something interesting in it. Please let me know if I did anything wrong with my tests or what I could do better. Thx. Long live ProcessWire ?

@Tiberium, Wow... just wow. Thank you so much for providing the code! I really appreciate your help. I’ll give it a try later today and let you know how it goes. Thanks again for your support!

The script is in my templates/init.php file. You have to change the switch statement. Change zh to pt and replace de with es. You need to put google on an exclusion list, so the bot get's not redirected! That is important, because the bot will visit with "en" language and will kick out all other language out of the index, if you force a redirect on them. The redirect function: function crawlerDetect($USER_AGENT){ # Bots we DON'T want to redirected $crawlers = array( 'Google' => 'Google', 'Lighthouse' => 'Chrome-Lighthouse', 'MSN' => 'msnbot', 'Rambler' => 'Rambler', 'Yahoo' => 'Yahoo', 'AbachoBOT' => 'AbachoBOT', 'accoona' => 'Accoona', 'AcoiRobot' => 'AcoiRobot', 'ASPSeek' => 'ASPSeek', 'CrocCrawler' => 'CrocCrawler', 'Dumbot' => 'Dumbot', 'FAST-WebCrawler' => 'FAST-WebCrawler', 'GeonaBot' => 'GeonaBot', 'Gigabot' => 'Gigabot', 'Lycos spider' => 'Lycos', 'MSRBOT' => 'MSRBOT', 'Altavista robot' => 'Scooter', 'AltaVista robot' => 'Altavista', 'ID-Search Bot' => 'IDBot', 'eStyle Bot' => 'eStyle', 'Scrubby robot' => 'Scrubby', 'Facebook' => 'facebookexternalhit', ); $crawlers_agents = implode('|',$crawlers); if (strpos($crawlers_agents, $USER_AGENT) === false) return false; else { return TRUE; } } # The setLang var is that for the hole session it will not enforce the redirect anymore # I have in the footer of my sites a language dropdown as override in case the user want to visit the # other language - or in case the automatic ist wrong $USER_AGENT = $_SERVER['HTTP_USER_AGENT']; if(crawlerDetect($USER_AGENT)) { $session->set('setLang','1'); }; if(!$session->get('setLang')) { if ($_SERVER['HTTP_ACCEPT_LANGUAGE'] != '') { # I take the first two letters of the sended language and compare it in a switch # statement $accept_lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'],0,2); switch ($accept_lang) { case 'de': $session->set('setLang','1'); if($page->url != "/") { $url = $page->localUrl('default'); $session->redirect($url); } break; case 'en': $session->set('setLang','1'); if($page->url != "/en/") { $url = $page->localUrl('en'); $session->redirect($url); } break; case 'zh': $session->set('setLang','1'); if($page->url != "/zh-cn/") { $url = $page->localUrl('zh-cn'); $session->redirect($url); } break; default: $session->set('setLang','1'); if($page->url != "/en/") { $url = $page->localUrl('en'); $session->redirect($url); } break; } } else { $session->set('setLang','1'); } }; The dropdown (is building also in the templates/init.php above the redirect function) - also make here the same changes as above, case 'default' to es (your base language set in ProcessWire and zh to pt, and the default case in the bottom to en, as the wish fallback: $current_lang = $languages->getLanguage(); switch ($current_lang->name) { # set all placeholder variable for the users language # also the attribute then for the html tag case 'default': $class_lang = 'language-de-de'; $hreflang = 'de'; $lang_url = $wire->page->localUrl("default"); break; case 'en': $class_lang = ''; $hreflang = 'en'; $lang_url = $wire->page->localUrl("en"); break; case 'zh-cn': $class_lang = ''; $hreflang = 'zh-cn'; $lang_url = $wire->page->localUrl("zh-cn"); break; default: $class_lang = 'language-de-de'; $hreflang = 'de'; $lang_url = $wire->page->localUrl("default"); break; } # The Dropwdon Linkt Text as PRocessWire Language Var, that can be set in the language module $drop_title = __("Sprache ändern"); $lang_li = ''; foreach($languages as $language) { // if(!$page->viewable($language)) continue; // is page viewable in this language? if($language->id == $user->language->id) { $lang_li .= "<li class='current'>"; } else { $lang_li .= "<li>"; $url = $wire->page->localUrl($language); $hreflang_drop = $home->getLanguageValue($language, 'name'); $lang_li .= "<a class='drop-item' hreflang='$hreflang_drop' href='$url'>$language->title</a></li>"; } } # Now comes the dropdonw. Build at with the framework/dropdown lib you want and change it accordingly. $drop_title for the titel of the menu # and then $lang_li for all the collect <li> above $lang_dropdown = ' <div class="dropdown"> <button class="drop-toggle" type="button" aria-expanded="false" onclick="dropFunc()"> <svg width="18px" height="18px" stroke-width="1.5" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg" color="#fff" style="transform: translate(0, 3px);"><path d="M2 5H9M16 5H13.5M9 5L13.5 5M9 5V3M13.5 5C12.6795 7.73513 10.9612 10.3206 9 12.5929M4 17.5C5.58541 16.1411 7.376 14.4744 9 12.5929M9 12.5929C8 11.5 6.4 9.3 6 8.5M9 12.5929L12 15.5" stroke="#fff" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"></path><path d="M13.5 21L14.6429 18M21.5 21L20.3571 18M14.6429 18L17.5 10.5L20.3571 18M14.6429 18H20.3571" stroke="#fff" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"></path></svg> '. $drop_title .' </button> <ul id="drop-menu" class="drop-menu"> '. $lang_li .' </ul> </div> '; Then in my templates/_main.php in the footer, I call $lang_dropdown for the dropdown menu for manual override.

I'd love to suggest other things as well, but for now I'll just say that this is also my experience. Sorry in advance if this turns into a rant, but I feel that this is an important topic ? Past few years we've shifted our focus so that now we mainly use ProcessWire for sites with heavy focus on application like features and structured content, while "regular websites" are more often built with WordPress. There are cases where ProcessWire is stronger, and it can be used to build flexible, content block based sites using something like Repeater Matrix, but to be fair Gutenberg (which I/we use solely, no other page builders) is on another level when it comes to built-in flexibility and WYSIWYG. With one exception: you can't have multiple "Gutenberg fields" on single page, which can, in fact, be a pretty big bummer in some cases; and that could also be a potential benefit if we did have some sort of block builder in the core. (... and if ProcessWire, on a core level, wants to focus more on directory / application type sites, there's nothing wrong in that either. It just means that we, as a group of ProcessWire developers and enthusiasts, will be "losing" a large — and likely increasing — amount of potential clients and projects for other systems.) The work done by Bernhard and jploch is fantastic, but for me the biggest question mark is probably that these are not core features, meaning that they are not something that is "officially supported" by the core / core team. They are also not free / open source software, which means that the community directly participating in their development is not really an option, in my opinion. I'm not sure what the best solution, especially since this is clearly not a common need/requirement for Ryan, but I do hope that we could eventually have some level of support for this at the core — even if it's not "full-featured", but rather a framework that can be expanded / built on top of. Using Gutenberg as an example: I don't have a real figure, but I can tell that a team has worked on it for many years now, and continues to do it on a daily basis. It's not realistic to assume that a single developer could truly compete with that. And one thing I've learned about page/block builders is that there's a lot of nuance and the architecture is a major question that could make or break it, so doing it without solid understanding of what the results of each choice is way down the pipeline would be a huge gamble. (In case of Gutenberg the architecture is a hot mess: there are no dedicated data structures, and they keep changing and breaking internal code all the time. But, again, they have enough resources to handle that, and the project has so much momentum that while developers may complain, eventually they'll have to go with the flow.) As for Ryan's point about preferring to "avoid features that blur the line between content and style or front-end and admin", which I assume was related to this request (to some extent at least), I'm sure there are ways to handle content block GUI in the admin without putting too much focus on how they look like on the front-end. E.g. tje editing interface could be more like a wireframe with some similar structure than "the final product". Front-end editing is an option, but... I must admit that I like the "middle ground" that Gutenberg has, where you're still editing content in the admin. Obviously introducing front-end styles for the content in admin is not a nobrainer, which is why many sites — in my experience — won't even aim for fully stylized (custom) blocks in the admin. WYSIWYG is a big topic in itself ?

I lost 85% of our clients to WordPress due to page builders like Elementor. They aren't concerned with code clutter, page speed and SEO disadvantages. I would love some offerings in that direction, I am aware that this maybe will open Pandora's box. Some praise here for ProcessWire: ProcessWire is unbeatable for websites that almost work as applications. We coded the whole backend office management for our web design firm with ProcessWire including tons of SEO-, Data protection-monitoring- and wp-plugin-updates-montitoring crawlers and checkers: We kind of remote control WordPress from ProcessWire. Clients can log in and see everything they booked at a glance, and can order things directly from ProcessWire, and it is directly connected to the invoicing app. This is a unique system, 10 years of work in it and now makes the entire company manageable by a minimal team, unthinkable without ProcessWire. Thinks I would like in PW4 are things I am used to from WordPress, a full switch to utf8mb4, those needed GDPR utilities out of the box, modules can be "deactivated" leaving the settings intact, and "removed" to make troubleshooting modules compatibility issues much easier. Some image optimization capabilities would be great, the existing 3rd party modules do not meet our expectations yet. Also a good monitoring/curation of outdated/abandoned modules, with supplied warnings, would be great; there are a lot of those old modules, unfortunately.

Excited to see thoughts about starting work on ProcessWire 4. PHP 8+ bring so many improvements, would be nice to utilize them. My personal pain points and wishlist for ProcessWire: - a global media manager - more official integration of multi site / multi domain capabilities (in my case especially for the one database, multiple roots option) - admin theme improvements: - a permanently visible page tree to quickly jump between pages - more ways to customize it, depending on the applications needs. Like having a predefined place to add a "website select" for multi domain websites. - quick mockup, based on www.clickup.com. Clickup also has a "task bar" where you can put pages that you want to come back to. That's quite handy as well. - from a tech point, some things that could be nice to have, but most likely not feasible and against the philosophy of ProcessWire because it would most likely make the project more bloated: - better utilization of composer, e.g. having the ProcessWire core and admin package as separate composer packages, so a ProcessWire installation would just have a "site" and a "vendor" directory - PSR standards / framework ineropability where it makes sense - some automated tests, at least for the core api @Jonathan Lahijani+1. We're using it for application development and it works very well if there is not too much data involved (with 10,000,000+ pages you'll start to having to search for workarounds to keep things fast, in my experience). Would be nice to hear what would be your ideas for improvement. A more web-application like and customizable backend would be nice for us as well. In some projects we were able to hack and hide everything that was not needed. In other projects we build a custom admin panel. Then a way to render a form for a full template in the frontend would have come in handy several times already.

An approach I sometimes use is the following. It seems to work quite well and is fairly clean: Put all your class-specific hooks in your page class, let's say in a ready() function (can be named anything of course, but ready() is a good convention for me). In /site/ready.php, just instantiate a single instance of the page class and call its ready() method. So, if we have let's say a NewsarticlePage class and we want to keep all news article related hooks together, we might have something like this in the page class: <?php namespace ProcessWire; class NewsarticlePage extends DefaultPage { public function ready() { $this->addHook('ProcessPageEdit::buildForm', $this, 'addImportOptions'); $this->addHookAfter("Pages::saved(template=newsarticle)", $this, 'processAfterSaveActions'); $this->addHookAfter("Process::execute", $this, 'processAfterExecuteActions'); } And in site/ready.php: <?php namespace ProcessWire; //required to trigger ready hooks in custom page classes: (new NewsarticlePage())->ready(); (new SomethingElsePage())->ready(); //etc... You can instantiate one empty page object for each Page class you need to run hooks for. There's some overhead, but not much, and it keeps your site/ready.php clean and your hooks where they make sense. Of course you still have to make sure the hooks only target the desired pages/templates. Inspired by some of @bernhard's earlier posts on the subject.

Reference to the new feature:

Never mind. The simplest way to do this is include $rm->watch methods in ready.php that cover the subset I want to pay more immediate attention to and then run migrate those watched files there: $rm = $this->wire->modules->get('RockMigrations'); $rm->watch($wire->config->paths->site.'/migrations',2); $rm->watch($wire->config->paths->site.'/migrations/matrixtypes',1); bd($rm->getChangedFiles()); // Just to check on things. $rm->migrateWatchFiles();