adamspruijt

Hey @ryan! The new custom classes are amazing, basically my dream feature for how I build sites. Thank you! Just wanted to ask about an issue I ran into. Like others I started playing with this as soon as I could. I ran into some issues that I wanted to check if they were actual "issues", intended behavior or maybe just "not ideal, but currently not solvable"? Currently two things I ran into: 1) Repeater and Repeater Matrix pages can't use DefaultPage methods. This one makes sense to me as I imagine it's as simple as, the don't extend DefaultPage, but if they can maybe they should? Not sure. Basically I have some simple helper methods that were previous set as hooks, now when using them in a loop through a Matrix field I get Exception: Method RepeaterMatrixPage::summarize does not exist or is not callable in this context . I can get around this by calling $page->parent->summarize() so it's not critical, but it's certainly not intuitive when looking at the code why I'm calling on the parent instead. 2) I have a fairly complex Recurring Schedule system in the site I'm working on. I moved a "getFormattedSchedule" method to the EventPage class, in most cases it works brilliantly, and certainly allowed for cleaner code in my opinion. I just discovered though if I want to use the method in a Page::saveReady hook in order to cache the formatted results I get basically the same error as the above "not callable in this context". In this situation I find it a bit more confusing since I would assume the classes would be loaded before hooks? Scrap #2, that one was on me. Still would love to see the below life-cycle doc, so I'll leave it for some context. Somewhat per #2, do you have a detailed overview of the ProcessWire lifecycle anywhere. If not I'd love to see one eventually, often when developing more complex systems using PW I forget the exact order everything is loaded, accessed, etc. Would be nice to have something as clean and easy to refer to as the PW API docs. (Bravo on those too by the way, best in class for sure).

I landed here from a somewhat related issue I was having. The API now supports strings, objects, ints and arrays as valid. LINK

Same question as @Torsten Baldes this feature seems kinda half finished in its current state without UTF-8 code ranges implemented. I would like to build a new site with Chinese, Japanese & Korean page name support, but as is I wouldn't feel confident that I'm covering edge cases.

@horst Agreed, looking at the way the zoom feature will work on the focus cropping I think I will be able to migrate.

Any chance we can get the addition of a method to check if there has been a crop defined for the image (over the default)? And possibly some way in the admin to reset the crops? By all means if I get a chance I will look at doing this myself and submitting a pull request. Thansk @horst

Hey, sorry to resurrect this thread, but I think my question is closely related and if possible a better solution. I am trying to sort my repeater before save using a hook, is this possible? Current code below doesn't work. $pages->addHookAfter("saveReady", function($event){ $page = $event->arguments[0]; if ($page->template->name != "statistics") return; $page->stat_websitepageviews = $page->stat_websitepageviews->sort("date"); });

Not the most beautiful solution but you can just add an empty construct to the Wire class to suppress the deprecation notice like public function __construct(){} I don't believe this should cause any trouble in PW (haven't tried it myself), though I wouldn't personally use this in production as I would assume you would just turn off deprecation notice in production. I can understand it being frustrating to have the notice show up in dev when debug is on.

Couldn't this be solved by just using the Ajax field load feature ProcessWire already has, seems that would be an easier solution? I imagine Firefox would not fill a password field loaded this was, though I could be wrong.

I am currently still experiencing this with PW 2.7.2 on any version of PHP 5.6+ Has this not been fixed yet, is there a patch I can manually apply. I'd rather not have to downgrade my dev environments just to be able to use xdebug. Heck, XAMPP ships with 5.6 by default now.

Ok, thanks Soma, I guess it good to know that I'm not alone with the issue. Hopefully better chance we can find a solution. I kinda wish the error was happening on my dev environment and not on the live site, would be a lot easy to try and help find the bug then.

Hope the title is at least a little bit descriptive. I will try my best to explain what seems like an incredibly strange and probably very rare issue. I have the follow code in the init.php file (using latest PW dev). The code below basically covert a date string like say "first Monday of March 2016" into a usable date while making sure the date is in the future. $pages->addHookBefore('save', function($event) { $page = $event->arguments[0]; if ($page->template != "holiday") return; if (!$page->dev->date_string) return; $year = date("Y"); $date = strtotime("{$page->dev->date_string} {$year}"); if ($date < (int) date("U")) { $year++; $date = strtotime("{$page->dev->date_string} $year"); } $this->message("Date set to " . date("Y-m-d",$date)); $page->date = $date; }); It works just fine as written above, but originally I was using this $pages->addHookAfter('saveReady', function($event) { $page = $event->arguments[0]; if ($page->template != "holiday") return; if (!$page->dev->date_string) return; $year = date("Y"); $date = strtotime("{$page->dev->date_string} {$year}"); if ($date < (int) date("U")) { $year++; $date = strtotime("{$page->dev->date_string} $year"); } $this->message("Date set to " . date("Y-m-d",$date)); $page->date = "{$page->dev->date_string} $year"; }); The only difference being. using "after saveReady" vs "before save". Either setup works fine on my local dev environment for those wondering. But on the live website, when a page using this code get saved it sorta gets "corrupted". The page becomes unviewable even if it is published and not hidden and the images and dev tab sets disappear. When the page is set back to unpublished thew fields are visible again. I got looking in my database after a great deal of frustration with these "corrupted" pages and saw that the trouble pages had strange status values. (17562, 141313, etc). Not sure why the status is being affected... For now I have obviously left the working code in place, but thought I should share this strange issue, maybe its a processwire bug? Maybe a hosting issue (I also find I have to access images differently on my dev machine vs my live server, $image vs $image->first, maybe related)? Hope this can help in some capacity is anyone else has had a similar issue or if its a PW bug. Not sure when I'll be back to take a look at this thread, but thanks ahead of time for taking a look.

I don't have any help to contribute, but unfortunately I have also been stuck with the issue for some time now (since at least 2.3). Still experiencing it (only on my remote host, not on local dev machine). Just thought I should add my two cents, maybe the issue isn't common but this also is not a one off.

Just thought I'd add to this thread a little suggestion. HTML email are a nightmare and I know getting a great design setup and working even decently consistently can be a pain. I use Mailrox (https://www.mailrox.com/) and have had pretty great results with it. Once you get used to the process its pretty quick to use. Not sure what they are going to charge once out of beta but so long as it is reasonable I'll be signing up! Oh and, LOVE WireMail class, so much clearer to use, I ALWAYS found myself forgetting how to properly send an HTML email. Thanks Ryan!

SOOO sorry about that Alxdre' I recently pushed compatibility fixes for Unify with the 2.3.5 dev version of PW and it seems I missed this error coming up with the current master. I pushed a quick fix.

Use it for all my private work, sooo awesome.