Leaderboard

Babel is a module that provides functionality for managing section based multilanguage sites. It is inspired by Babel Plugin for MODX. There are cases where websites have 600 pages in english, 700 pages in russian and only 300 pages in english and russian. In this case it is much better to keep the content separate, each under one section and have their translations linked. This module helps you to manage those links. Github Page Download Link How to Install Warning Backup your database before installing this module. Requirements Babel works on top of core LanguageSupport module. You will have to install it first and create languages for your site. Then: 1. Copy all the module files to /site/modules/Babel/ 2. In your admin, go to Modules > Refresh for new modules. 3. Click the "Install" button next to Babel. Settings First of all you should set the root page for each language. Usually section based multilingual sites will have a structure like... Root |__Home (English) |__About |__News |__ News Article 1 |__ News Article 2 |__ News Article 3 |__ News Article 4 |__Contact ... |__Главная (Russian) |__О нас |__Новости |__ Новостная статья 1 |__ Новостная статья 2 |__ Новостная статья 3 |__ Новостная статья 4 |__Связаться ... |__Baş Sahypa (Turkmen) |__Barada |__Habarlar |__ Habar Makalasy 1 |__ Habar Makalasy 2 |__ Habar Makalasy 3 |__ Habar Makalasy 4 |__Aragatnaşyk ... You just need to select the languages that you want Babel to manage and select the root pages for each of them. API Babel creates couple useful methods and a properties for you. language (Page property) Every page that is handled by Babel (those who are descendants of root pages that you choose on Babel module's settings page) will have a language property that returns a Language object that they are assigned to. It is determined based on under which rootParent the $page lives; Syntax $page->language; Return Language object. translation (Page method) This method returns the page that was assigned as a translation for the given $language. Syntax $page->translation($language); Arguments The $language argument could be either a string (the name of the language), an integer (the id of the language) or a Language object itself. Throws WireException if the language is not found or isn't handled by Babel. Return The method returns a Page object or NullPage if the translation is not available. translations (Page method) This method will return the pages that were assigned as a translation for all $languages that are available for that page. Or an empty PageArray if no translations are available. Syntax $page->translations(); Return Returns PageArray. addTranslation (Page method) This method will create a translation link from $page to $otherPage. Syntax $page->addTranslation($otherPage[, $overwrite]); Arguments The $otherPage argument should be a Page object. The language of the page will be determined by Babel itself based on under which language section the page is located. The $overwrite argument is optional and has three case scenarios: If omitted the reverse link of the translation will be created only if the $otherPage does not have a translation link for the $page->language. If set to true the reverse link will be overwritten even if $otherPage does have a translation link for the $page->language. If set to false the reverse translation link will not be created even if the $otherPage does not have any translation links. Return boolean if the translation link/s is/are created successfully or not. removeTranslation (Page method) The method removes a translation link between $page and $otherPage. Syntax $page->removeTranslation($language[, $remove]); Arguments $language (string|integer|Language) The language link you wish to remove. $remove (boolean) If there is a reverse link that points back from the translation to this page, should Babel remove it too. Default is false. Throws Throws WireException if the language couldn't be found or is not handled by Babel. Return boolean If the removal of the translation link/s is/are successful. closestParentTranslation (Page method) Returns the translation of the closest translated parent of the page. Syntax $page->closestParentTranslation($language); Arguments $language (string|integer|Language) The language for which you want a translation for. Throws Throws WireException if the language couldn't be found or is not handled by Babel. Return Page object. getRoot (Babel method) Returns the rootPage of the language. The one you have assigned in the module settings page. Syntax $modules->get('Babel')->getRoot($language); Arguments $language (string|integer|Language) Throws Throws WireException if the language couldn't be found or is not handled by Babel. Return Page object. translatable (Babel method) Tells if a page is translatable via Babel or not. Syntax $modules->get('Babel')->translatable($page); Arguments $page is a Page object. The page you want to check on. Return boolean If the page is translatable or not. getTranslated (Babel method) Returns a PageArray of translated pages. Syntax $modules->get('Babel')->getTranslated($fromLanguage, $toLanguage[, $limit[, $pageNum]]); Arguments $fromLanguage (string|integer|Language) The language from which the translation is. If omitted (or null given) then all the translation from all languages will be considered. $toLanguage (string|integer|Language) The language to which the translation is. If omitted (or null given) then translation to all languages will be considered. $limit is the number of pages you want to receive. Default is 50. $pageNum is the page number. Use for pagination of the returned PageArray. Default is 1. Throws Throws WireException if the language couldn't be found or is not handled by Babel. Return PageArray. getUntranslated (Babel method) Returns a PageArray of pages that are not translated to one or the other language. Syntax $modules->get('Babel')->getUntranslated($fromLanguage, $toLanguage[, $limit[, $pageNum]]); Arguments $fromLanguage (string|integer|Language) The language from which there is no translation. If omitted (or null given) then all the untranslated pages from any language will be considered. $toLanguage (string|integer|Language) The language to which there is no translation. If omitted (or null given) then untranslated pages to any language will be considered. $limit is the number of pages you want to receive. Default is 50. $pageNum is the page number. Use for pagination of the returned PageArray. Default is 1. Throws Throws WireException if the language couldn't be found or is not handled by Babel. Return PageArray. babelHomePage ($config property) Reference to the home page. This is usually one of the pages that you chose in the module settings. Syntax $config->babelHomePage; The babelHomePage is determined based on: the path that user has entered... if not available then the session is checked... if not available then it defaults to the core LanguageSupport module's default language; Usage Tips If your site structure is the way it looks like it is shown above. Your root page usually won't ever render. Whenever a user enters your site at the `/` path you will redirect him to one of language root pages. Here is how I suggest you to do that in your root.php template file. $session->redirect($config->babelHomePage->url, false); that's pretty much everything you need to have in your root.php file. To display links for each language homepage... $home = $config->babelHomePage; $homePages = $home->translations()->and($home); echo "<ul>"; foreach ($homePages as $p) { $title = $p->language->title; echo "<li><a href='$p->url'>$title</a></li>"; } echo "</ul>"; To display links for each translation of the current page... echo "<ul>"; foreach ($page->translations() as $p) { $title = $p->language->title; echo "<li><a href='$p->url'>$title</a></li>"; } echo "</ul>"; ProcessBabelTranslate Babel comes with very useful admin helper. You can link pages as a translation for each other. You can create translation page if there isn't one yet. There is small indicators on page tree that shows which pages are translated to what languages. And you get a Babel Tanslate page where you can quickly find all the translated and untranslated pages accross your site. See the screenshots below... Settings page Translation indicators Quick action button Quick modal translate form Tab translate form ProcessBabelTranslate page Go ahead and try it out. This is my first module to publish. Please tell me if something need to be added, changed, removed...

Hi folks! I'm about to add my new module FieldtypeAssistedURL to the repository. You find the source code on github and hopefully in the modules repository soon. Here an extract from the README.md: This module offers you a new field type AssistedURL Field, providing and input field for storing absolute and relative URLs. The field type adds a button to open the URL chooser dialog known from the CKEditor link feature without the tab navigation bar for specifying link attributes. Using the URL chooser dialog the editor may select URLs from internal pages or uploaded files via a search field with auto-completion, a page tree control, and a file selector control. Please feel free to post suggestions and any form of feedback here in the forums or on github. Wumbo

I just published a pre-release of my new password reset module. It will enable identification from any field of your choice, and is fully translatable. Integration is just 2 lines of code, the first is calling the controller, the second is loading a script (no dependencies). You can download the code on GitHub at https://github.com/plauclair/PasswordReset. Also, have a look at the reset process in this video https://vid.me/eEVY. This exemple is not styled, but there should be all you need in there to style it. Comments and feature requests very welcome!

That's not entirely correct. If you don't check the "active" checkbox under Settings when editing a page, the page is not listed for users with this language, e.g. excluded from $pages->find calls. I'm not sure what the default behaviour is when you visit the page directly in a language which is not active. Maybe you'll see the content in the default language. In this case, I'm sure you could also hook into somehwere and throw a 404 or do the prefered action. Yep. You're right. I did not even know that. I guess the difference with this module is only the contextual approach to the multi-language sites. I don't think this module is any better than the core LanguageSupport module, just the other way of doing things. I posted it here for community to decide. If we decide we don't need it the thread will stay only for historical reasons I guess. Another thing might be the hassle with FieldTypes that do not support multi-language. FieldtypeFile and FieldtypeImage for instance. I know that you can have multi-language descriptions. But what about files themselves. You can't have different files for different languages.

ProcessWire does not support tree based multi-language sites. This is just another approach to handle sites with many languages. Some people prefer to do it this way. There are cases where websites have 600 pages in english, 700 pages in russian and only 300 pages in english and russian. In this case it is much better to keep the content separate, each under one section and have their translations linked. In case for core LanguageSupport module. When you publish an article in english, it will be shown in the russian version of the site too, even if there isn't a russian version of the article. It will also will show in places like navigation, on sidebar with the latest news etc. However if you put everything english under one page and build every parts of your site under that page (your navigation root, latest news) then your article in english language will never be seen in russian version. Update: The last paragraph is not entirely correct. See the comment by @Wanze below.

With these, it's best to tackle them one by one. For this particular one, place the following directly beneath RewriteEngine On: RewriteCond %{QUERY_STRING} ^sa=[^&]+&ved=[^&]$ [NC] RewriteRule ^(.*)$ /$1? [R=302,L] This will trim out the query string and revert to /name-of-page.

Admin Page Tree Multiple Sorting ClassName: ProcessPageListMultipleSorting Extend the ordinary sort of children of a template in the admin page tree with multiple properties. For each template, you can define your own rule. Write each template (template-name) in a row, followed by a colon and then the additional field names for sorting. Example: All children of the template "blog" to be sorted in descending order according to the date of creation, then descending by modification date, and then by title. Type: blog: -created, -modified, title Installation Copy the files for this module to /site/modules/ProcessPageListMultipleSorting/ In admin: Modules > Check for new modules. Install Module "Admin Page Tree Multible Sorting". Alternative in ProcessWire 2.4+ Login to ProcessWire backend and go to Modules Click tab "New" and enter Module Class Name: "ProcessPageListMultipleSorting" Click "Download and Install" Compatibility I have currently tested the module only under PW 2.6+, but think that it works on older versions too. Maybe someone can give a feedback. Download PW-Repo: http://modules.processwire.com/modules/process-page-list-multiple-sorting/ GitHub: https://github.com/FlipZoomMedia/Processwire-ProcessPageListMultipleSorting I hope someone can use the module. Have fun and best regards, David

A conversation from the GITHUB issues which I thought to be useful to have in this Forum's knowledge base. Ryan Cramer put some valuable information there, which should be searchable in this forum, i.m.h.o. My Summary: Use the "autojoin" option on pagefield (when allowing multiple pages) with care. There could be unwanted side effects especially if you use more than one of these fields with that setup on a single template. Original conversation: tbba asked: I have 2 page fields (one is the clone of the other - so they are unique apart from the name). Both are used on a template. The first field DOES remember the (dragged) sort order of the pages, the second does NOT. Has anyone else have the problem too? Is this a cache problem, or corrupt indexes? PW latest dev / php 5.6 fastcgi / Safari+Firefox Update: If I change the display order of those 2 fields in the template, both fields behave the opposite: So the first (whatever the first field is in the template when editing the page) always WORKS the second NOT. (The 2nd field lets me still adding or deleting a page - just the order is corrupt there.) Update: On localhost everything works (same php version but has opcache off in MAMP - maybe this info is important) Update: If I switch "autojoin" off for those page fields, everything works everywhere. This is my workaround for now. (I remember that "autojoin" has been a problem for me with page fields already in much earlier versions of PW on many sites so it is not a temporary phenomena.) ryancramerdesign commented If you need to retain a sort order, you'd only want to autojoin one of the page fields. Autojoin causes everything to be loaded in one query, and there can't be two different sorted result sets included in that query as far as I know. Though it's interesting it works on your localhost and not on the other server. There are some MySQL versions known to have issues with sorting and certain queries, and you may be hitting up against that on one server and not the other. Though I can definitely see how auto joining two Page fields in one query would pose challenges to retaining the sort order. So in either case, I would limit your autojoin to just one Page field, or simply not use Autojoin for page fields at all. There's not a major benefit in doing so. tbba commented MYSQL on the live server is 5.6 and on localhost/MAMP it is still 5.5. I am very glad you can confirm that this issue is not a phantom of a defect system and can be 100% nailed down to "Autojoin". I used Autojoin under the assumption that it indexes a field and makes certain searches (menu building) quicker. (Since the new cache options, I am not worried with speed on certain searches any more.) If Autojoin has, in the best case, no "major" effect with page fields and in the worst case totally confuses the system, why is the option nor switched off and deactivated for this field type? Is Autojoin only bad for page arrays or even if the page field is set to accept only one page? Are there other fields that also have a problem with "Autojoin"? (I must say this "mystery bug" - which sometimes happens and sometimes not - was quite a debugging nightmare and other users should be warned/hindered to set-up such a combination, i.m.h.o.) ryancramerdesign commented I am very glad you can confirm that this issue is not a phantom of a defect system and can be 100% nailed down to "Autojoin". Actually I can't nail it down to autojoin, but outside of using it with a simple text or number field, autojoin is an advanced option that can be affected by a lot of different factors. It's one of those things we suggest using when you find it helps, and don't use when you find it interferes. When you autojoin a multi-value field, MySQL is performing what's called a group_concat, and is at the mercy of certain MySQL memory buffers and configuration settings. It's very possible you are hitting up against that too, which is made all the more likely by auto joining two multi-value fields. That would explain why you see it on one server and not another. I used Autojoin under the assumption that it indexes a field and makes certain searches (menu building) quicker. (Since the new cache options, I am not worried with speed on certain searches any more.) It can make things quicker but it can also slow them down. It really depends on the case. The only way to tell for certain in a given instance is by testing and timing it. I do know for certain that auto-joining one or two text fields (like title and summary, for example) does provide a performance benefit to large navigation lists that use the autojoined fields, though not likely one that you would feel unless loading hundreds of thousands of pages. If Autojoin has, in the best case, no "major" effect with page fields and in the worst case totally confuses the system, why is the option nor switched off and deactivated for this field type? Because it is an advanced option that may be beneficial. If auto joining one multi-value field, like a small list of category page references, you may find it beneficial when outputting a 100 item navigation list. Or you may not. It really does come down to installation specific configuration, so it's one of those things you want to test when you use it to make sure it's working and worthwhile for your case. I wouldn't want to disable the option for this Fieldtype, because I think it can be worthwhile. But it's on the advanced tab for a reason. Is Autojoin only bad for page arrays or even if the page field is set to accept only one page? Are there other fields that also have a problem with "Autojoin"? Autojoin should be fine for Page fields, especially single page fields. What I would avoid is giving several multi-value Page fields autojoin on the same template. You are more likely to run into issues there, but again, the only way to know for certain if it's going to be an issue on your installation is to test it. If you need something guaranteed to be portable across systems, then limit autojoin use to single-value text fields and such. Any multi-value Fieldtype has potential to run into installation-specific limits that could cause issues, so always treat it as an advanced option and test.

i usually use a custom module and put all of my custom admin stuff there, e.g.: public function ready(){ if($this->page->process == "ProcessPageEdit"){ $this->addHookAfter('ProcessPageEdit::buildFormContent', $this, 'mySpecialThing'); } } public function mySpecialThing(HookEvent $event) { $form = $event->return; $field = $this->modules->get("InputfieldMarkup"); $field->markupText = "<h3>My Special Thing</h3>"; $form->prepend($field); } // end function

I fully agree. "For a beginner there is just too much freedom to begin with." This is the best and the worse of PW when you are a beginner. That's where the book aims to help. What I think is to write for absolute beginners on ProcessWire, not fully beginners. People that have developed at least one website using Wordpress or other CMS in the past. So they know how to handle at least some basic PHP of course. I'm imagine the possible buyers/readers: 1. Project leaders/managers of small digital agencies that want to improve their speed on creating websites, reducing costs and problems (maybe caused by other CMS performance and security issues). He/she will buy the book (after they knew a little about PW of course here in the forums), read some pages, and give it to the developers and designers so they can learn the basics quick. I was in this situation back in 2008, the agency had a CMS developed internally, a piece of crap, so I decided to get rid of. I made some research and decided to use Wordpress at the time. For us it was perfect, and for many companies it still is, we became a reference on Wordpress. In the small agencies' market, usually there are two types of websites, one that is made to last for long time and needs to be well done and have the smaller cost of maintenance possible, and one that is more common, that is made to last for a only a couple months, because it is part of a campaign that will be off air soon. This is the one that needs to be the cheaper to develop. 2. People like ourselves, that were hooked by PW's web interface, API and so forth, that want to offers their freelance clients something easier to use and that has a better performance than Wordpress, Joomla, Modx etc. and just want to know how to start by reading a book (some people prefer to read a book than see videos or web tutorials) --- The same project leader/manager I said earlier will also need to convince her/his boss to choose ProcessWire over other choices from a market stand point, this will not be as easy. Wordpress marketshare in Brazil is huge and a lot of people don't see a reason to change because they cannot see its problems and that there's something better available. This is now their fault, that's the way it is. Some people still use SharePoint to develop websites... There is a lot of developers who claim to know how to create a website using WP, so from a HR point of view, if the agency need to contract more developers, will easier to find ones that know Wordpress. This is understandable. --- Going further, and a little off topic if I may, I also have a client that asked me some questions and I don't have numbers to answer them emphatically. Questions like: - How many big companies/websites use ProcessWire in the world. How is it compared to WP? - If you die , how long it will take to find a new developer in the market that knows how to continuing working on my website? Will it not be quicker and less expensive to find one that knows Wordpress? - If the main developer (Ryan) dies, what happens to ProcessWire, will it be actively developed? How can you assure that?

Skitch. It's great for taking quick screengrabs and then saving them to a dashboard of all your screenies.

Nice work That's not entirely correct. If you don't check the "active" checkbox under Settings when editing a page, the page is not listed for users with this language, e.g. excluded from $pages->find calls. I'm not sure what the default behaviour is when you visit the page directly in a language which is not active. Maybe you'll see the content in the default language. In this case, I'm sure you could also hook into somehwere and throw a 404 or do the prefered action.

Thanks guys. @mr-fan it needs to be production ready this week so for sure it's going to be there pretty soon. @jacmaes yes currently there is a length check in the module properties. There will be a strength check at some point, but probably not at v.1.

I just posted a comprehensive HOW-TO, that describes how get a solid and good working stripped down Ubuntu server on the Odroid c1 with also Joomla installed and with proper ownership and rights settings for Joomla combined with the server. It works great. Go here (it also solves the Dvorak keyboard issue)

# exclude the whole big-data-stuff /site/assets /site/assets/* wire /wire/* index.php .htaccess /.*/ /.* Where's the mess?

I suggest not to start right away with processwire but first wireframe your website. Checkout: https://processwire.com/api/ Available modules: http://modules.processwire.com/ select on top left for more.

And there it is: http://modules.processwire.com/modules/fieldtype-assisted-url/ https://github.com/marcostoll/processwire-fieldtype-assisted-url https://processwire.com/talk/topic/10530-module-fieldtypeassistedurl/

This has been discussed before in the forum and what I remember from it is that this needs some strategy: => leaving out writing what is thought to be necessary and write what turned out to be needed. The forum holds many repeating posts from beginners struggling with the need to think differently because Processwire differs from most other cms'es out there: no front, everything "is a page" linked with "templates" and fields and the ability to be both a cms and cmf. For a beginner there is just too much freedom to begin with. Talking about beginners, you have to distinguish between processwire beginners who already know other cms systems and cms beginners. Then you have to reflect on being able to replace your self in a beginners mind set, because the more experienced and skilled you are, the more difficult that will be.

sometimes i use 2 fields in this type of situation, one i'll call an "add item utility" and the other is the regular page select; so i can add the items in the 'utility' field and then select them in the page select; it was the only way i could come up with to achieve a similar functionality as you have described, e.g the utility field adds the item only, and then it can be selected from the other field..

Thanks Can, that's it. I'm making good progress with that module.

You could use one Field for downloads where you could upload several files and add tags them like "english", "german", etc.

I like to keep things light. I'd say look into Foxycart or Snipcart, or Moltin. Either solution still allows you to use ProcessWire while handling off commerce functionality to those other systems. Or you could built it entirely in ProcessWire like I did. Not recommended unless you really want to get your hands dirty. A lot of re-inventing the wheel (although a good learning experience).

I have done something like this half a year ago. I made an intranet for a company with 200 employees. There are no problems I heard of so far. It has a full text search, a searchable image repository with thousands of photos, every user has his own profile with his portrait... Most important thing was: every download of this intranet (PDF, Word, Excel, image files and so on...) is a page. I have build a small multi file importer which allows to upload many files at once, which leads to creation of the according amount of pages with these files attached. I did this to give each file more properties (think of it as an" asset management" - every file can have properties like view rights, tags, relations, descriptions, authors etc.). To assign this download pages to their parent "content pages" (the page the visitor sees in frontend view) I did use page tables very much. I think it works very good and I enjoyed it to develop and customize.

Regarding Problem #2: I think the best way would be to store product information in a separate part of the tree, without frontend access and then use the data from there in all the places you need them. For both problems I'd suggest you should take a look at urlSegments.

Procache cannot help with multiple requests and slow connection.

Template caching is language aware (and it includes the language as part of the cache file's id), but you'd have to have some aspect of the request determine the language before rendering the page. Otherwise there's no way to connect that cache file with the request. The simplest way to do that is to use the LanguageSupportPageNames module, to ensure that your homepage (for example) has a different URL for each language. If you are determining language from the hostname (i.e. en.domain.com, it.domain.com, etc.), then you'd have to have a before(Page::render) hook that sets the $user->language based on the hostname. I'm not sure what method you are using to determine language, so let me know and I can give you a better example.

Just clicking 'Like' doesn't seem enough. Ryan, you make it all sound so easy.

I want a hardcover copy!