kixe

I use this 5 lines of code, placed in an access controlled folder under root, to run a cronjob at fixed time. Just set 'cycle' in module settings to 'none' to prevent database backups triggered by LazyCron as well. <?php namespace ProcessWire; $root = dirname(__DIR__); include_once("$root/index.php"); $cdb = $modules->CronjobDatabaseBackup; $cdb->cronBackup(); Thanks for the input. I thought about it. In the end, I'll leave it as it is, and the inclusion of manually created dumps in the cleaning routine remains the standard. When I manually create a dump, I usually move or download it immediately. I rarely (never?) leave it on the live server and I want the files removed automatically. The default name created by ProcessDatabaseBackups is the database name. Just use this as the 'stopword' and use a different name format in the setup of CronjobDatabaseBackup and voila it works exactly as you want it. Furthermore there is also the option to save the files in a user-defined directory. Manually created dumps are then never affected by the CDB's cleaning routine.

This should have been already implemented with the option to set a custom storage path. Unfortunately I recognized a bug while looking in this. This bug is fixed now and I made some additional changements. Please update to v1.2.3. The automated cleanup effects only the custom path and not site/assets/backups/database/ used by ProcessDatabaseBackups. Currently you cannot use ProcessDatabaseBackups to edit backups stored under a custom path. I added functionality to protect files by 'stopword'. Files having this in its names or descriptions will be protected from beeing deleted by the cronjob. Just set the 'stopword' in the module config. @bernhard @horst @Robin S I hope the fix helps and feeds your needs (?)

Example with a multidimensional array. RepeaterMatrix fieldname = 'fieldname' first level: page where the repeater field lives in, indexed by ID second level: per page repeater items indexed by ID third level: field inside repeater indexed by name $rp = $pages->find('fieldname.count>0'); $return = []; foreach ($rp as $p) { $return[$p->id] = []; // RepeaterMatrixPageArray foreach ($p->fieldname as $item) { if ($item->type != 'basic') continue; $return[$p->id][$item->id] = []; // RepeaterMatrixPage foreach ($item->template->fields as $repeaterField) { if ($repeaterField == 'repeater_matrix_type') continue; // we do not need this if ($item->$repeaterField === '') continue; // if you want to ignore empty strings $return[$p->id][$item->id]["$repeaterField"] = $item->$repeaterField; } // remove if empty if (empty($return[$p->id][$item->id])) unset($return[$p->id][$item->id]); } // remove if empty if (empty($return[$p->id])) unset($return[$p->id]); } var_dump($return);

Please check access settings in the related page template and parent page template.

Sorry for not looking in here. I replaced the code as recommended by @Robin S without further testing and hope it works well now. I didn't use the module by myself for a long time. Stay healthy!

This bug is fixed now. Current module version 1.1.4

@Robin S@Macrura@d'Hinnisdaël Interesting discussion. I suggest continuing this outside of this thread as it is not directly module-relevant. For my part, I did a useful update because the script doesn't have to be autoloaded everywhere.

@Macrura Thanks for reporting. I fixed the issue. The JS is required only for the module settings UI. It is now only loaded there.

ProcessWire / Fullcalendar solution including comfortable planning app in the backend: https://vdt-icsa.de/program/ https://2018.tonmeistertagung.com/en/program/

Why?

Do not use FieldtypeInteger for Phonenumbers, because the Mysql Datatype is INT and therefore the value is limited to 4 bytes strings (32bit). You can use FieldtypeInteger only for numbers within the range from -2147483647 to 2147483647. Use builtin FieldtypeText or FieldtypePhone (3d Party Module) for Phonenumbers. The value of FieldtypePhone must be an instance of Phone (WireData derived object) otherwise it will be set to blank value. From the code: /** * If value not of instance Phone return empty instance */

The guest user language will be provided by default. You can change it. If you want to control it via get parameter you need to hook in ProcessLogin::execute(); Pick up the language ID from the url get parameter and set the user language in a hookBefore.

As far I can see it is possible to change it in the DB. After a quick research I couldn't find any place where this would cause problems (maybe in 3d party modules?). But still I wouldn't do that. If you just want the value for the label, why not taking it from the homepage name, representing the language in the url. foreach ($languages as $l) echo $pages->get(1)->localName($l);

For the sake of completeness. Hooks in ProcessPageView are also possible if the hook is placed in the /site/init.php file. Example: // pick up $_GET['it'] (requested uri) before unset wire()->addHookBefore('ProcessPageView::execute', function($e) { var_dump($_GET['it']); });

I don't think this is a PW issue. I am playing around a bit with this behaviour. The problem is, browsers does not handle this consistent and there does not exist a proper status header. Something like a combination of 401 and 302 (e.g. "Moved Login required") would match this situation. Browsers should never cache those redirects and search engines should handle this also without disadvantages. This does not exist. Another workaround without redirect should work with the following hook in init.php // render login for guest users trying to access a disallowed page without redirect wire()->addHookAfter('ProcessPageView::ready', function($e) { if ($this->wire('user')->isSuperuser() || $this->wire('user')->hasRole('client')) return; $pid = $this->wire('page')->id; $disallowedPageIDs = array(1582, 5584, 5342, 1133, 1607, 5374, 6075, 6605); if (in_array($pid, $disallowedPageIDs)) { $login = $this->wire('pages')->get('/login/'); $this->wire('page', $login); } });

@bernhard Thanks for pointing on this. I fixed this bug. Please update to 1.2.0

I came across this post because I had this redirect problem in a production environment. I could reproduce this in Firefox. The problem also occurs in IE. I have a template that can only be viewed by users with a specific role. Based on the template settings, an unregistered user or a user who does not have the required role will be redirected to a different URL (301). This is done by ProcessPageView::execute(). If the user tried to access the page before logging in and therefore has been redirected once, the redirect will also be performed when the user is logged in later because the browser has cached the redirect. Possible solutions: Add a unique GET parameter (such as a timestamp) to the URL in the link. Trigger the redirect via API in the template file: $session->redirect('/targeturl/', false); // 302 Paste this hook into your init.php wire()->addHookBefore('Session::redirect', function($e) { $url = $e->arguments[0]; if ($url == '/login/') $e->arguments(1, false); // change to 302 if target is /login/ });

@Stefanowitsch Please post a code snippet and your ProcessWire version, otherwise it is difficult to reproduce the error.

Password is stored as a hash in the database. You cannot read it out. To set a new superuser (admin) password, put the following code in a template, or in your ready.php $users->get($config->superUserPageID)->setAndSave('pass', 'mynewpassword'); Don't forget to remove the code later.

Everything fixed. Current module version 1.1.3

Yes, the permission will be created on install only.

@horst Sorry for the very delayed answer. The module (FieldtypeSelectExtOption) is a fieldtype, not an inputfield. The fieldtype supports any Core Inputfieldtypes (Select, Radios, Checkboxes, SelectMultiple or ASMSelect) furthermore some 3d Party Inputfields like InputfieldChosenSelect. Read more about this in the README.md. I don't know if there exists an Inputfield module which extends InputfieldSelect or InputfieldSelectMultiple showing icons or thumbnails to select from. Let me know if you find a solution.

@jploch @horst Tonight a had a look in the module and I made an update to version 1.1.6 I removed any general permission from module. The Backup is triggered now by any user (if a time interval is set). I added trigger option when a user logs in (thanks for the hint @horst). I changed the name for the required permission (trigger on login or logout) from 'db-backup' to 'trigger-db-backup'. Also to prevent permission conflicts with ProcessDatabaseBackupsusing this permission.

A customer wanted to provide own content from other sources in the admin. Videos and other stuff. Nothing special.

Keep same and cross domain iFrames sized to their content with support for window/content resizing, in page links, nesting and multiple iFrames. https://github.com/davidjbradshaw/iframe-resizer