kongondo

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!

Try this: https://processwire.com/api/ref/paginated-array/get-pagination-string/

@bilioso, Welcome to the forums and to ProcessWire. Before you start, please backup everything, especially the databases. Secondly, do the import on test site first, whether a local or remote site, but don't try this on the live/production site. Once you've tested things went OK, you can do the import on the live server. For backups, in ProcessWire, there are several options. The simplest I think is this module by Ryan. https://modules.processwire.com/modules/process-database-backups/. You can use it to make backups at different points in your tests. Use that to make a backup of the ProcessWire site before you changed the dates. This will allow you to always be able to go back to that point whenever you need. I am assuming this is SQL executed via ProcessWire? Template file could work. You would add the code to a template file and visit a page that uses that the template that template file belongs to. You would do that once then remove the code. However, a better approach is to use TracyDebugger's code console. You can then run the code there and comment it out or delete it once done. TracyDebugger is really useful to developers. You can get it here: https://modules.processwire.com/modules/tracy-debugger/ Let us know how it goes :-).

I understand Please do. You're welcome :-).

Seems like someone left in a Tracy debug call in there ?.

Oops. You didn't need to do that, especially if there is some sensitive info there. Just needed the PHP version :-). The error seems to suggest that this is the issue. Hmm.. Have you tried on a local site? Does it work? On the remote installs, does the reverse work? i.e., accessing contents of the 'second' site inside 'main' site.

Excellent! Glad you got it sorted. ?

Yes. This will be more versatile. Alternatively, if you were working with a known set of icons that won't change or wont' change much, you could use the separate value|title feature of FieldtypeOptions. Looks a bit hacky but you could do something like this (assuming you are using font awesome): fa-coffee|Breakfast fa-cutlery|Ristorante fa-bed|Bed fa-wifi|Wifi fa-car|Car Park fa-wheelchair| Accessibility // OR... coffee|Breakfast cutlery|Ristorante bed|Bed wifi|Wifi car|Car Park wheelchair| Accessibility You would then be able to access the icons names using $item->value. Obviously this means it is only the developer who will be able to determine and set icons (which may not be a bad thing actually). Just a thought...

I see. However, I still don't get where the icons are coming from. For instance, where have you stored your wifi icon? Where is the icon for Piscina? Etc..Unless it is a new feature I am not aware of, FieldtypeOptions doesn't store icons.

Do you have Functions API enabled? If yes to #1, if you turn off Functions API, does it work? ProcessWire version? Multilingual? Server environment (just in case)....PHP, MySQL No. It should just work.

I'm not sure if you mean a ProcessWire field icon that can be set in the Advanced Tab when editing a field? If yes: $f = $fields->get('name_of_field_with_the_icon'); $icon = $f ? $f->icon : '';

Is there a reason you are overwriting the API variable $page?

I see two potential suspects here; Windows IIS and MySQL 8. I haven't tested MM in Windows IIS. However, I think we have reached a point where it is best that I have access to a test server. This could either be a test site where you can reproduce the problem or the production site itself. I have never been able to reproduce the issue, albeit I have not tried in a Windows IIS environment. I don't have access to such an environment either, sorry. No other users have reported similar UNRESOLVED issues, so I have nothing else to go on regarding your particular case. That's not great! Please consider giving me temporary access to a site where I can debug the issue. Thanks.