justb3a

After a lot of testing I found the solution for my problem by myself. Comparing objects in a template leads to this behavior (it works using ProcessWire version 2.5.3): - <li class="nav-meta__item{% if language == user.language %} nav-meta__item--active{% endif %}"> + <li class="nav-meta__item{% if language.id == user.language.id %} nav-meta__item--active{% endif %}">

Sorry I don't have time at the moment to implement this. For translating the strings there is already an issue opened on github. For me it isn't necessary to change the order of the fields. Try to leave the checkboxes blank and add caption (for example) in other fields. I know there is a hint Do not use `orientation`, `link` or `caption` in this list. I just tested it and it seems to work. I know this solves not the problem to rearrange link and orientation field. You can also open an issue on github (or solve it on your own and send me a pull request ).

At the moment there is no way to use it more than once in a project. I guess duplicating is not that easy because you have to adapt all template and field names as well.

I use Twig as template engine and to enable string translation I wrote a litte helper function. In 2.5.x everything works well. Now I upgraded to 2.6.0 and got the following (strange) problem: Default language - everything works as expected. Second language - error (white page, stopped rendering output after first string translation) Error: Nesting level too deep - recursive dependency? Twig Helper function: $function = new Twig_SimpleFunction("__", function ($text, $filename = '') { if (!empty($filename) && $this->twig->getLoader()->exists($filename . '.twig')) { $textdomain = $this->twig->getLoader()->getCacheKey($filename . '.twig'); return __($text, $textdomain); } }); The problem occurs in wire/core/LanguageFunctions.php. In line 26 the second parameter $textdomain is supposed to be a string. * @param string $textdomain Textdomain for the text, may be class name, filename, or something made up by you. If ommitted, a debug backtrace will attempt to determine it automatically. function __($text, $textdomain = null, $context = '') { But wire/modules/LanguageSupport/LanguageSupport.module line 186 and 188 use the $this->_('string') function: 186: $this->wire('config')->dateFormat = $this->_('Y-m-d H:i:s'); 188: $locale = $this->_('C'); This calls wire/core/Wire.php line 1094. public function _($text) { return __($text, $this); } $this is passed as second parameter / $textdomain (which should be a string). But $this is in this case an object(LanguageSupport). Dirty workaround at this moment: remove translate ($this->_('string')) call in wire/modules/LanguageSupport/LanguageSupport.module and just pass string. Any ideas how to solve this without touching the core?

For those who want to upgrade to the latest core version like me, I added the following command: Common Upgrade Checks and optionally installs core upgrades. $ wireshell upgrade Available options: $ wireshell upgrade --dev --just-check --just-download Output Example ❯ wireshell upgrade A ProcessWire core upgrade is available master 2.6.0 Downloading ProcessWire Version 2.6.0... 9.35 MB/9.35 MB ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 100% Preparing new core version... Upgrade files copied. Installing new core files. Your index.php file is confirmed identical to the one included with ProcessWire version 2.6.0 so it should be safe to replace without further analysis. We have detected that your .htaccess file may contain site-specific customizations. Please double check before replacing it. Upgrade completed. Now double check that everything works. You have to replace htaccess.txt manually. A lot of the code is taken from Ryan's ProcessWireUpgrade Module.

I missed some more user commands, pls have a look here (again mismatched pull request number ). **user:create** - adds possibility to set a password **user:list** - list all users - optional: limit output by role **user:delete** - delete users by username, comma separated **user:update** - updates username, role, email, password for an existing user

Using PHP56 I can not upload files (JavaScript on): Uncaught SyntaxError: Unexpected token < Tested with PHP53 and PHP55 - works without any problem. If I deactivate JavaScript it's working for PHP56 too. If I click save, I get the following message: Pageimages: Removed 'images' temp file(s) for page /haeuser/ - 062fc62.jpg ProcessWire 2.5.29 dev

@formmailer: You do not missed something. It's not possible at the moment. I could imagine to add a checkbox in the module setting to enable markdown. Could you open an issue on github or send me a pull request? I've no time at the moment to implement this. Thanks.

@biber Hi, just to make sure: you visit the page in the frontend? That means you do not see the text output if you are not logged in. Strange. Do you see the images? Or is everything missing? Could you (temporary) try to disable the module and use the built-in functionality including description. Just to make sure it depends on the module.

I downloaded and installed the module yesterday so it should be up to date. But I did not notice that you be able to choose the twig version in module settings. Default is set to 1.15.0. I changed the version to 1.18.0 but I still get the same error message. Maybe it depends on the ProcessWire version!!, I use 2.5.3 in this project. Error: Exception: An exception has been thrown during the rendering of a template ("Method Page::template does not exist or is not callable in this context") in "partials/html-end.twig" at line 25. (in /../public/site/modules/TemplateTwigReplace/Twig-1.18.0/Twig/Template.php line 304) Edit: It works on the dev branch using twig 1.18.0 Thanks for your feedback

no way! This leads to: Error: Exception: An exception has been thrown during the rendering of a template ("Method Page::template does not exist or is not callable in this context") in "partials/nav-sub.twig" at line 3. (in /../public/site/modules/TemplateTwigReplace/Twig-1.15.0/Twig/Template.php line 291) I'm just able to debug this statement {{dump(page.template)}}. See the reason above:

I know, this topic is not up to date, but I got the same problem and here is my solution: {{page.get('template').get('name')}}

I missed the possibility to download a module from github if it doesn't exist in the ProcessWire module directory or if you need a specific branch. Added.

It should be clear that the module should echo, I removed the echo keyword from my documentation because if you download for example ProcessWire, it contains some basic templates and you will need $content = $modules->get('SimpleContactForm')->render(); to output the form. So if you use a template prepend file or if you use for example TemplateDataProviders it differs. I think about that, for now just enter antiSpamTimeMin = 0 (Maybe I should set this as default?), antiSpamTimeMax = 1000 and antiSpamPerDay=1000. This modules creates two log files (→ documentation), have a look there to figure out what is wrong. If you were redirected to the homepage (→ documentation) the reason is always spam protection. If you change the markup make sure to maintain the names of the fields and you have to hide website(honeypot field) and submitted (→ documentation). If you change the number of inputs manually (adding or deleting a field), you have to adapt antiSpamCountAdditionalInputs (→ documentation). You enter the fields as a comma separated list, maybe there will be more textarea fields like `message`. How should I know which one should be a textarea and which one a simple input or maybe a date input (for example). This module provides some templates as starting point, you have to change / adapt the html! The honeypot field is also displayed because it's better to add a surrounding div assigning a class and hide it using CSS. Feel free to contribute! You could at least help me to improve the documentation! Nobody has to use this module! Go ahead and use formbuilder. You can fill out the form in less than one minute, just set timeMin = 0! It's the same as disabling spam protection. There is much more spam protection and of course there is already a honeypot field.

I've just started a new project and decided to test/use Wireshell. After I had successfully created a new project I missed the opportunity to download modules. You've received a new pull request. Maybe you have some time to test (and hopefully implement) it.

I do not want to start a discussion and I can definitely understand both points of view. It's better to contribute to an existing module as reinventing the wheel again and again. But sometimes it's also good to have the possibility to choose between modules so you be able to pick the module which fits the best to your needs. Had I known what was awaiting me during this project, I maybe would have used the existing validation module. On the other site, processwire comes with some great sanitizers which are designed for the special processwire purposes (for example $sanitizer->username). An external validation library will never support this but sometimes you do want to test exactly such behavior and it's already there. Why not use this?