Robin S

  • Content count

  • Joined

  • Last visited

  • Days Won


Robin S last won the day on May 23

Robin S had the most liked content!

Community Reputation

2,040 Excellent

1 Follower

About Robin S

  • Rank
    Hero Member

Profile Information

  • Gender
  • Location
    New Zealand
  1. Hi @cosmicsafari, This has been answered here:
  2. Hi @kongondo, I've been getting to know this module and it's really impressive the features you've worked in and all the settings that can be customised. Just wondering about the behaviour of the MM inputfield though - currently it reloads the whole of Page Edit with each addition to the field, which is not so good if the user has made some edits to other fields but not yet saved the page. They are faced with the option of accepting the reload which would lose the other field edits, or cancelling the reload in which case their media selection is not added. Maybe you could look at how the PageTable inputfield reloads itself via AJAX when a change is made, and do something similar with the MM inputfield?
  3. I'm puzzled by the idea that the thumbnail part of the selector could change your sort order - by using thumbnail!='' we are saying that we don't want any pages that don't have a thumbnail (because in that case you can't show their thumbnail in the slide). So that will exclude some pages if there are any without a thumbnail, but it shouldn't change the sort order of the pages that are matched. If you are using my example that uses chunk() then remove this: // ditch the last group if it has less than the number of images per slide (assuming that's what you want) if( count(end($albums_chunked)) < $images_per_slide ) array_pop($albums_chunked); Or if you are using my second example then change the for() line to: for($n = 0; $n < $albums->count(); $n += $images_per_slide) {
  4. @Juergen, thanks for the report - should be fixed in v0.0.4
  5. The only thing affecting the order of the images is the sort within the selector. You can check the order right after you get the albums: $albums = $pages->find("parent=/work/, template=project, thumbnail!='', sort=sort"); echo $albums->each("<p>{title}</p>"); This should list the pages in the same order as they appear in the page tree. Unless you have specified automatic sort settings on the parent page or template, but I doubt you would have done that as it would prevent manually sorting the pages. If the album pages are listed in the right order but the images within each slide are not in the position you want then that is a CSS issue. Not sure what is going on there. There's nothing in the chunk() hook that should affect logging in. But you don't really need to add chunk() as a new WireArray method if it's causing you difficulties and you only need to use it for this one application - you can just do the equivalent within your template/include/function instead: $images_per_slide = 4; $albums = $pages->find("parent=/work/, template=project, thumbnail!='', sort=sort"); $albums_chunked = array(); for($n = 0; $n + $images_per_slide <= $albums->count(); $n += $images_per_slide) { $albums_chunked[] = $albums->slice($n, $images_per_slide); } // now iterate...
  6. @jploch, looks like good case to use my proposed $wirearray->chunk() for. See this post for the hook you would need to add in order to use chunk()... I'm not a fan of echoing markup within functions (nothing wrong with it, just a personal preference) so I would do this: In a new include/partial named album_list.php... <?php $images_per_slide = 4; // exclude pages with no thumbnail in the selector $albums = $pages->find("parent=/work/, template=project, thumbnail!='', sort=sort"); // chunk albums into groups $albums_chunked = $albums->chunk($images_per_slide); // ditch the last group if it has less than the number of images per slide (assuming that's what you want) if( count(end($albums_chunked)) < $images_per_slide ) array_pop($albums_chunked); ?> <?php foreach($albums_chunked as $key => $slide): ?> <div class="slide" id="slide<?= $key + 1 ?>"> <div class="grid"> <?php foreach($slide as $album): ?> <a href="<?= $album->url ?>" <?= $album->thumbnail->bgset('half', 'lazyload item size1of2', array('quality' => 70)) ?>> <img src="/site/templates/img/plus-icon.svg" class="info-button"> <div class="item-info"> <div class="info-container-center"> <h3><?= $album->thumbnail->tags ?></h3> <h2>Für <?= $album->title ?></h2> <p><?= $album->thumbnail->description ?></p> </div> </div> </a> <?php endforeach; ?> </div> </div> <?php endforeach; ?> Then wherever you want to output the slides... include $_SERVER['DOCUMENT_ROOT'] . '/site/templates/partials/album_list.php'; Or if you prefer... echo $files->render('partials/album_list');
  7. Depends how many roles you have, whether any of those non-superuser roles need admin access, whether you will be adding new roles in the future, etc. But in general if a role has no permission to edit pages then you could say they have no business accessing the admin, and that way you don't have to maintain some list of authorised/non-authorised roles.
  8. If the role doesn't have page-edit permission and doesn't have profile-edit permission then they cannot see the page list or edit their profile. They just see this: But to prevent them from seeing the admin interface at all you can add this at the top of /site/templates/admin.php... if($user->isLoggedin() && !$user->hasPermission('page-edit')) { // Uncomment whichever you prefer // $session->redirect('/'); // throw new Wire404Exception(); }
  9. Are you talking about inputfield dependencies? From the docs...
  10. Module

    Installing via "Add module from URL" is nearly as easy: But I agree it would be great to have this module in the directory.
  11. To my way of thinking, numeric IDs are the worst case in terms of being editor friendly. I see HannaCodeDialog as being a kind of progressive enhancement of Hanna Code, such that in the future you could uninstall HannaCodeDialog and still have tags that an editor can understand and use. But with numeric IDs you'll have tags along the lines of... [[my_tag file="34784" options="4745|9748|8985"]] And that seems contrary to the whole idea of Hanna Code, which is about giving editors easy to understand options while you the developer do the heavy lifting (be it matching editor-friendly names to IDs or whatever) behind the scenes in the tag code. Having said that, I'd like the module to be flexible and let devs decide for themselves how they want to use it. So happy to announce... HannaCodeDialog v0.1.2 Inserting a tag from the dropdown no longer opens the dialog if the tag has no editable options. A new method prepareOptions() can be hooked in order to define or manipulate the options that can be selected for a tag attribute. See the module readme for more. @LMD, you can hook this new method to set separate value and label as per your proposal: $wire->addHookAfter('HannaCodeDialog::prepareOptions', function($event) { $options = $event->return; $new_options = array(); foreach($options as $option) { if(strpos($option, '@@') !== false) { list($value, $label) = explode('@@', $option); $new_options[$value] = $label; } else { $new_options[$option] = $option; } } $event->return = $new_options; });
  12. No, I mean cookies. I've experienced endless redirect issues when PW gets confused about my logged in status, perhaps due to the change of cookie name from "wire_challenge" to "wires_challenge" when accessing PW via the HTTPS protocol. Deleting the existing session cookies and logging in again solves the issue. The browser cache has no impact on your logged in status.
  13. I agree this would be an improvement and will add it in the next release. I'm not opposed to adding this as such but I want to be sure that it's the best way forward. Besides making the module usage that bit more complicated, the issue to me is that the tag as it appears in the CKEditor window is readable text - a site editor can look at the tag and it makes some sense. If you display a different string of text in the dialog inputfield than what is inserted into the tag then I think this could be confusing for site editors. You are saying you have some options where there is a human-friendly label and a not-so-friendly value that you actually need for use inside the tag's code. Wouldn't it be better to only ever show the human-friendly label in the tag and dialog, and then match the label to the needed value inside your Hanna code? So if you, the developer, know that "file123-xyz.pdf" is aka "Annual Accounts 2016" then in your Hanna tag code you have something like: if($file == 'Annual Accounts 2016') $file = 'file123-xyz.pdf'; Of course you could use switch() for multiple cases, or look up filenames from the descriptions, or match the label to value in whatever way you would have done when assigning "value@@label" under your proposal. Does that make sense? Any other users have an opinion on this?
  14. These redirects can be made by uncommenting two portions of the PW .htaccess file: One Two If you're seeing this when trying to access the PW admin then it could be due to old browser cookies - try clearing the cookies for your domain.
  15. IMO having comprehensive documentation is something that can only add value to the Pro modules, and takes nothing away from them. I get that many users will only interact with the modules via the admin interface and would have no desire to browse through all the methods - they can ignore that documentation entirely. But it's nice to have thorough documentation for those who do have a need for it. I'm not proposing that you necessarily spend a lot of time writing up documentation beyond what's already present in the source. The tools already exist to extract and format those phpdoc comments as online documentation as it powers the current API reference docs. And the API Explorer module can do this for modules already. The reason I prefer online docs to the API Explorer is that it's so useful to harness the power of Google to find what you're looking for. It's quicker and more powerful to open a new browser tab and do a search from the address bar (I have a keyword shortcut for "") than navigating through the API Explorer interface. And of course not everyone has API Explorer. Could the Pro modules be stored in private GitHub repos and indexed the same way as the API reference? Maybe this module from @justb3a could be useful for the authorisation?