netcarver

PW-Moderators
  • Content count

    1,425
  • Joined

  • Last visited

  • Days Won

    27

netcarver last won the day on October 17 2016

netcarver had the most liked content!

Community Reputation

2,052 Excellent

About netcarver

  • Rank
    Code Monkey

Contact Methods

  • Website URL
    https://www.youtube.com/watch?v=kWrjYdD0Tg0

Profile Information

  • Gender
    Male
  • Location
    UK

Recent Profile Visitors

12,100 profile views
  1. @adrian Thanks for the feedback - I like the idea. It needs a take account of the chosen time format (that's just one of the ones on offer), but this should be possible. Will see what I can do.
  2. Hi @cosmicsafari Just look in the cache directory for a file called LazyCronLock.cache. If it is there for more than half a minute (or however long you estimate your code should run for) then delete it to unjam LazyCron. If this keeps happening, then there could be something in your hook method that is timing out and leaving the lock file there. Here's some code to return the location of the file if you want to do it programmatically... function getLazyCronLockfileName() { return wire('config')->paths->cache . "LazyCronLock.cache"; }
  3. LazyCron is driven by user visits. Are you sure the site is being visited regularly? If you need to guarantee a run, you need to setup a cron job to visit a page on your site, or simply use cron itself to drive your tasks. Another possibility is that the cron script is timing out behind the scenes and leaving the LC script jammed.
  4. Oops, I stand corrected.
  5. @owzim Great to hear from you in the forums again. I think Bernhard already opened a PR for you.
  6. What does your initial research/googling suggest? What do you want to achieve?
  7. Hi @adrian Thanks for the idea - I'll give it a try locally and see how it goes.
  8. The easy way to do this is to compare the current JSON reply to the previous one. If an entry exists in the previous JSON reply that doesn't exist in the current JSON then you know that you need to delete the corresponding entry in PW. Storage is easy - just write the JSON to disk. Compare is easy - convert the two JSON feeds to arrays and just do an array diff. Delete is easy, as long as there is a unique field in the JSON that maps through to a unique field value in PW. Once you've processed the current deletions, just store the JSON ready for the next cycle.
  9. @joshuag Early on in the thread you mentioned a work-in-progress fix for the 2800 event limit, and also about a more elegant update feature when adding exclusions. Any update on this? I've scanned the posts in the rest of the thread but might have missed it. Have these issues been addressed in the current version?
  10. Hi Simon, Please make sure that the field is not set up to do HTML Entity Encoding. To do this, edit the field for which you setup the CKEditor and go to the "Details" Tab and then remove the HTML Entity Encoder from the list of Text Formatters to be applied to that field. Just hit the little trashcan/dustbin icon at the right. This will be applied when you save the field. You should also make sure that the content type further down the page is setup for Markup/HTML. Hope that helps!
  11. Do you know if the client is using the DomainServer Basic package. The FAQ pages say that htaccess files aren't even allowed for sites hosted on that service. It might be worth emailing the support folks at the host and asking the question direct to them.
  12. Well, I still want to extend the breaking change search to apply to the text of commit messages. Currently the search is only applied to the changelog (if any.) I think extending the search for breaking changes and simply highlighting where a breaking change phrase occurs is probably enough.
  13. @horst There's a pull request on your module that should update the formatting of the Changelog to allow it to be parsed by the existing code in my module. I've also fixed a couple of issues with the Markdown in the readme file as well. I hope this helps. As long as the changelog markdown is of the following format, markers should be correctly inserted... # Changelog // this line is optional - not needed, but if it is present it is sliced off and presented left justified above the versions. ## {version string} {optional information, usually the release date} // H2 - github will style this with a bottom border - Change 1 - Change 2 - or - ### {version string} {optional information, usually the release date} // H3 - github will style this without a bottom border - Change 1 - Change 2 @tpr There was a bug in the way I was comparing versions. You should be able to stick with whatever formatting you prefer. That said, I think there is more flexibility with string versioning than using integers. With string versioning you should be able to have deep version if you'd like - "0.7.8.1" or "1.5.2dev" are all possible. I'll be moving my modules over to string versions as and when I update them from now on.
  14. @adrian I'll see what I can do over the weekend to try and get things working for TOCs in the readme files. Release Notes displays any files that start with "readme" - so you can split different topics into different readme files if that helps.
  15. I think you might be using the screen wrong. I tried that a long time ago and found it didn't really work. Edited to add: These new-fashioned LCD screens don't have quite the same kick as the old CRT monitors.