Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/11/2020 in all areas

  1. Yeah nice resource, I've been using them for a while, I guess they rebranded a while from unsplash.it ? By the way, the pictures are from unsplash.com, so they are completely free and can even be used in final commercial products. Though they don't have many upload guards in place to prevent people uploading copyrighted material, so it's worth it to do a reverse image search just to make sure. There's also undraw.co for illustrations, which is nice because the illustrations are SVG files and you can customize the main color right on the website.
    2 points
  2. 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.
    2 points
  3. 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! :-).
    2 points
  4. There are a few problems with that code: Switching $magazine to $page doesn't actually help at all. $page is not defined here either. As I mentioned in my previous post, you're in function context, and in that context you only have access to a) function arguments ($event), b) variables you've made accessible with "use" (currently there are none), and c) global functions. $page is none of those. Another issue is that there's no savedPageOrField method for Inputfield, so Inputfield(...)::savedPageOrField is never triggered — what you're looking for is Pages::savedPageOrField. From your post I assume that you've put this code in the template file, i.e. /site/templates/your_template_name.php? If so, the hook only applies to when you're viewing a page using that template, i.e. it has no effect in Admin. I'm not sure if that's what you really intended, but I'd assume not — more likely you'd want to put this hook somewhere it gets added in the admin as well, so perhaps /site/init.php or /site/ready.php. ... and, finally, even if your code did work, you would've likely ran into an infinite loop: if you hook into page save and save the page, that'll trigger the page save hook, which will then save the page and trigger the page save hook again, which... you know the drill. Pages::saveReady() is often better method to hook, as you can just modify the page values, and they'll get saved soon after (you don't have to call save in your hook) ? In this case something along these lines could work: // hook into Pages::saveReady $wire->addHookafter('Pages::saveReady', function($event) { // get current Page object — in this case this is the first argument for the $event object $page = $event->arguments[0]; // bail out early if current Page *doesn't* have the field we're interested in if (!$page->template->hasField('snipcart_item_image')) return; // ... and also bail out early if the snipcart_item_image field hasn't changed if (!$page->isChanged('snipcart_item_image')) return; // now that we know that snipcart_item_image has changed, set a custom value to another field $page->set('imagecolorat', 'YOUR_NEW_VALUE_HERE'); // finally, populate our modified $page object back to the event $event->arguments(0, $page); }); Note: written in browser and not properly tested.
    2 points
  5. Last week I told you how I was working on a getting a new Stripe payment method working with FormBuilder… and I’m still working on it. That wasn’t exactly the plan. Stripe isn’t quite as easy to work with as it used to be, or maybe Stripe thinks I’m not as easy to work with as before. Either way, I’m learning, and it’s been a good opportunity to expand FormBuilder with its own class for plugin “action” modules. Hopefully some of this work on the Stripe side can apply for other payment methods, or any type of action you’d want to take with a form submission. It’s probably going to take another week or so before this module is ready to release in the FormBuilder board, but it’s going to be built well and accompany a new version of FormBuilder too (that supports these plugin actions by way of PW modules). Having these actions as ProcessWire modules opens up new doors for FormBuilder, and I may even move some of the built-in actions (like saving to Google Sheets) into this type of module, which would be nice for hooks and maintainability. There’s not a lot to report on the core side this week. There are a few commits and improvements, but not yet enough where I’m ready to bump the version to 3.0.168. One small but useful improvement is that handling of selector queries for words with apostrophes has been improved. One of my clients noticed they were having trouble with their site search engine matching terms like “Alpe d’Huez” and “L’estello”, and so our page finding engine has been improved to narrow them down with the fulltext engine and then find the exact matches with regular expression queries. This improvement enhances most of the partial text matching operators. It also solves the issue of there being different kinds of apostrophes (ascii straight vs utf-8 curly), among other things. Overall the core is running running very smoothly on the dev branch, so I’m thinking we may try and do another merge to master before 3.0.170. Thanks for reading and have a great weekend!
    2 points
  6. I found this random picture generator the other day but kept forgetting to post it here. It's basically lorem ipsum but for photos. They have quite a nice feature set too.
    1 point
  7. 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.
    1 point
  8. 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('/');
    1 point
  9. Same issue here. Found out anything @fliwire? Lol just gotta echo the variable that is passed by reference: $urlStr = '<p>' . $url . '</p>'; $modules->get('TextformatterVideoEmbed')->format($urlStr); echo $urlStr;
    1 point
  10. 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.
    1 point
  11. Yeah, we all struggle with that sometimes. ? I did a bit of experimenting and here's another way the language options can be removed from the title field: // Single-language title field for "test-template" at Page Add $wire->addHookAfter('ProcessPageAdd::getAllowedTemplates', function(HookEvent $event) { $tpls = $event->return; $t = $event->wire()->templates->get('test-template'); if(isset($tpls[$t->id])) $tpls[$t->id]->noLang = 1; $event->return = $tpls; }); // Single-language title field for "test-template" at Page Edit $wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) { /** @var InputfieldForm $form */ $form = $event->return; $page = $event->object->getPage(); if($page->template == 'test-template') { $title = $form->getChildByName('title'); if($title) $title->useLanguages = false; } });
    1 point
×
×
  • Create New...