Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/24/2021 in Posts

  1. Huh, I thought you could just do $img->sort = 1 and save the field, but doing this does indeed require a small hack as described by Ryan here: So you can totally just send a bunch of numbers and figure the new order out on the server: $newOrder = [2,4,1,3,5]; $page->of(false); for ($i = 0; $i < count($page->images); $i++) { $page->images->eq($newOrder[$i]-1)->sort = $i; // the sort property doesn’t exist on PageImage, we just introduce it so we can call sort on it below } $page->images->sort('sort'); // this is the key to the whole thing $page->save('images'); Obviously IRL you would have to validate the input etc.
    1 point
  2. What’s the bit you’re asking about specifically? A general strategy could be to markup your frontend form the same way ProcessWire does it in the admin (i.e. the names of the inputs) and let PW do the server-side work somewhat like this: $yourImageField->processInput($input->post); /* upload errors must be handled separately, but you only want * to rearrange existing images, so you’ll probably want to * reject submissions with new images somehow. */ if (count($yourImageField->getWireUpload()->getErrors())) { $errors++; $yourImageField->error('Upload failed, tough luck.'); } if (count($yourImageField->getErrors())) { $errors++; } else { // successful form submission, so populate the page with the new values. $page->set($yourImageField->name, $yourImageField->value); } if ($errors === 0) $page->save(); You’ll notice that PW uses hashes to identify individual PageImages. It keeps track of the name of the image field and the image’s hash in the name of an input element that contains the image’s sort value: <input type='number' name='sort_<?=$yourImageField->name?>_<?=$image->hash?>' other-stuff-such-as-value /> For your use case it will likely be cleaner to just have a form with one number input per image, named after the hash, and hand rolling the sever-side processing. In fact, it may be easier to identify images by file name. Not sure how PW gets from the hash to the image. Since you’re likely using JavaScript to rearrange the images anyway, you might even get rid of the input element alltogether and just build the POST parameters from the actual order in the DOM before submitting.
    1 point
  3. ITRK-Service for ProcessWire Module for the automated transfer of imprint, data protection declaration and terms and conditions from IT-Recht Kanzlei to your ProcessWire installation What is ITRK Service for ProcessWire? ITRK-Service for ProcessWire is a free module for ProcessWire CMS. It provides an interface to the update service of IT-Recht Kanzlei, via which the legal texts of your online presence are automatically updated. In this way, the texts remain legally secure and warning-proof in the long term. Imprint, data protection declaration, revocation and general terms and conditions are currently supported. You can find our documentation (in german language) here: https://www.pupit.de/itrk-service-for-processwire/dokumentation/ Download: https://www.pupit.de/itrk-service-for-processwire/ Github: https://github.com/pupit-de/pwItrkServiceConnector
    1 point
  4. Hey @hollyvalero You're almost right. All folders starting with a dot are backups which where automatic created, when you update the modules via the PW backend. So if you've tested everything carefully, there's no reason to not delete them ?
    1 point
  5. For the benefit of anyone else wanting their module to be comptible with earlier versions of PW, I suggest you use: $tab1 = $this->wire(new InputfieldWrapper()); not $tab1 = $modules->get('InputfieldWrapper'); Also, do not use plain $tab1 = new InputfieldWrapper(); as the column widths of the contained inputfields will not work properly. Per the PW coding style guide:
    1 point
  6. Quick report: wire works splendidly: <?php function myFunction() { $session = wire('session'); echo $session->future; }; ?> Thanks again, @kongondo, for the pointer!
    1 point
  7. Hi Ryan, thx for the update! Is there any reason why the label field is required? I find that really annoying - I'm leaving that blank most of the time while developing, because I see the name of the field instantly and change/fill the label only if the setup turns out to be working properly. Otherwise removing fields, renaming fields etc. is more work than necessary, because one always has to fill/rename one additional field that does not add any benefit. Would be great to revert this back to optional. I like the new interface, though. But it would be better IMHO to show name | type | label (optional) PS: I saw that the page name fills automatically based on the label - that might be nice for all english speakers, but most of the others I guess will usually have different labels and field names, because the label is in their language while the field name is english...
    1 point
  8. Here's a short snippet for site/ready.php that hooks after ProcessPageEdit::buildForm and moves a regular field (named "testfield here") from the Content tab to Settings. The methods used are from the InputfieldWrapper class. <?php wire()->addHookAfter("ProcessPageEdit::buildForm", null, "moveFieldToSettings"); function moveFieldToSettings(HookEvent $event) { $form = $event->return; $field = $form->find("name=testfield")->first(); if($field) { $settings = $form->find("id=ProcessPageEditSettings")->first(); // Alternatively, find a specific field to insert before/after: // $settings = $form->find("name=template")->first(); if($settings) { $form->remove($field); $settings->append($field); // In the alternative, insert before or after the found field: // $form->insertBefore($field, $settings); } } }
    1 point
×
×
  • Create New...