Leaderboard

Hello, I would like to present you a new module which aim to facilitate the productivity of your editors/publishers when working on ProcessWire. The idea begun when my co-worker told me that when typing in ProcessWire CkEditor field he was feeling "loosing motivation" when writing big wall of text and/or inspiration. So he opened his web-browser and show me a site looking to Wordpress - feel free to put your preferred emoji here - then he opened Gutenberg... typed some text and moving some "blocks". I understood immediately why he got this feeling with CkEditor. If you or your client feel like this guy, then you will love this module ! What is currently supported ? Features Auto-save Medias upload support HannaCode support Blocks Implemented Heading Image Paragraph Embed Quote Code Link Table (beta) Block Delimiter Raw HTML Note (custom block markup) Feature Request Frontend Edition And there you go for the preview - sorry I am to lazy and bad at typing text so I had a copy/pasta moment : Module featured in the ProcessWire Weekly #317 - Thanks @teppo

Finally, a blog post this time ? — ProcessWire 3.0.159 brings some useful and time-saving upgrades to the core two-factor authentication system: https://processwire.com/blog/posts/pw-3.0.159/

This could be a block builder option? https://grapesjs.com/ https://github.com/artf/grapesjs Newsletter demo: https://grapesjs.com/demo-newsletter-editor.html Webpage demo: https://grapesjs.com/demo.html Usage: <link rel="stylesheet" href="path/to/grapes.min.css"> <script src="path/to/grapes.min.js"></script> <div id="gjs"></div> <script type="text/javascript"> var editor = grapesjs.init({ container : '#gjs', components: '<div class="txt-red">Hello world!</div>', style: '.txt-red{color: red}', }); </script> That's it.. I try it before, but I don't know how to build a module ?

If I got what you mean (compatible Fieldtype ?) it's already the case, you can drop a textarea then choose EditorJS, CkEditor or the vanilla textarea as field. Sure ! On my side, it's the possibility to fetch those JSON data directly into the third party apps (mobile, desktop, etc). Glad to hear that someone tried to implement this editor solution. Could you elaborate on why it wasn't a great success ? As a non-editor who I am, I really like what I feel writing thing on this fieldtype. About RepeaterMatrix, I think (and we already saw some posts here in the forum) that it could be used to make a page builder, but thats not intended by this module.

You already know that you might have to backup and upgrade your site to the new master. Since this version (3.0.62) there have been a number of various fix including repeater.

The naming convention is actually the page ID, so 1234 in your example is the page whose id is 1234.

Thanks @teppo for your insight, as always highly appreciated. I got what you mean. I think that there is a part of question of taste but also depending on the task on which the user is involved/focused. In first instance, while discussing with the colleague, I started to insist that he could use the CKEditor to write his articles; The point is here, he is specialised in content creation. I also suggested MS Word as tool - but no, the UI is not soft as Gutenberg. Then I abdicated and told him to write his articles on Gutenberg and a local install of Wordpress, after all, I will not touch at it, and I can import the content of a Wordpress page to ProcessWire. I don't know if you guys are used to write content, but this guy showed me also the editor that was crafted for the big site Medium. It's something similar, polished, the editor contain an inline toolbar and some blocks. I understood then that it's like an "new" category of users, they are used to write content in a modern environment. I was not even aware of those type of editor / blocks approach ? . So yes, I can understand that it can be "intimidating". Yes! First mission that was to bring back this guy to use ProcessWire is almost done ?? @Pixrael Yes it could. The module you would like to see was already mentioned and I remember that Theo, Elabx and Joshua worked on something. It was not grapejs but the idea remain the same. If you really want to give a try and invest some time the community will help you ! @bernhard wrote nice tutorials on modules creation you could begin with, then start a new thread here in the modules/dev forum. There are some hard works in perspective and I think that a module like that should be taken by a group with dev and designers ?

You'd be setting yourself up for all sorts of complications. You really don't want to go there. How so? Manually finding files?

Sorry @rick not yet, there is a chance that the module will be released as ProModule with refund policy to be able to try the module.

I am talking about multi-instance ? not multi-site. They are two different things. // public site $somePage = $pages->get('/some/page/'); // second site // create instance $site = new ProcessWire('/path/to/www/', 'http://domain.com/'); $stuffFromSecondSite = $site->pages->find("template=very-important-stuff,sort=-created, limit=3"); // do whatever with $stuffFromSecondSite No namespace issues using above.

Cacheable Placeholders This module allows you to have pieces of dynamic content inside cached output. This aims to solve the common problem of having a mostly cacheable site, but with pieces of dynamic output here and there. Consider this simple example, where you want to output a custom greeting to the current user: <h1>Good morning, <?= ucfirst($user->name) ?></h1> This snippet means you can't use the template cache (at least for logged-in users), because each user has a different name. Even if 99% of your output is static, you can only cache the pieces that you know won't include this personal greeting. A more common example would be CSRF tokens for HTML forms - those need to be unique by definition, so you can't cache the form wholesale. This module solves this problem by introducing cacheable placeholders - small placeholder tokens that get replaced during every request. The replacement is done inside a Page::render hook so it runs during every request, even if the response is served from the template cache. So you can use something like this: <h1>Good morning, {{{greeting}}}</h1> Replacement tokens are defined with a callback function that produces the appropriate output and added to the module through a simple hook: // site/ready.php wire()->addHookAfter('CachePlaceholders::getTokens', function (HookEvent $e) { $tokens = $e->return; $tokens['greeting'] = [ 'callback' => function (array $tokenData) { return ucfirst(wire('user')->name); } ]; $e->return = $tokens; }); Tokens can also include parameters that are parsed and passed to the callback function. There are more fully annotated examples and step-by-step instructions in the README on Github! Features A simple and fast token parser that calls the appropriate callback and runs automatically. Tokens may include multiple named or positional parameters, as well as multi-value parameters. A manual mode that allows you to replace tokens in custom pieces of cached content (useful if you're using the $cache API). Some built-in tokens for common use-cases: CSRF-Tokens, replacing values from superglobals and producing random hexadecimal strings. The token format is completely customizable, all delimiters can be changed to avoid collisions with existing tag parsers or template languages. Links Github Repository & documentation Module directory If you are interested in learning more, the README is very extensive, with more usage examples, code samples and usage instructions!

In terms of making the core smaller, can the old admin system (ie, the contents of /wire/templates-admin/ I believe it is) be done away with? The admin that looks like this: https://i.ytimg.com/vi/eq-9GQCT0lw/maxresdefault.jpg

@Martijn Geerts - many thanks for taking the time to make the fix here! I will implement is and do some tests and update the module soon.

That line wants to execute ProcessPageView. The error means that line 53 returned null: $process = $wire->modules->get('ProcessPageView'); /** @var ProcessPageView $process */ My guess is that files were either not transferred correctly, or fully or were corrupted. FTP can be notorious for converting files on route! (ASCII vs Binary) I'd suggests this: Upload a zip of ProcessWire Unzip the files when they are on the server Install ProcessWire Upload a zip with the file assets Unzip the assets Do the database import Alternatively Install ProcessWire on the server using this script by Soma (you might need to edit it first) Follow steps #3 - 6 above Later, you can sort out your FTP file transfer settings.

To be clear I wouldn't say that it was a failure by any means — more like we didn't see major benefits going with Editor.js vs. Repeater Matrix + CKEditor. "Results were inconclusive" ? Like you said, Editor.js probably isn't going to replace Repeater Matrix if what you really need is a block builder; at least it doesn't seem like a good idea at the moment. While it could definitely help with some tasks that CKeditor currently isn't very good at — such as embedding images — at the same time the "every element is a block" approach can also feel a little intimidating and perhaps even unintuitive for those more familiar with "traditional" content editors (CKeditor, Word, etc.) Should probably also mention that I did my proof of concept back in March, when the Editor.js project seemed a little... unresponsive. There were big missing parts (including i18n support) and issues that were not getting much attention. Now that I've checked, it appears that the project is going strong again. Hope this makes sense. All in all I'm very curious to see where you're going with this module! ?

I'm not sure I understand your goal here. When you are coding your template files, Processwire sets $page to the current page. Therefore, the $page->id represents that page. I don't know why you would want to change the id. Or are you referring to a custom URL?

This is amazing, @flydev ??!! Looks very useful!

Interesting, I was thinking that ProcessWire could do with a couple of alternatives to the dated CK Editor. EditorJS is one of those 'modern' editors (I was also looking at Quill), I definitely like the block-based output in JSON format. In the end I think it would be nice to be able to change the editor implementation library for textarea fields on the fly – like having a textarea field where you can select between CK Editor, EditorJS, TinyMCE etc. and being able to easily add other editors through a hook or something. Edit: Obviously this should be changed in the field settings per site, not configurable by editors themselves!

Finally got onto trying this out and confirm fix works - thanks for your help ?

Intrigued! As it happens, I have InputfieldEditorJS + FieldtypeEditorJS proof-of-concept sitting on one of my own sites as well. Mostly functional, though your module looks way more polished. I never got to implement media uploads, for one. It was intended as a test to see if our team would prefer that over Repeater Matrix, and since it wasn't a massive success, I never fully completed it. Very much looking forward to seeing your module in action ?

@rick Thanks, dude! OMG more reasons to love Processwire.

Got a link?

That is correct.

Hello @Pip, 1. Go to Setup > Templates and click the template you want to edit. Processwire displays a list of fields. 2. Click the Title field and enter the new title text you want displayed. 3. Click save. You can change any Label of any field in any of your templates to better suit your requirements.

No worries. Moved to to the right place.

I haven't done this before (split websites) but what you describe seems doable using ProcessWire's multi-instance capability. That would require that both sites are on the same server though. https://processwire.com/blog/posts/multi-instance-pw3/

I'm sure it's the less used path, but a CLI is useful for anybody automating deployments either using some kind of CI/CD or manually called scripts. The goal of my migrations module was to result in reproducable db state, so automation is possible. If migrations can be run arbitrary times it's not going to do that – e.g. a field created and later deleted is not the same as a field deleted and later created. Therefore migrations have a fixed order (by timestamp) and a db table keeps knowledge about which migrations were already applied before.

@Macrura First of all I love SettingsFactory! I've seen notices before in SettingsFactory when I add new fields but not yet saved the value. In this complicated setup I have here this notice prevents the PageList from being loaded. SettingFactory->getSettings() triggers the notice on line 152. // Locally i have changed the if statemaent on line 151: } else { $newDataArray[$key] = $dataArray[$key]; } // To this: } else if (isset($dataArray[$key])) { $newDataArray[$key] = $dataArray[$key]; } Without looking much in to this, this fixes it for me.

Didn't take that as offense at all ? Just tried to make clear that I have already thought of that but I don't plan to implement it any time soon. But if anybody would be up for it, I'd be more than happy to assist or to pull the changes ? Sorry if that was not clear.

Didn't want to imply your module needs anything or that it is "missing" something or that I was asking for a feature, I apologize if that's how it came out! Just wanted to give an example of an exception to the norm in case anyone finds this thread and of course, I agree it's the mission of all of us to contribute to open source and I must say this community has inspired me a lot to thrive into that direction rather than just consuming the work of others but also contributing, first step is to solve the very serious personal time management issues I have and just force me to do get open source done lol. So basically how it's useful for me is that, I keep a bunch of sites on one server and they all share template files and fields configuration. I keep files in sync using git and git worktrees, and with a shell script I make merges from the dev branch into the rest of the branches, including the migration files (each site is a branch). Then, if I need to make an update that involves any adding/removing fields I also have another shell script that goes on every site directory and runs a specific migration. It saves me a lot of time to run this for the 50+ sites I manage, I can very easily see if an error occurred, if migration was already run, if it didn't exist (then it means that site is now correctly wired up to the git repo), etc. Probably this is the least likely scenario of most PW users lol, as I have the feeling that most of PW users build heavily customized sites, for very specific requirements.

By the way, a quick workaround, if you insist on living on the edge is to do the following: Edit a Media Manager field (e.g. media_manager_image) Change its Use Tags setting and save Revert the change to what it was before and save again Uploads should now work. Note though that using the 'Cleanup' feature might still throw the PDO error linked to in the post above.

Hi all, A recent change in ProcessWire has partly broken part of Media Manager's upload feature (see the screenshot in this post with the PDO error, thanks to for @Mustafa-Online reporting). My strong feeling is that it has to do with the recent changes to the Database Class(es). I am looking into this and will report back as soon as I can. Thanks.

I got a solution (maybe there are others better than mine) public function init() { if($this->wire('user')->isSuperuser()) { $this->wire()->addHookAfter('ProcessPageEdit::buildFormSettings', $this, 'buildForm'); $this->wire()->addHookBefore('Pages::saveReady', $this, 'saveForm'); } } public function buildForm(HookEvent $event) { $p = $event->object->getPage(); $inputfields = $event->return; $data = wire('modules')->getConfig($this); $fieldset = $this->wire('modules')->get("InputfieldFieldset"); $fieldset->attr('id', 'my_fieldset'); $fieldset->label = __("My Renders"); $fieldset->collapsed = Inputfield::collapsedYes; $field = $this->wire('modules')->get("InputfieldTextarea"); $field->attr('name', 'renders'); $field->attr('value', $data['RendersPages'][$p->id]['renders']); $field->label = $this->_('Renders'); $fieldset->append($field); $inputfields->append($fieldset); } public function saveForm($event) { $data = wire('modules')->getConfig($this); $data['RendersPages'][$this->input->post->id]['renders'] = $this->input->post->renders; $this->wire('modules')->saveConfig($this, $data); }

As i mentioned before; I started my own e-commerce project and had to say i was afraid at beginning. This is my first OOP project, so i spent some time to find my way. But i am very happy when i see my progress and the results step by step... It will surely not as future rich as Padloper but my clients do not use many futures anyway. Mainly the general things.... Hope to present my first Ecommerce project on PW here soon....

Thanks for this @horst ! The workaround looks way cleaner than using additional fields or checkboxes. Additionally, we'll be setting the actual secondary language slug (f.ex. "en") instead of "onlySecondary" as default page title (for pages which only contain secondary language data) in order to pass on the specific language information. Best, -N.

I appreciate the effort here, but remember @kongondo that many of us aren't looking for that full list of features from your original post two years ago. I'd much prefer a performant cut down version and the ability to give you some money for ongoing development than one giant release with all the bells and whistles. MVP > feedback from real customers > new releases. Thanks and i hope everybody is okay considering the current climate =D

Yes, it's on the dev branch. I applied fixes on the current master version until the next master. So far so good.

Hi @Greg Lumley, Implementing a "user admin" on the front-end isn't difficult because of PW's API -- In theory, that is. If you aren't familiar with PHP, or aren't familiar with the API, then it obviously will be a little more difficult. You can ask any questions here in the forum and a plethora of highly-skilled programmers will be glad to help. That's another big selling point with PW vs any other. The community support is second to none. The following is an example break-down of one of my sites. I have one site where specific users have the only permissions to access specific pages. All other users could only view pages. Think of it like the *nix RGE permission structure, where Root is super user, Group is any registered user, and Everyone else is a guest just visiting. PW initially gives you the Root and Everyone roles, so you will need to add the Group role. You can name it what you want. And since I don't let *any* user access the PW admin, I don't need to specify any permissions, such as page-edit, etc. I use Processwire's built-in page management to further limit a user to only their pages. Specifically, all pages have a created_users_id, and other information that is saved each time a page is created or updated. So when a user wants to create a new entry (page) their $user->id is assigned to the created_users_id property. Now I have a one-to-many relationship between a user and all of their pages. I also have different sections where a user can create a page. For example, when a user logs into my site acme.com, they can create a page under "high-explosives", and another page under "jet-powered devices". They may not wish to create a page under any other section. Each section has it's own template, so I can easily use selectors to retrieve the user pages by section, or even retrieve all pages. The front-end "user admin" interface is simply a two column layout with a menu on the left and the content on the right. I use the Group role to determine the menu options. I obviously don't want one user viewing details of another user, except for me as super user (Root). This also restricts the admin page(s) from view by the Everyone (Guest) role. I also have a drill-down capability from this initial user admin page to get more specific details. Each user can manage their own personal data page as well. That is the basic overview. The next thing are the modules. If you do not have your own login system then I would recommend LoginRegisterPro as it covers all the bases (register, login, forgot password, etc.) that you will need for your user access requirements. I am currently looking into implementing @bernhard's RockFinder3 module to handle queries because I have many users and they each have many pages and I want to be as efficient as possible. You must have TracyDebugger. That is a requirement (should be in core ? ). It will save you many hundreds of hours of scratchin' your head. You may elect to use other modules, such as caching, etc. These are just the minimum I would recommend for a project like yours. I hope this helps.

There were lots of core updates this week, very much in the same theme as last week — major long term quality improvements for the core, but no shiny toys to play with… Just lots of good and solid foundational core improvements, and a few fixes too. It's mostly kind of technical stuff that's probably not that interesting to read about, so I'll keep this short, but for those interested here's the commit log. Thanks for reading and have a great weekend!

Very good news for the weekend: RockFinder3 does now work again with the latest dev version of PW (thx to @adrian for making Ryan aware of the issue that also affected tracy!) ? v1.0.6 is up and running smoothly and ready for a long future ? $owners = $rockfinder3 ->find("template=person") ->addColumns(['title', 'age']) ->setName('owner'); // set name of target column db($rockfinder3 ->find("template=cat") ->addColumns(['title', 'owner']) ->join($owners) ->getSQL()); SELECT `pages`.`id` AS `id`, `_field_title_5ed16c868e555`.`data` AS `title`, GROUP_CONCAT(DISTINCT `_field_owner_5ed16c868e66d`.`data` ORDER BY `_field_owner_5ed16c868e66d`.`sort` SEPARATOR ',') AS `owner`, GROUP_CONCAT(DISTINCT `join_owner_5ed16c868ea01`.`title`) AS `owner:title`, GROUP_CONCAT(DISTINCT `join_owner_5ed16c868ea01`.`age`) AS `owner:age` FROM `pages` LEFT JOIN `field_title` AS `_field_title_5ed16c868e555` ON `_field_title_5ed16c868e555`.`pages_id` = `pages`.`id` LEFT JOIN `field_owner` AS `_field_owner_5ed16c868e66d` ON `_field_owner_5ed16c868e66d`.`pages_id` = `pages`.`id` LEFT JOIN ( SELECT `pages`.`id` AS `id`, `_field_title_5ed16c868de1f`.`data` AS `title`, `_field_age_5ed16c868dea8`.`data` AS `age` FROM `pages` LEFT JOIN `field_title` AS `_field_title_5ed16c868de1f` ON `_field_title_5ed16c868de1f`.`pages_id` = `pages`.`id` LEFT JOIN `field_age` AS `_field_age_5ed16c868dea8` ON `_field_age_5ed16c868dea8`.`pages_id` = `pages`.`id` WHERE (pages.templates_id=48) AND (pages.status<1024) GROUP BY pages.id ) AS `join_owner_5ed16c868ea01` ON `join_owner_5ed16c868ea01`.`id` = `_field_owner_5ed16c868e66d`.`data` WHERE (pages.templates_id=44) AND (pages.status<1024) GROUP BY pages.id PS: I decided to change the case of the API variable from $RockFinder3 to $rockfinder3 (all lowercase)!

ProcessWire 3.0.157 on the development branch continues the trend of core refactoring that’s been happening quite a bit in 2020. Rather than doing a rewrite every few years (like some CMS projects) we instead refactor parts as we go, constantly improving and optimizing the core. This works because the core design/architecture is right where it needs to be, even 10 years in. But there’s always still bits of legacy code, and code that can be improved. So in the context of ProcessWire, refactoring means incrementally rewriting code on the inside, without changing its behavior on the outside (other than making it faster and/or more secure). This has been happening regularly over the last 10 years, and will likewise continue happening over the next 10 years and likely beyond. This week the code behind ProcessWire’s core Database and PageFinder classes got a major refactoring. This is some of the most used code in PW, as it handles everything involved in taking a selector and converting it to a database query. But it’s always been a little bit of a pain point for me because it had to build queries in a way that I thought wasn’t ideal, in order to make it possible for lots of different modular parts (mostly Fieldtype modules) to contribute to the query and for PageFinder to put it all together. It was fast and secure, but still one of those parts that felt like a little too much duct tape to me. But considering how crucial the code is, I’ve always been reluctant to make major changes, since it all worked just fine. Spending lots of years thinking about it (on and off), a desire to work out any pain points, and having better tools available (like Phpstorm and Tracy) made it possible to finally massage out this pain point. Some work still remains to be done, but it’s mostly there and I’m feeling good about it. Stuff like this is key for the maintenance and longevity of the core, and involved a lot of time and effort, but makes very little difference to users, even if it makes a lot of difference to me in maintaining the core. It would make a boring blog post for sure—lots of work and changes, but no new toys to show for it. Nevertheless, it has that feeling of a good house cleaning, even if you can't see it from the outside. The scope of changes here means that there may actually be new bugs to work out, so to be on the safe side, consider 3.0.157 to be a little more “beta” than the dev branches usually are. Though I’m running it here on processwire.com and it’s working well. Beyond the fairly major updates to the Database classes, there are also a few new Sanitizer convenience methods that are primarily variations on existing ones, but useful ones for sure. Thanks for reading and have a great weekend!

This is a reworked website of Imre Baksa, a Hungarian actor and director. His former (static) website was also made by me back in around 2009. He asked me to do a redesign but I decided to involve ProcessWire to make content management easier. http://baksaimre.hu/ Lesson 1: templates - no thanks It is tempting to use ready-made templates for a project because most of the work is done, there's some tweaking here and there and mission completed. Okay, this is the theory. I have to admit that I have never found a suitable template/theme for my projects, but being a web designer this is the way it should be, I guess. This time I found one that looked fine: Landed from HTML5 UP. In fact there was a self-made design for the site and this template looked 90% similar, so it really seemed to be an easy task to bring it into ProcessWire. Soon turned out that some of the fancy features of the template required advanced JavaScript knowledge. That means, I had to dive into it and learn how it worked. I did so and I was able to tweak things then, but I wasn't satisfied with the outcome. So I went back to the drawing board and dropped the template. This experience reassured that starting from scratch would have been a better choice on the long run. The good thing is that I learned some new things that will come in handy in the future. Lesson 2: template engines - Latte is still my best friend I was using Nette's templating engine, Latte in previous projects and I liked it a lot. It is similar to Twig, which is more widespread, so I decided to try that for learning purposes. This sounded like an easy journey because ProcessWire supports Twig through modules. However, at the end of the day I sort of regretted that. Latte has some small helper features that makes templating easier, and these differences made up a huge difference. Maybe I'm getting old but I felt Twig more of a nuissance after Latte. Finally I got rid of Twig and I guess I will never look back I will keep using Latte in the future even if I have to bootstrap it manually. Lesson 3: frontend development is hard Having ProcessWire at hand, backend is the minor part in web development, at least in smaller projects. I've used only a few jQuery plugins but making them work together nicely was a real challenge. At the end I had to make a compromise by removing SmoothScroll because it didn't work well with JScrollPane. Even so, I had tough times to eliminate content "jumps" when a lightbox is opened, and to make JScrollPane work the way I wanted to work. Making the whole thing responsive added another level of complexity as features needed to be destroyed/reinitialized on different screen sizes. I like to polish things as much as possible but the current state of the web makes it almost impossible to reach certain level of perfection. Moduling up This was the project where I felt that a link checker button would be helpful so started to develop InputfieldURLChecker. I use this in a few projects and it does the job nicely. My other pet PW module FEEL also got some polish during site development. For site-wide settings I used MultiValueTextformatter so I didn't need to create a field for every setting, just one for all. Other modules used: SEO: must have! Admin Template Columns for better admin layout Page List Image Label: to add featured image to the list of pages in the admin Pageimage Remove Variations: remove unused image variations Forms: one step closer to simpler form processing For the contact form I used Nette Forms, because it is so easy to add forms to the site with it, with frontend & backend validation in one go. Processing them still needs some sweat, but this time I finally put together a class to make this easier. Surely it still needs some iterations but it's a huge help: it takes only a few parameters to save submissions as Pages or send email to the admin or the visitor. For email templates I also used Latte (what else? ). I also created a "json_storage" field to store submission. The beauty is that while it's only one field (a textarea), in the admin it is displayed as formatted key-value pairs using a hook. Summary The site looks fresh and the year knob on the left makes it fun to use. Content management is easy as 1-2-3 thanks to ProcessWire, even if it's mostly me who will deal with the updates. While it's not visible on the site, in the background there are many improvements to my development tools and workflow that will be of huge help in the future.

Hi, i found solution and i would like to post it here. Maybe it helps someone. i removed echo $searchresults->toJSON(); i used the code below instead of toJSON function $myPages = $pages->find('template=clinic|doctor|treatment|location|resource'); $data =$myPages->explode(['title', 'url']); echo wireEncodeJSON($data); now it shows the current language results You have to set the $.typeahead({ cache: false, if you dont set cache : false it still show the cached language result even you change the language.

Docker (http://www.docker.com) is an open platform for building, shipping and running distributed applications. Docker containers are a great way to package a complete application with its specific dependencies in a portable way so that it can easily be deployed on any compatible network or cloud infrastructure. Recently I spent a few days making my ProcessWire site run in a Docker container, and - as I could not find any good tutorial for this - it sounded like a good idea to write one. You will find on the web plenty of presentations and tutorials about Docker, so I won't start with the basic concepts, and this tuto assumes that you have a first understanding of Docker's fundamentals. What we want to do here is to migrate an existing site to a set of docker containers. Therefore, to start with, you should have: - docker installed on your computer; - the site directory of your ProcessWIre site - a backup of your site's MySQL database Let's start. Create a docker container for the site database For several reasons (insulation, security, scalability), it is preferable to host the site database in a separate docker container. 1. Set-up a SQL database with MariaDb or MySQL $ docker run --name database -e MYSQL_ROOT_PASSWORD=rootdbpassword -d mariadb Here I choose to use the MariaDB official container in its latest version, but MySQLwould be just fine as well. 2. Run a PhpMyAdmin container and create the ProcessWire database We first select an simple image with PhpMyAdmin on the Docker Hub: nazarpc/phpmyadmin and we create a docker container based on this image. This container will access the port exposed by the database container via a private networking interface. We specify this with the `--link` option. It can be run temporarily (and exited by ctrl-C): docker run --rm --link database:mysql -p 8881:80 nazarpc/phpmyadmin Or it can be run as a daemon in the background: docker run -d --name phpmyadmin --link database:mysql -p 8881:80 nazarpc/phpmyadmin From phpmyadmin (accessed from your browser at http://hostaddress:8881) you can now create your ProcessWire database, create a dedicated user for it, and import the database content from a previously saved SQL file. Note: alternatively, you can do all database operations from the command line in the database docker container created during step 1, or use another mysql user interface container if you prefer… 3. Update the database parameters in your site configuration In your site's `config.php` file, the sql server name shall be set to `mysql`: $config->dbHost = 'mysql'; Other `$config->dbXxx` settings shall match the database name, user and password of the just-created database. Create a Docker Image for Apache, PHP and the Processwire site 1. Create an image-specific directory with the following contents and `cd` to it bash-3.2$ ls -l . config .: total 16 -rw-rw-rw- 1 jean-luc staff 1163 21 aoû 12:09 Dockerfile drwxr-xr-x 17 jean-luc staff 578 17 aoû 12:48 ProcessWire drwxr-xr-x 7 jean-luc staff 238 21 aoû 12:07 config drwxr-xr-x 7 jean-luc staff 238 20 aoû 18:46 site config: total 160 -rw-rw-rw- 1 jean-luc staff 160 20 aoû 18:28 msmtprc -rw-rw-rw- 1 jean-luc staff 72518 20 aoû 18:56 php.ini where: `ProcessWire` contains the version of ProcessWire that we want to use for this site; It can be retrieved from github with a link like https://github.com/ryancramerdesign/ProcessWire/archive/{version}.zip` For example, the 2.6.13 dev version can be obtained by the link https://github.com/ryancramerdesign/ProcessWire/archive/7d37db8d6b4ca6a132e50aff496a70e48fcd2284.zip `site`: our site-specific files `Dockerfile`: the dockerfile for building the image (see below) `config`: a directory containing specific configuration files copied to the docker image (see below) 2. Set the `Dockerfile` content FROM php:5.6-apache RUN apt-get update \ && apt-get install -y libfreetype6-dev libjpeg62-turbo-dev libmcrypt-dev libpng12-dev zziplib-bin msmtp\ && a2enmod rewrite \ && a2enmod ssl \ && docker-php-ext-install mysqli pdo_mysql iconv mcrypt zip \ && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \ && docker-php-ext-install gd EXPOSE 80 EXPOSE 443 # Add a specific php.ini file COPY config/php.ini /usr/local/etc/php/ # Configure the mail sent utility msmtp (http://msmtp.sourceforge.net) and make it readable only by www-data COPY config/msmtprc /usr/local/etc/php/ RUN chmod 600 /usr/local/etc/php/msmtprc \ && chown www-data:www-data /usr/local/etc/php/msmtprc # Remove all default site files in /var/www/html RUN rm -fR /var/www/html/* # Copy ProcessWire core files COPY ProcessWire/wire /var/www/html/wire COPY ProcessWire/index.php /var/www/html/index.php COPY ProcessWire/htaccess.txt /var/www/html/.htaccess # Copy site-specific files COPY site /var/www/html/site # Make www-data the owner of site-specific files RUN chown -R www-data:www-data /var/www/html/site VOLUME /var/www/html/site Based on the official image `php:5.6-apache`, it installs missing packages to the system, adds mod-rewrite and mod-ssl to Apache, plus a number of PHP modules needed by Processwire (core or modules): mysqli, pdo_mysql, iconv, mcrypt, zip, and gd. Then it copies the site files to the location expected by the Apache server. Finally it declares a Docker volume `/var/www/html/site` (i.e. the site files and assets), so that it can be shared with other containers. 3. Set the msmtp configuration We need to configure a sendmail utility, so that we can send emails from php, for example when a user registers on the website. The simplest way to do it is to rely on an external smtp server to do the actual sending. That's why we use msmtp. - define the desired smtp account in `config/msmtprc` account celedev-webmaster tls on tls_certcheck off auth on host smtp.celedev.com port 587 user webmaster@celedev.com from webmaster@celedev.com password thepasswordofwebmasteratceledevdotcom - in `config/php.ini`, configure the sendmail command so it uses msmtp: sendmail_path = /usr/bin/msmtp -C /usr/local/etc/php/msmtprc --logfile /var/log/msmtp.log -a celedev-webmaster -t 4. Build the Docker image docker build -t php-5.6-pw-celedev . 5. Create a Data-only container for the site files docker run --name celedev-data php-5.6-pw-celedev echo "Celedev site data-only container" 6. Run the web server container docker run --name celedev-site -p 8088:80 --link database:mysql --volumes-from celedev-data -d php-5.6-pw-celedev Note that this container is linked to our database and shares the 'celedev-data' volume created previously During development, it can be convenient to keep an access to the host file system from the container. For this, we can add a shared volume to the previous command: docker run --name celedev-site -p 8088:80 --link database:mysql -v /Users/jean-luc/web/test-docker:/hostdir --volumes-from celedev-data -d php-5.6-pw-celedev Our ProcessWire website is now up and running and we can test it in our browser at http://hostaddress:8088. Great! What we now have in Docker bash-3.2$ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE php-5.6-pw-celedev latest 2aaeb241c2e2 3 hours ago 1.149 GB nazarpc/phpmyadmin latest e25cd4fd48b3 8 days ago 521 MB mariadb latest dd208bafcc33 2 weeks ago 302.2 MB debian latest 9a61b6b1315e 5 weeks ago 125.2 MB bash-3.2$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 68cc5d976f0d php-5.6-pw-celedev "apache2-foreground" 20 hours ago Up 20 hours 443/tcp, 0.0.0.0:8088->80/tcp celedev-site 0729fe6d6752 php-5.6-pw-celedev "echo 'Celedev site d" 20 hours ago Exited (0) 20 hours ago celedev-data e3e9e3a4715c mariadb "/docker-entrypoint.s" 3 days ago Up 3 days 3306/tcp database Saving the site data We can create an archive of the site files by running a tar command in a dedicated container: bash-3.2$ docker run --rm -it --volumes-from celedev-data -v /Users/jean-luc/web/test-docker:/hostdir debian /bin/bash root@2973c5af3eaf:/# cd /var/www/html/ root@2973c5af3eaf:/var/www/html# tar cvf /hostdir/backup.tar site root@2973c5af3eaf:exit bash-3.2$ Tagging and archiving the Docker image We can also add a tag to the docker image that we have created in step 4 (recommended): bash-3.2$ docker tag 2aaeb241c2e2 php-5.6-pw-celedev:0.11 bash-3.2$ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE php-5.6-pw-celedev latest 2aaeb241c2e2 3 hours ago 1.149 GB php-5.6-pw-celedev 0.11 2aaeb241c2e2 3 hours ago 1.149 GB nazarpc/phpmyadmin latest e25cd4fd48b3 8 days ago 521 MB mariadb latest dd208bafcc33 2 weeks ago 302.2 MB And we can archive this image locally if we dont want to push it now to the Docker Hub: bash-3.2$ docker save php-5.6-pw-celedev:0.11 | gzip > php-5.6-pw-celedev-0.11.tar.gz And that's it! You now have a portable image of your ProcessWire website that you can run directly on any docker-compatible system.