kixe

@PWaddict Module works as expected. No failures here. Thanks, but I have no need for your suggestions. Feel free to fork it and adapt it for your needs.

It depends on your server settings. You should play around a bit with LanguageSupport:: _('C') translation strings. In my local environment I am getting the following results in a test template: setlocale(LC_TIME , 'de_DE'); echo $page->mydatetimefield; // getting Mai-27-2017 setlocale(LC_TIME , 'en_EN'); echo $page->mydatetimefield; // getting Mai-27-2017, expecting May-27-2017 setlocale(LC_TIME , 'en_US'); echo $page->mydatetimefield; // getting May-27-2017 As you can see I am not able to solve this via the module. Have also a look here http://stackoverflow.com/questions/10909911/php-setlocale-has-no-effect

Sorry for the trouble. I tested with translations 'en_EN' for default and 'de_DE' for german and it works. If I set german as default it doesn't work. I will have a deeper look asap.

@PWaddict Thanks for pointing on LanguageSupport::_('C'). I pushed an update 2.0.5 which is aware of this.

@PWaddict OK. I fixed the issue. For datetimefields the format will be pulled from the field settings including strftime formats. Datetime fields are not true multilanguage fields. The language-specific output of a datetime field can not be influenced by changing the user language. In a template, the output will be language-sensitive only by using setlocale() and if strftime formats for output are set in the datetime field settings. Inside PW datetime fields are not aware of the language. It would actually be desirable to have a field for setting locales in Processwire for each language or an option to set the locale in datetimefields settings. You maybe want to start a topic in the wishlist and roadmap section to point out Ryan.

The module uses php function date() and NOT strftime(). To get what you expect use the following format string: 'date(M-d-Y)'.

I would say yes since php_sapi_name() will return 'cgi' or 'cgi-fcgi' even if cgi is called from the command line. Some other remarks: The content of $_SERVER differs depending on the call of php-cgi (server or command line) If register_argc_argv is disabled (php.ini) $_SERVER[argc] is not set. Could be checked with ini_get('register_argc_arg'); As far I can see the setting of $config->cli has not an effect inside PW.

... but not in admin template.

The code I have posted is taken from a frontend login template. The frontend has a complete suite of register, login and logout templates. I use core processes in the frontend. To prevent redirects to the backend in case of successfull login/ logout or an expired session I set login and logout URLs before I execute the Process. The customers are PW users with very limited permissions. I gave the admin area a very strange name (default: processwire) like '6gt0klw5a14' to hide it from guests or frontend users. You can additionally protect the login with a custom cookie or IP filter in your .htaccess file. Calling any target in the admin area without a valid session will cause render of the Login page instead. Its not recommended to change this.

To change settings for all fields via API you could use: /** * make all fields accessible to view only for all roles except superuser * */ foreach ($fields as $field) { if ($field->hasFlag(8) && $field->name !== 'title') continue; // skip system fields `Field::flagSystem` $field->addFlag(160); // Add flags `Field::flagAccess` = 32 + `Field::flagAccessEditor` = 128 // Applicable only if the `Field::flagAccess` is set to this field's flags. $field->editRoles = array(); // leave empty if you want to give access to superuser only $field->viewRoles = array(1026); // assign field view permission to specific roles (IDs) // save the field $field->save(); }

@Slav Welcome to the forum. Take this as a first approach $homeUrl = $pages->get(1)->url; // Prevent redirect to admin login. Redirect to homepage instead if (!$user->isLoggedin() && isset($input->get->login)) $session->redirect($homeUrl); if ($user->isLoggedin() && isset($input->get->login)) $session->redirect($customLoginUrl); // set custom login/ logout urls $login = $modules->get('ProcessLogin'); $login->setLoginURL($customLoginUrl); $login->setLogoutURL($homeUrl);

No. You need the simplexml module. PW doesn't check if simplexml extension is available during its install. I would post an issue about that: https://github.com/processwire/processwire-issues

The good thing: In PW you have full flexibility handling languages. You can create any name or title. As @Zeka mentioned you can also add any custom fields (2 letter iso codes, numeric iso codes, language descriptions, flag-icons, landscape images, currency etc.) The bad thing: You have to do some things by yourself. Keep in mind that the naming of your homepage is also related to language settings. For better handling I recommend consistence (equality) between this and the language name (or any custom language field like 2 letter language code)

I pushed a revision 1.0.2 of the module with extended capability and more delimited from core functions (still using them if possible).

/** * @param HookEvent $event * */ public function hookFunction(HookEvent $event) { $event->removeHook(Wire $object, $hookID); // ... } not tested.

function pageRenderHookMethod (HookEvent $event) { $default = $event->return; if ('my condition' == true) { $event->return = 'my custom return value'; } else { $event->return = $default; } } If you hook after you don't need $event->replace = true;

You need to set the page name for the homepage specific to the language.

First of all, a persistent login is always a balance between user-friendliness and security aspects. There are two related $config settings. /** * Use session fingerprint? * * Should login sessions be tied to IP and user agent? * IP fingerprinting may be problematic on dynamic IPs. * Below are the possible values: * * 0 or false: Fingerprint off * 1 or true: Fingerprint on with default/recommended setting (currently 10). * 2: Fingerprint only the remote IP * 4: Fingerprint only the forwarded/client IP (can be spoofed) * 8: Fingerprint only the useragent * 10: Fingerprint the remote IP and useragent (default) * 12: Fingerprint the forwarded/client IP and useragent * 14: Fingerprint the remote IP, forwarded/client IP and useragent (all). * * @var int * */ $config->sessionFingerprint = 1; /** * Session expiration seconds * * How many seconds of inactivity before session expires * * @var int * */ $config->sessionExpireSeconds = 86400; The easiest way would be to force a log out, if ProcessProfile or ProcessPageEdit is requested and show the default login screen. You could compare the current user-agent, IP or duration of the session with current session data. This can be different from default (more lazy) $config settings.

@adrian Its only the extensions. maxFiles and outputFormat is set to 0 ((int) NULL) by default. @hellomoto No need to set inputfieldClass. The following is enough to get it work. $f = new Field; $f->name = 'myfield'; $f->type = 'FieldtypeImage'; $f->extensions = 'gif jpg jpeg png'; $f->save();

Module programming is great. Maybe I am missing something but currently I cannot see the benefit of your module. Example: Field creation with built-in API $f = new Field; $f->name = 'field_label'; $f->type = 'FieldtypeWhatever'; $f->tags = 'tag1 tag2'; $f->label = 'Field Label'; $f->columnWidth = 50; $f->save(); Field creation with your module $IS = new ImportShorthand(); $IS->newField([[ 'name' => 'field_label', 'type' => wire('modules')->get('FieldtypeWhatever'), 'tags' => 'tag1 tag2', 'label' => 'Field Label', 'columnWidth' => 50, ],[ // additional field options go here ]]);

Where and how did you define $addPage ? Try var_dump(gettype($addPage)); // 'object' var_dump(get_class($addPage)); // 'ProcessWire\Page'

<img src='{$story->imagefieldname->url}' alt='{$story->imagefieldname->description}' /> // single image field <img src='{$story->imagefieldname->first()->url}' alt='{$story->imagefieldname->first()->description}' /> // multiple images selecting the first https://processwire.com/api/ref/pageimages/ https://processwire.com/api/ref/pageimage/

I completely agree. I don't mind about the absolute sort value, but the page index should be in the right place. In my example it is enough if the page with previous sort value 7 get the index 2, which is the fact if a sort value of 12 is assigned (one more than 11) For handling pages the absolute sort value is not of interest it does say nothing, the index position is the important value. So it would be nice in addition to get the index via $page->index having a setting method. Of course I will do that. https://github.com/processwire/processwire-issues/issues/225

@LostKobrakai I took a look in the core sorting functions. Unfortunately it doesn't work as expected and the $pages API reference is faulty and should be updated: // set $page to have sort=5, moving any 5+ sort pages ahead $pages->sort($page, 5); // works as expected // same as above using alternate syntax $page->sort = 5; // WILL NOT moving any 5+ sort pages ahead it just changes the sort value. Duplicates possible $pages->sort($page); // WILL NOT set anything. This is a getter not a setter. Similar to $page->sort In the $page API reference, $page->sort is described as follow which is faulty too. Use $page->index instead to get expected/ described result. But you cannot use $page->index as a setter! Currently the only (nearly) working solution needs the following 2 steps $pages->sort($page->parent, true); // re-build sort values for children of $page, removing duplicates and gaps $pages->sort($page, 5); // sort +=1 for all pages above In this example you will get an unexpected result If the sort position related to the siblings was 4 before. There will be no change, because there is a gap at sort position 4 now. What I would expect using this function If I set sort I would expect a zero based position related to the page siblings. Example $pages->sort($page, 2); 3 page siblings having the sort values 4, 7, and 11. If I assign a sort value 2 to the page with the former sort value 7 I would expect the page moves to the end (last index number under 3 siblings), but currently it moves in the opposit direction and will be the first one related to its 2 siblings. Nice to have in the future (already available via PageMove module) // move page to the first or last position related to its siblings $page->moveFirst; $page->moveLast; $page->moveFirst($newParent = null); $page->moveLast($newParent = null); // move the page to an index position relative to its siblings, optionally change the parent too in one step $page->move($parent, $newIndex = null, $selector = 'all') // or simply $page->setIndex($newIndex, $selector = 'all'); Expecting a core update related to this I will not push the module to the modules directory. Feel free to pull it from github directly until this is available from core.

Of course I missed them. Thanks for the hint.