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.

Just thought I'd share some design I was doing and change the subject from all this font talk. My take on the Autocomplete field and page sorting NOTE ** I replace the ui-icon with font-awesome with some clever CSS... (not that clever really I suppose but it has worked nicely)

Updated for compatibility with current dev version 2.3.5

I'm talking about form/style not function. ProcessWire arguably functions better and more logically than any of those CMSs by a long shot. WordPress might be a bit bland but it is consistent, though not the best example I believe it is still better than PW 2.3 admin (aesthetically).

I have been playing with the new theme/building my version of what I think should be the default and I have some suggestions/complaints/requests: I really don't like the sub-menu items personally, I don't see them as a worthwhile addition, particularly when their usefulness really only applies to the process of setting up the site and they are no advantages to clients. If the sub-menu items are here to stay can we PLEASE consider the idea/implementation of Admin Themes being able to "bootstrap" in configuration options (these would be unique to each theme). For example the default theme could add and option to turn off the sub-menu, or the drop-downs all together, we could also set the the theme "color" setting here instead off needing to alter the "config.php" file. In the case of my theme I showed earlier I could add an option to turn off the "PageListItem dots" I created, because I'm sure some won't like this idea. Also if the Sub-menus stay could we find a better value that 100 for the item limit, maybe 20, again if the above was implemented an admin could just change this. Also I thought maybe if the limit were say 20 and you had more than this maybe the default configuration could be to show the most recently added or edit templates first and then at the bottom of the list show a "View all" link that would have a bit of a different style to help it stand out (I understand you can just click the main Field/Templates entries themselves but sometimes displaying things twice can't hurt and can avoid confusion) It would be preferable it when I page does not have children the ".PageListNumChildren" item was not rendred at all, currently if a theme designer applies a Background to this element the empty ones become visible. Could we get "utility classes" on the first and last "Inputfield" items or a row, this would make having subtle style tweaks to these much easier. .... I have more I think but need to go for now and pick up the wife from work!

I have to say I agree a lot with what Felix is saying here, though I sure our methods would differ in some ways the overall message is the same, the admin interface is holding PW back. While the new design is an improvement (for the most part) it really doesn't hold a candle to Ghost, Craft, Statamic or even WordPress, and I feel like this is at an extreme odds with how the API its self functions which is clean, modern, easy, concise and beautifully self apparent. Some of the other things mentioned here I have mention before as well, a more modular approach, fixing the massive overuse of !important, migrating away from jquery ui (its antiquated, bloated and generally looks like shit, sorry), adding font icons (in the new default! yay!) so on. I believe PW can dominate if its gets the "sex appeal" it sorely needs and frankly the new theme still isn't going to get us there, not yet at least.

Agreed on the notifications, kinda how I did it in my version? Though I think the nav is a tough one, the numbers of items can very greatly from site to site, and often clients will see far fewer links. Maybe some type of "responsive javascript" will need to be used to determine if the links are overflowing, was the image you posted a working example or just a mock-up?

Totally agree, I usually do that and added it to my version.

Made a compromise that I'm happy with. Same technique might be a happy medium for Ryan's theme as well. The more I look at it the more I like it. Awesome!

You make a good point, it still makes me a tad nervous, I think those clients who use multiple tabs may find it a bit hard to "reacquaint" themselves with the page. Regardless I'm open to it, and like any good developer or designed I'd be glad to be wrong and learn something instead!

Keen is an understatement for me, no CMS comes even close, PW is a quantum leap in CMS's. I like many others here have a hard time bothering with anything else anymore. I looked for soooo long for something with the logic of PW. And while I still look because I just find software and CMSs fascinating, nothing has yet to even give PW any competition in my mind. I believe with the right design and marketing PW can be "the next big thing". Oh and thanks for the complement!