apeisa

These are from Win7 / Chrome31:

Great improvements Ryan. Surprised how big difference there is by removing the header. Also lots of little new improvements here and there! I like the new fonts, but some of the sizes are jaggy, at least on chrome / win7. I would say all bolds are messy (like page tree actions and button labels on warm theme).

If your login template is HTTPS, then how is the session even possible without SSL? Ah, it is. Our setup is actually little more complicated: we have https://*.pwire.fi ssl sert that we use for all our clients. So their domain is different with SSL. But basically if you always use relative urls, then it will not ever change for logged in user (if your login page is ssl of course). Though to be sure you can check in autoload module (or _init.php template) something like if user is logged in and http, redir to http .

@Soma, what is wrong here?

Hmm... not sure how to fix that. How have you setup your ssl? Or I mean where you define that admin is always SSL and public is not? We have always setup so that logged in users are https, so it will load just fine.

Or maybe just make it require faster clicks. It is way more "slower" than usual double click on windows.

PW is defintely more a CMF than a CMS. As a marketing strategy it is difficult to say which way is better. For technical people I have explained that PW is Django of PHP world.

GitHub is great way to go. Forum is fine too, specially when you are not sure if it's a bug or not (so more people looks for it and maybe tries to reproduce).

This looks super clean! Also I think this builds upon PW strengths without trying to "re-invent" everything. If you pull this with same quality code than these UI screens are, I think this would be definitely great candidate as a next default theme. As Ryan has mentioned the current improvements are some "first aid" for the theme challenge, all doors are open to take this to next level.

I am not too keen for it either. only accidentally done that few times.

yep, safari has actually different issue. it doesn't show edit page at all. stable chrome allows saving, but doesn't close modal. I am able to reproduce both issues, so should be able to fix after I find time.

yep, that is great starting point. remember that on module scope you need wire("pages") instead of $pages (same for all API variables).

try without $this and with two underscores. __("like this")

that is good way to go. But you can also easily built custom profile pages for your clients to edit. Those can be process modules (admin usage), like ProcessStudentEdit. That way you could extend things like student search etc. welcome Martin!

Thanks Marty! That is strange. Just tested it with Mac (through excellent browserstack). It doesn't work with Chrome 29 (and not in 30beta), but it does work on 31dev (also in mac). Also tested with Safari 5.1, which has other issue (doesn't show the editing iFrame at all). Since this works in IE and FF, so it must have been some bug in earlier chrome versions. I'll take a look at next weekend at latest. I would love to see this working in Safari too.

have you made hard refresh? works great here with chrome. also tested with Android browsers i have and all works.

Thanks Marty. That is probably also something that AjaxSave method in core doesn't support, at least yet. I just pushed new version: I added animation after submit (modal goes small again with spinning wheel), which makes this feel faster than before. Also made some tweaks etc, and this version works great on IE (10 at least, not tested others yet, I don't believe this works in 8, but probably works in 9), Firefox and Chrome. Hopefully someone of you Mac people can test if it works in Safari too?

Hmm.. it seems repeaters don't work either (images inside repeaters do work, but images/files go different route). I guess that is because of lacking support in ProcessPageEdit::AjaxSave method, but not 100% sure about that.

Just pushed this "ajaxified" stuff on dev-branch: https://github.com/apeisa/Fredi/tree/dev Hope you guys find time to test it. It feels superfast to use. Probably few bugs here and there, but we will sort those Marty: I decided to leave the FieldName=<Width> syntax all together and it now uses whatever there is for the field on settings (old default was always 100% for each field).

I think cleanest solution would be different kind of RTE. Something that all the big newsletter softwares are doing (mad mimi, mailchimp etc). Pity that there ain't any of those open sourced. I also think it could produce straight HTML and be somewhat drop-in replacement for current editors, keeping the metadata inside data-attributes or classes. But I have had less and less need for this kind of stuff, and I believe in future even less. PW and future is more and more about content management for multiple platforms (mobile web & applications, computers, television, consoles...) and there "layout building" is something that each medium does, not the CMS.

Note about ajax save & multilang: it actually save the default language to the langue that user has active. It ignores the others.

Ok, got little bit too excited and started building Fredi with Ajax saving & ajax page refresh (instead of the old clumsy submit => post processing => page reload). This is working great already, simplified code a lot and actually fixed the "images don't save inside repeaters" problem too. I also changed the code so that you won't be able to define the columns, but those will be inherited from the actual template context. This is great now that Ryan made tweaks along field dependencies so that there won't be "empty" spots at all (if fields doesn't make 100%, then last one in row will get larger). I also believe that even field dependencies will work on Fredi now (not tested yet). Only problem I am having currently: it seems AjaxSave method doesn't support multilang fields yet? https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L1037 I have only two languages: "default" and "test". If I change the default title value and save, that new value will be put on the test title and default will remain old.

Marty, that is implemented here, but not yet committed. I will add that soon, since there seems to be lots of interest for Fredi lately.

great progress Adrian!

I love the new themes and all the nice improvements (like font-awesome, "add new" etc) Ryan, fantastic work! I noticed that drag & drop file uploads aren't working: probably changes in dom are effecting the js init there?