• Content count

  • Joined

  • Last visited

  • Days Won


netcarver last won the day on October 17 2016

netcarver had the most liked content!

Community Reputation

1,918 Excellent

About netcarver

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

11,492 profile views
  1. @matjazpThank you! I've also issued a couple of very minor pull requests on top of this new feature. Nevermind, I see you already pulled them. Thanks again!
  2. Thank you! I'd also like to throw in a request for the module to optionally make backups of files before overwriting. A simple copy to .<filename>.<definable extension> would be great. Best wishes, Steve
  3. @DaveP I've now initiated a pull-request for your consideration.
  4. @DaveP, I've found this useful over the past week on a client project, so a big thank-you! I think you should change the filename & classname of the module from "TextFormatterInsertDummyContent" to "TextformatterInsertDummyContent" though. At the moment, this module does not appear in the modules list grouped with all the other Textformatters but it is in its own, lonely, "Text" group. Unfortunately, this does require making a breaking change to the module, as the filename and class name (plus internal path names etc) all need to change. The upshot of which is that the module can't be simply upgraded (at least, I think not.) Anyway, I've forked your repo (here) and made some changes. I've also added code to randomise the output on each call. There is also a corporate branch that sources its 50 paragraphs from Corporate Ipsum.
  5. @matjazp Just sent in a pull request for your consideration. I was in need of an admin edit option that would allow me to specify files in the templates/styles/skin subdirectory of a site under development. I therefore added a recursive scan of the templates/ directory to the config options for the root of the editable files. I also noticed that whenever I used the module to edit one of the files (hosted on a linux server) , git would pick up every line of the file as having changed, not just the little edits that had actually been made. It seems that the post of the file through to the back end was converting all the original linux end-of-line characters into Windows end-of-lines. This makes finding and describing edits made by clients very difficult. I therefore added a config option for you to specify what line endings to use on save (Win/Mac/*nix) so the files show no eol differences and git diff shows only what was really changed. Small update to the choice of font-awesome icon too. Thanks for considering!
  6. Thanks to a pointer from Adrian, I just found this thread. Want to cross-reference this post here. There are a few possible ways of handling this and I'd like to work on the issue after I finish my current client work.
  7. This issue hit me a while back too with the RepeaterMatrix field. I ended up posting about it in the Profields support board but, embarrassingly, forgot to let you know about it at the time, jaro. My apologies to all for the oversight.
  8. @Mike Rockett That looks even better - having it as a popup would be good.
  9. If anyone's interested, I've forked Ryan's ProcessWireUpgrade module and added the ability for it to detect if github has a tagged release for the latest version of each listed module (except for the PW core repos which will require special handling). If a tagged release entry is found, it then adds an extra link to the table. This is strictly an alpha "proof-of-concept" experiment, but if you are interested my fork of the repo is here - just replace the current version of the module code with my fork and you should be OK. Providing module authors start tagging their releases on github, it will allow you to navigate to the release notes for review before you hit the upgrade link. As you can see, Mike Rockett has already started tagging his releases - and hence his module gets the extra "Release Notes" link. Worthwhile idea?
  10. It could be as simple as having an offsite link to the github release page for the version. I believe it could be auto-generated, as they all (currently) follow the same format...<user>/<project>/releases/tag/<upgrade-version> =================================== | Known to PW from the module repository? Updated to add: Yes, just trying the locally and it seems to work. Not difficult to pull the repo URL along with the other data and use it to add a "Changes" link next the new version. A little more use of WireHttp() requests to check if the links are sending back a 200 or 404 page and we'll know which items have release tags.
  11. @Mike Rockett I like the use of release and the changelog - please keep it up. In fact, I think I need to adopt this with my own modules going forward. It would be really nice if ProcessUpgrades - or the PW core - could send us to a module's release notes before we decided to update it.
  12. @Macrura Thanks for the reply. It's good to know that you are having success with the module approach - I did take a brief look at it as I like the idea, but I ended up passing it over when I realised there was no support for images out of the box. Could you perhaps issue a pull-request to the module author with your changes? They sound like a worthwhile addition.
  13. Curious to know what other people are doing for this now - especially in light of the new FunctionalFields feature.
  14. Hmm, now if only the module toolkit were installed by default
  15. I've now merged FlorianA's patch into the allow-blanks branch. Please test and let me know if it works for you.