Jump to content

Leaderboard

Popular Content

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

  1. @Ivan Gretsky GitHub is a requirement for modules that are automated with regard to automatically pulling version and readme, etc. If someone needs a case where the module can't be managed at GitHub (like a commercial module or other specific case) then I would just ask them to contact me so I can add it manually. I feel it's safest for our users by having downloadable modules provided by GitHub. They have security measures in place that give me a lot more peace of mind than a link to a random ZIP file off on some site none of us know. Without GitHub as a middle man, I think there's a much higher probability of getting something questionable in a ZIP file, whether it's because of a hacked site or any number of other reasons. GitHub also provides great security options for protecting individual accounts, which I think further increases the safety for consumers of ProcessWire modules. The other side of it is that GitHub provides an API that we can read data from in order to ensure our module information is up-to-date and that users don't have to manage that information in more than one place. That API also includes a function to safely convert GitHub-flavored markdown to HTML, which is very useful for the modules directory. Presumably it would be possible to also implement this for other providers (GitLab was mentioned), so if there's significant demand for it then it would be worthwhile. But it took me a long time to implement the GitHub integration as it is, and at present I likely couldn't afford the time investment to implement another different API right now. Down the road I'm open to adding support for more Git providers. For now though I had to work within the bandwidth I could afford to devote to this project. @Mikie The module class name is used throughout, but it's true it doesn't literally say "class name:" anywhere. I think you are right it would help with clarity if it does that somewhere, so I'll plan to add it. As for version compatibility, I'm going through all of the PW 2.x modules and deleting any that aren't 3.x compatible and don't look like they will be. This will take me a little while, but basically the intention with the directory is that you can assume it's 3.x compatible. For more fine grained detail on version compatibility, it's going to read the module info array. It doesn't report that info at present, but this project isn't fully finished yet so it will be reporting more from the module info array in the coming weeks.
    2 points
  2. This is a Leaflet version of Ryans Google Maps marker module. @Github
    1 point
  3. Just to update everyone: in case you missed it, we intend to release this as a commercial module sometime this coming week, testing feedback permitting.
    1 point
  4. @netcarver, any news on your solution?
    1 point
  5. While I kind of share your opinion on the vendor lock-in thing, I don't think this is going to be a big deal — as Ryan pointed out the vast majority already use GitHub, even though some popular modules are currently on GitLab. Looking at this from Ryan's point of view it's likely less work to develop (and maintain) features when you're using a single API rather than multiple... and if that helps Ryan keep things up and running, I think it's a good approach. Also personally every time I want to report an issue or send a pull request (or merge request in GitLab) it's a bit of a nuisance if the module is not hosted on GitHub. What I'm trying to say here is that since GitHub is the most popular option by far, as well as the platform we're using for core development, hosting third party modules there makes collaboration easier ? Regarding "own git" or "custom download URL" it's good to keep in mind that a lot of the data can be pulled automatically via GitHub API, and this would defeat that purpose. Custom download URL would also be potential risks in terms of security — public git repository, and preferably one with a GUI, is a must-have for this exact reason.
    1 point
  6. Thank you @Robin S! I made these changes based on your reply and now it works: // Adding values from: $addonSelect.children('[value="' + valueToSelect + '"]').attr('selected', true).end().change(); // to: $addonSelect.children('[value="' + valueToSelect + '"]').prop('selected', true).end().change(); // Removing values from: $addonSelect.children().removeAttr('selected').end().change(); // to: $addonSelect.children().prop('selected', false).end().change(); So I switched from attr() to prop(). Lesson learned: do not use attr(), use prop().
    1 point
  7. @houseofdeadleg Gebeer was on the right track when he posted the above. The error is due to the use of single quotes - I ran across it as part of the work I posted about above. If you still want to try the approach gebeer introduced then give this a shot... $options = array(); $safe_title = str_replace("'", "\'", $page->title); $safe_title = str_replace("\n", "<br />", $safe_title); $safe_body = str_replace("'", "\\'", $page->body); $safe_body = str_replace("\n", "<br />", $safe_body); $options["markerPopupContent"] = "<b><a href=\"{$page->url}\">$safe_title</a></b>$safe_body"; // ... more options $map = $modules->get('MarkupLeafletMap'); echo $map->render($items, 'map', $options); We have to make sure that no un-escaped single quotes appear in anything we generate that gets inserted via the JS on the page. That also means we have to use escaped double quotes around the link's href attribute. We also have to prevent newline characters getting through that are part of any field - I do that as shown above rather than use the nl2br() method as nl2br prefixes all newlines with <br/> but does not remove the newlines. Hope that helps! Edited to add: Forgot to say, with the new version of the module you can just do this... <?php $map = $modules->get('MarkupLeafletMap'); $options = array( 'popupFormatter' => function($page) { return $page->body; } ); echo $map->render($items, 'your-marker-field-name', $options); ?> That will append the page body content to the popup window. It also takes care of escaping single quotes and converting newlines into HTML breaks.
    1 point
  8. @Mats @gebeer Thanks to a job I just finished for @dab I have been actively taking your work forward. I have a fork of the project here that... Simplifies getting the needed files used by MarkupLeafletMap into a template's header Integrates the Leaflet.AwesomeMarkers project and the latest FontAwesome icons into the module Adds a callback function for customising the content's of a marker's popup box Adds a callback function for customising the visual appearance of any marker Updates the readme file significantly Provides an example template file to help get folks underway with this module in their projects I based my work on gebeer's extension of your repo Mats, so I have issued a pull request to gebeer - but I'd like to get these changes into your repo if possible as then we can revert to your repo as the master codebase and, hopefully, have the latest goodies straight from the PW module directory. It's now very easy to add fields to the marker pages that let you customise their appearance. Below I have added an Options field, a FieldtypeFontIconPicker and a Text field to control the marker visuals via the added callback. If anyone want's to try it out, here is the link to the zip file.
    1 point
×
×
  • Create New...