Jump to content

adrian

PW-Moderators
  • Posts

    11,239
  • Joined

  • Last visited

  • Days Won

    374

Everything posted by adrian

  1. @Macrura - the fix is available in the latest version. The other major update to this version is support for resizable panels - there is now a resize handle at the bottom right of each panel so you can manually size to suit your needs. This is especially useful when you have one of the larger panels open (like the Field List & Values section of the Request Info panel) and it's taking up the entire screen and you want to compare values in the panel with what is on the page - now you can manually resize to fit where you want. Also, the Tracy core has started refactoring lots of code to use ES6, so those changes are being incorporated as well. Let me know if you come across any issues with this new version!
  2. Hey @joshuag - firstly I wanted to send some kudos your way - I feel like I've been complaining lots in my last few posts I have been playing around with RenderList, RenderEvent, RenderCalendar etc, and the backend Calendar views and they really are awesome - thanks for all the hard work! I do have a request though - I have been looking at the rrule in the json and wondering if you'd consider adding a helper to parse the rule into plain english. I'd love to be able to output this: WKST=MO;FREQ=MONTHLY;DTSTART=20180402T100000Z;INTERVAL=1;BYDAY=TU;BYSETPOS=2;UNTIL=20180428T235900Z as: Every second Tuesday from 10 am to 2 pm from April 2nd, 2018 till April 28th, 2018 Do you have any thoughts on this? Is there already an inbuilt method that I missed that would help with this? Thanks again!
  3. Sorry, I understand my mistake on this. It needs: Although I still don't know why the dateFormat is not being respected in the output.
  4. Looking at this all again now. I am working with manually created events (so there aren't any complications with API import) and I am still confused. This is what I set up: $recurme->renderEvent($page, array('dateFormat' => 'M d, Y @ g:i a')); results in: Error: Trying to get property of non-object on line: 682 of MarkupRecurme.module If I do: you can see that the "time" is off by an hour - probably a timezone issue, but how can I manually output something like: March 13th - March 30th, 2018 10:00 am - 2:00 pm This sort of output I am sure is quite common. The problem is that end_date: 1522562399 is 2018-03-31 11:59 but the event only goes until the 30th. So how do I get the 30th - do I have to parse UNTIL from rrule, or can do take end_date and subtract one day - what is the reliable way to get the actual end date? Sorry if I am being stupid - I can't believe I am the only person to come across these issues, but I don't think I am missing anything - I think the module just needs more properties with things like actual start date, start time, end date and end time so we can easily output custom formats. Let me know if you want to spend a little time on a live chat/call about this. Thanks!
  5. Thanks @Macrura - knowing the version number helped me track it down. It only happens in Production mode. I have a fix in place. I am working on some other updates at the moment, so I'll release this fix with those a little later today. Thanks again!
  6. I doubt it's a common scenario, but I have never seen a PW fieldtype work this way - normally you just call $page->fieldname so it's weird to get used to parsing an entire page to $recurme.
  7. What version of Tracy are you running? When you say "but not any source" do you mean that lime 89 is blank? That's what I am seeing on the latest version. Can you provide the d() or bd() call that is triggering the warning?
  8. Sorry, me again When I create a new event through the admin and it's a non-recurring event, it doesn't store the enddate: {"startDate":1522971420,"endDate":false,"allDay":false,"timeEnd":"08:00 pm" But you have no API method for getting the end time directly in your API calls (at least not that I can see) - what am I missing?
  9. Ok, more details:If I import a date, the json initially looks like this: {"startDate":1520956800,"endDate":1522440000,"allDay":false,"timeEnd":"02:00 pm","dates":["W11/13/Tue/Mar/2018","W11/14/Wed/Mar/2018","W11/15/Thu/Mar/2018","W11/16/Fri/Mar/2018","W11/17/Sat/Mar/2018","W11/18/Sun/Mar/2018","W12/19/Mon/Mar/2018","W12/20/Tue/Mar/2018","W12/21/Wed/Mar/2018","W12/22/Thu/Mar/2018","W12/23/Fri/Mar/2018","W12/24/Sat/Mar/2018","W12/25/Sun/Mar/2018","W13/26/Mon/Mar/2018","W13/27/Tue/Mar/2018","W13/28/Wed/Mar/2018","W13/29/Thu/Mar/2018","W13/30/Fri/Mar/2018"],"excluded":[],"active":true,"showResults":false,"rrule":"WKST=MO;FREQ=DAILY;DTSTART=20180313T100000Z;INTERVAL=1;UNTIL=20180330T140000Z"} Then if I open the page in the admin and save the page (without changing anything), it then looks like this: {"startDate":1520960400,"endDate":1522479540,"allDay":false,"timeEnd":"02:00 pm","dates":["W11/13/Tue/Mar/2018","W11/14/Wed/Mar/2018","W11/15/Thu/Mar/2018","W11/16/Fri/Mar/2018","W11/17/Sat/Mar/2018","W11/18/Sun/Mar/2018","W12/19/Mon/Mar/2018","W12/20/Tue/Mar/2018","W12/21/Wed/Mar/2018","W12/22/Thu/Mar/2018","W12/23/Fri/Mar/2018","W12/24/Sat/Mar/2018","W12/25/Sun/Mar/2018","W13/26/Mon/Mar/2018","W13/27/Tue/Mar/2018","W13/28/Wed/Mar/2018","W13/29/Thu/Mar/2018"],"excluded":[],"active":true,"showResults":false,"rrule":"WKST=MO;FREQ=DAILY;DTSTART=20180313T100000Z;INTERVAL=1;UNTIL=20180330T140000Z"} Notice the change in the startDate and endDate stamps as well as the fact that "W13/30/Fri/Mar/2018" is removed after saving. Help
  10. Even more confusion. Take these examples - why does the value of enddate vary depending on how I get it?
  11. @joshuag - I am also confused about the output of endDate - it's always a day after the specified end date - is this for some reason intentional? It seems confusing to me. Note that importing using the script you PM'd me is also problematic with this "bug" - if you provide an end date, the end date shown in the field edit dialog is one day before the end, but when you output it via the API it returns the end date I specified on import, so it's quite confusing to the editor.
  12. Hey @joshuag - I am quite confused about calling dates via the API. From the docs it looks like I should do: $recurme->event($page)->start_date; but what if I have more than one recurme field on the page? I am tempted to parse it myself like this: json_decode($page->event_dates)->startDate; because this way I can get the start date from my selected "event_dates" field. However I am sure I am missing something in how this is meant to be used Any tips please?
  13. The issue that @Robin S was having has been fixed in the latest version - seems like I wasn't seeing it because I am running PHP 7.2, but didn't investigate that too thoroughly. Thanks again Robin for reporting this and for access to test and diagnose it!
  14. Are the other languages active? on the settings tab of the page? You should set the status for each language to active during the import. Or after the fact you can do with the AdminActions module's "Page Active Languages Batcher" feature.
  15. Not saying it's a reason to switch, but it does support xlsx whereas that appears to require the paid version aggrid.
  16. True - it does define it, even though I don't think it actually ever uses it, but that explains why it's being calling that file
  17. One thing I don't get here is why that DatabaseMysqli.php file is being called. I don't think the PW core use mysqli anywhere these days. Do you have a module that is using $db vs $database?
  18. Hi @Robin S - I can't seem to reproduce this - the Request Info panel appears to be only adding one call. I am using the HannaCode textformatter and adding: bd($field->name); to the first line of the formatValue() method and with the RequestInfo panel open I get two dumps, and with it closed I get one. Could you share the module you are working on, or perhaps test with Hanna code, and maybe with a different field/template combo to see if there is something more specific required to reproduce? PS - Are you running the latest version of Tracy?
  19. Thanks @tpr and @Robin S for your work and thoughts on this. I haven't had time to test thoroughly regarding template level sort etc, but I just wanted to note that the initial issue of loading all siblings is definitely now fixed
  20. Would it be easier/more efficient to have << first < prev > next >> last links instead of trying to loop around at the beginning and end?
  21. How about: $this->editedPage->siblings('sort=-sort, limit=1')->first()
  22. Ok, dumping with the __debugInfo() magic method is now the default. You can disable this in the config settings if you don't like it and you can override for a specific dump with something like this: d($page, array('debugInfo' => false)); Hope you guys find this useful!
  23. Thanks @bernhard and @Robin S - a little more detail on PW's implementation of __debugInfo() is here: https://processwire.com/blog/posts/processwire-core-updates-2.5.27/#php-5.6-and-debuginfo and also point "8" from https://processwire.com/blog/posts/processwire-2.6-rc1-2.5.29-and-more/#processwire-and-phps-interactive-mode Robin, you are correct that the output will depend on what the developer of the class makes available. You end up with something like this which I think in general is much more helpful than the default: I think in general Ryan has done a great job with what is returned and I think for most Tracy users most of the time, this will be preferable to the full object. I think the best option might be to make it on by default, but you can either override this in the config settings globally, or you could pass: debugInfo => false in the d() or bd() call's $options parameter if you want the full object. Sound ok?
  24. Hi everyone - looking for some feedback. The Tracy core has just introduced an option to dump objects using the __debugInfo() magic method which PW also supports. It changes this: to: What I am wondering is whether to make using __debugInfo() the default or not. And also wondering how often you guys might want to switch between one vs the other - in other words, will it be ok as a config setting, or do you think it's something that should be easier to change on-the-fly? Thanks for any input.
  25. @Martijn Geerts - thanks for this module - it's coming in very handy right now! When you get a minute, it would be great if you could fix the PHP 7.2 countable errors: 34× PHP Warning: count(): Parameter must be an array or an object that implements Countable in .../modules/FieldtypeFields/FieldtypeFields.module:159
×
×
  • Create New...