kongondo

I'll see if I can get time to have a play. From what I can tell, in AdminThemeFramework::init we have this code: <?php namespace ProcessWire; $user = $this->wire('user'); if(!$user->isLoggedin() && $this->useAsLogin) $this->setCurrent(); parent::init(); That checks if the user is NOT logged in and if useAsLogin is true... $this->setCurrent() is a method in the base class, AdminTheme. Like you said, $useAsLogin is native to AdminThemeFramework. However, AdminThemeFramework only uses it internally to see if to use setCurrent(). In AdminTheme::init, it will first check if there is a user specified theme and if that matches the current admin theme. If true, it will use setCurrent() to set it as the current theme. Else, it will fall back to what is specified in $config->defaultAdminTheme, if a value exists there. <?php namespace ProcessWire; if($adminTheme) { // there is user specified admin theme // check if this is the one that should be used if($adminTheme == $this->className()) $this->setCurrent(); } else if($this->wire('config')->defaultAdminTheme == $this->className()) { // there is no user specified admin theme, so use this one $this->setCurrent(); } I am guessing that in the init() method of your custom AdminTheme, you can use the above logic (first code) similar to what is in AdminThemeFrameWork::init (the bit about user not logged in....). Sorry if this doesn't make sense; Written in a hurry...

Follow the rabbit from here: wire/core/AdminThemeFramework.php /** * AdminTheme Framework * * The methods in this class may eventually be merged to AdminTheme.php, * but are isolated to this class during development. * * @property bool $isSuperuser * @property bool $isEditor * @property bool $isLoggedIn * @property bool|string $isModal * @property bool|int $useAsLogin <------- this one? * @method array getUserNavArray() * */ $useAsLogin maybe?

No worries :-).

This line is the problem. It is messing up the selector string (see screenshot below). $sanitizer->entities is for entity encoding a string for output ( i.e. output to your page). What we want here is for input, hence $sanitizer->selectorValue should be enough. Remove the entities sanitizer (or use $sanitizer->text in its place to remove HTML) and you should get same results: sanitized selector results

Haven't done it myself, but I guess it should be possible. Have a look at AdminThemeUikit settings when editing it in Admin / Module /. You see this: That shows it should be possible.

@vmo, Was there question you wanted to ask?

Yes, it should. As long as you tell the JS what criteria to use to filter things. I don't know if you are using vanilla JS or some library but the principle is the same. You will filter out/in items to either remove/hide OR add/display depending on whether you filtered out or in. This is how we do it in Menu Builder, giving us flexibility to create all sorts of menus. If you have more questions specific to your use case (including the JS), please open a new thread so that we stay on topic in this thread. Thanks.

What's your use case? Deeply nested arrays can get unwieldy and depending on how big they are, consume a lot of memory. I find it simpler to work with flat(ter) arrays with in-built relationships between the members. I then run that through a recursive function. Something like this: <?php namespace ProcessWire; $menu = array( 1 => array( 'id' => 1023, 'title' => 'Menu item 1', 'parent' => null, // this menu item does not have a parent/top level ), 2 => array( 'id' => 1024, 'title' => 'Menu item 2', 'parent' => null, ), 3 => array( 'id' => 3000, 'title' => 'Child 1 of Menu item 2', 'parent' => 1024, // its parent is item with ID 1024 ), 4 => array( 'id' => 3001, 'title' => 'Child 2 of Menu item 2', 'parent' => 1024, ), 5 => array( 'id' => 3003, 'title' => 'Child 1 of Child Menu item 2', 'parent' => 3001, ), 6 => array( 'id' => 1027, 'title' => 'Menu item 4', 'parent' => null, ), 7 => array( 'id' => 3009, 'title' => 'Child 1 of Menu item 4', 'parent' => 1027, ), 8 => array( 'id' => 4001, 'title' => 'Child 1 of Child 1 of Menu item 4', 'parent' => 3009, ), 9 => array( 'id' => 4002, 'title' => 'Child 2 of Child 1 of Menu item 4', 'parent' => 3009, ), );

Glad you got it sorted :-). Those are nice improvements you added there.

Here's the updated code with the above robustness baked in. In your template file with 'forget me form': <?php namespace ProcessWire; if ($input->post->forgetme) { if ($user->isSuperuser()) { echo 'You should not be here...'; $session->redirect('/'); } $items = $pages->find('template!=user,name=' . $user->name); if ($items->count) { // save items to delete to cache using unique cache names // cache the value, and expire after 10 minutes (600 seconds) $cache->save("forgetmepages-{$user->id}", $items, 600); $cache->save("forgetmeuser-{$user->id}", $user, 600); $session->redirect("/confirm-delete/"); } } In the 'delete confirmed' template file: <?php namespace ProcessWire; // get the uniquely-named caches $forgetmePages = $cache->get("forgetmepages-{$user->id}"); $forgetmeUserID = (int) $cache->get("forgetmeuser-{$user->id}"); // if we got the caches if ($forgetmePages && $forgetmeUserID) { // also check if we have the right user if ($user->id === $forgetmeUserID) { foreach ($forgetmePages as $item) { $item->delete(); // $pages->trash($item); } // delete the user $users->delete($user); // log them out $session->logout(); } } // get me outta here $session->redirect('/'); Hope this helps.

Btw, the code I supplied is not robust enough to cover a scenario of simultaneous forget mes! It uses the same cache name and will at best lead to a race condition or at worst, miss deleting pages since these would have been replaced in the cache. One way to overcome this is to create a cache with a unique name, e.g. 'forgetmepages-1234' where 1234 is the ID of the logged in user we want to 'forget'. We would the retrieve the cache as $cache->get("forgetmepages-{$user->id}"); We will need to check that the cache exists before doing the foreach(){delete). Secondly, and this is now probably covered in the above, it is best to check that we have a user ID at $cache->get("forgetmeuser->$user->id"); and that the (int) value of that matches the $user->id before we delete the user and his/her pages. I hope this makes sense.

Yes, please let me know. I did a number of tests and it worked for me. Speaking of which, I better get to mine as well! :-).

Stuff like is the page locked; is it a system page (e.g. repeater pages) is it currently being viewed (see below), it has children and you haven't told ProcessWire to do a recursive delete..etc Since 2019-04-04 you cannot delete the page currently being viewed: See these lines in wire/core/PagesEditor.php. This is because wire/core/PagesTrash.php itself checks PagesEditor::isDeleteable which in this case has returned the info that the page cannot be deleted. Here's one way to do it: You will need two templates. One for the 'forget me form' and another that will carry out the deletion, the logout, the redirect and, if needed, give confirmation/feedback to user. In your template file with 'forget me form': We do our checks for the post and check that user is not superuser. We then try to find pages for that user. If we find pages, we cache the PageArray. We also cache the user. ProcessWire will cache this as the user ID. We redirect to the delete page <?php namespace ProcessWire; if ($input->post->forgetme) { if ($user->isSuperuser()) { echo 'You should not be here...'; $session->redirect('/'); } // @note: we need to tell ProcessWire we are only searching for pages at this point and not users as well! // Otherwise we'll get an error when caching, about mixing multiple types in the cache // as otherwise this selector will also find the user with that name along with the user pages $items = $pages->find('template!=user,name=' . $user->name); // we found items if ($items->count) { // save items to delete to cache // cache the pages to delete and the user to delete // and expire after 10 minutes (600 seconds) $cache->save("forgetmepages", $items, 600); $cache->save("forgetmeuser", $user, 600); // redirect to the page that will carry out the cleanup $session->redirect("/confirm-delete/"); } } In the 'delete confirmed' template file: Here, we no longer have access to the $input->post->forgetme Retrieve the caches with the items to delete and the ID of the user to delete that we saved above The items cache is already a PageArray, so we just loop through it and delete the pages We get the user to delete using their ID, just to be safe Delete the user Log them out Redirect to home page <?php namespace ProcessWire; $forgetmePages = $cache->get('forgetmepages'); $forgetmeUserID = $cache->get('forgetmeuser'); $forgetmeUser = $users->get($forgetmeUserID); foreach ($forgetmePages as $item) { $item->delete(); // OR // $pages->delete($item); // $pages->trash($item);// if you want to trash the pages instead } $users->delete($forgetmeUser); $session->logout(); $session->redirect('/');

You can do it manually by either of the following ways: Selectors: $pages->find("$your_selector"); foreach(){} -> and capture in values in an $array which you can then echo json_encode($array); OR Selectors: $pageArray = $pages->find("$your_selector"); ->then use $array = $pageArray->explode(['title','body']) -> then echo json_encode($array); OR Use ProcessWire's (not installed by default) ProcessPagesExportImport module, select the pages you want and optionally the fields you want and export to JSON. Note, it will add other information not necessary for translation, e.g. Page IDs and templates. #2 is probably easiest and cleanest. Edit: #3 will allow you to import/update after translations are done.

Here's another... I am not sure if in your case the slowness is due to the query itself or the page objects that have to be created after the find. If the latter, you can tell ProcessWire not to return page objects. You can then work with arrays as it seems your main interest are not the items themselves but their IDs and the quantities. Just a quick thought..

Nice one Robin! Much cleaner than what I proposed. At Page Add, it responds to template change but not so at Page Edit.

Yes you are right Robin and you raise some good points. Now that I read this... I see that I probably misunderstood the OP question. Good point. I am wondering though, couldn't the converse also apply in this case? i.e. aka, don't show an input that the user does not need to fill ?. Anecdotes I've heard from developers who work on multi-language sites is that if they can, they often resort to hiding what the user doesn't need to fill, as in spite of the education, their users still get confused by/forget/ignore...etc the instructions.

Here's how I managed to do this by hook or crook ?. Summary Hooks alone are not enough We still need to be able to switch templates and view/enable languages if those templates support languages We need to be able to do this both during page creation and post-creation We need CSS, JavaScript and Hooks We use hooks to: (a) deactivate non-default languages (b) to pass an array of template IDs that we designate as mono-lingual We use CSS to hide unrequired language tabs, inputs and labels We use JavaScript to add/remove 'hide' classes as needed We need to load the CSS and JavaScript in the admin. There are various ways to do this. I've simply added them via templates/admin.php You'll notice some brief FOUC, but they are not major and can probably be sorted out using CSS and JavaScript. I've left in some example code in the CSS (see below) Code CSS JavaScript PHP /site/templates/admin.php /site/ready.php Other approaches, anyone? Demo

Found a solution :-). Will post here tomorrow.

Note to self: Like I said, I really need to get more sleep! Although all fields in ProcessWire are custom fields, the Title field is somewhat special and I suppose that's why ProcessWire treats it so. Let me have a think...

Of course you are! Sorry about that. I need to get more sleep ?. OK, back to the issue. You might have noticed this yourself. It seems ProcessWire does not allow you to create two title fields. At least that's what I am seeing here, i.e. I cannot create a new field and make it to be of type Page Title. I haven't seen a setting to change that. However, we can change the type of an existing title field from Page Title Multi-language to Page Title. But that's not what we want. Hmm, let's try something else. We can trick ProcessWire by duplicating the current title field! OK, progress...until you look at the type for the cloned Page Title field. In my case, I am testing in a multilingual site and in the clone, for type choices, we now only get Page Title Multi-Language!We cannot change the type to Page Title! Interesting...The original title field can still have its type changed; but, you don't want to do that because you will lose the multilingual data for the pages that currently use that title field! Thoughts, anyone? We can always hook, but was just wondering... :-)

I don't know what your setup is, however, in ProcessWire you normally use URL segments in your template to handle such issues. Basically, you need to tell ProcessWire what to do in case it doesn't find a valid page at the address products/table/red. If this is what you need, please have a read here: https://processwire.com/docs/front-end/how-to-use-url-segments/

@picarica, Moderator Note This section of the forums is dedicated to module development only. Please either post your question in the dedicated Padloper support forum (you need special access. Let us know if you cannot access that forum) or post in the General Support section of the forums. For now, I have moved your question to General Support. Thanks.

No hook needed :-). Edit the template you don't want ML support for Go to Advanced Tab Scroll to the bottom Disable ML support for the template Advanced Tab Disable ML Support

Not true, actually. You can: See these lines, here and here: $str = sprintf($this->_('%1$s %2$d of %3$d'), $label, $pageNum, $totalPages); // Page quantity, i.e. Page 1 of 3 $str = sprintf($this->_('%1$s %2$d to %3$d of %4$d'), $label, $start, $end, $total); // Pagination item quantity, i.e. Items 1 to 10 of 50 Here's how to do it ? Setup -> Languages -> Your Language Find Files To Translate Look for \core\PaginatedArray.php under Translatable files in /wire/ Select #3 Click Submit Translate!