Leaderboard

It's unlikely a single module will provide everything everyone will need for a login/registration system, because everyone's interpretation of its requirements will be different every time. Will users use email or usernames? What other details do you need to capture about the user? What validation needs to happen on these extra fields? Do people need to validate their email addresses, or do accounts have to be approved manually? What security roles and settings need to be applied? Where do people log in? Is there going to be a "remember me" option? What happens if they forget their password? What if there's a third-party backend system that the authentication needs to tie in to? Those are just some of the considerations I can think of based on my experience of building similar bits of functionality in the past. With the frameworks and CMSs I've used, I can't remember very many of them them that have been flexible enough "out of the box" to do what I needed without having to hack where I shouldn't, or ended up with me writing my own methods to replace theirs. To pick an example. I mainly use CodeIgniter, and have done for a long time. One of the "ready-made" libraries for users is called Ion_Auth (or something like that). In every application I've written with CI, it has never been a good fit because the application demanded either much more or a lot less; or I didn't like the way it handled a certain part. The API is already there in ProcessWire, you just have to utilise it in your template files to suit the website being developed. There really isn't much to it, and because of that, any module that did try to cater for it would either only cater for a particular type of site; or it would be overly complex and force developers into its own way of working - rather than the other way round. In lots of other systems, you have to get modules and plugins for just about everything that isn't in a WYSIWYG box, because the core system is too inflexible to let you do "stuff" any other way. With ProcessWire, the API is completely open to use how you want to use it. One of the reasons I dislike Drumlapress is for the plugin-for-everything mentality. Need to split out some images in a carousel? Install plugin X. Want to put some images in a gallery page? Install another plugin Y; and never the two shall meet (because when they do, their javascripts conflict, and the back-ends are totally separate...). Several months later you might want to put some of those on a map. Oh, that will be a separate plugin Z that doesn't really work with X or Y. And then you update Drumlapress to the next version because of a major security flaw (again). Plugin X is fine, but plugin Y breaks because it's not compatible with the latest version. And then your website is broken.

Problem Solved, updated the gist. To use: $image = $page->image; // image from $page, or any other ProcessWire image // $x & $y are required $x = 200; // width, the size of the box (max width an image can scale in width) $y = 100; // height, the size of the box (max height an image can scale in height) // $compress is optional $compress = 20; // makes heavier smaller then normal images, from (low) 1 to (high) 99 compression // usage 1 $img = $modules->get("ImageFitBoundaries"); $img = $img->load($image, $x, $y, $compress); echo $img->render(); // usage 2 $mod = $modules->get("ImageFitBoundaries"); $info = $mod->load($image, $x, $y, $compress)->info(); // also works: $mod->load($image, $x, $y, $compress)->info $thumb = $image->size($info['width'], $info['height']); echo "<img src='$thumb->url'>"; Thanks Dave, for your insight!

This thread is for the new PW admin theme being developed for 2.4. Zahari and WillyC, I'm sure you guys both have good intentions, but this is not the right thread to promote other admin themes and such. We're now focused on wrapping up and fixing bugs in the new theme, not redesigning it. This is in preparation for the very soon upcoming 2.4 release. Zahari–please do keep up the good work on your theme, post to the directory, and start a thread for it, as I'm sure many of us will enjoy using it too. WillyC–please don't let that one go beyond the sketch stage. I hope you can appreciate that there's no way one could ever get everyone to have the same viewpoint on subjective things, so that is kind of pointless. The goals here have always been more about the system. Then taking that system and reducing it to the most minimal, easy-to-use implementation. All while still incrementally improving on the old theme. The consensus has been that's what we've done, even if we're still working out some bugs. We'll let others take it and run with it in creating stuff more tailored towards their own preferences and other scenarios. The biggest complaints with the old admin theme were: 1) the colors don't have broad appeal; 2) the header area used entirely too much space; 3) the fields layout was too boxes-in-boxes with excessive linework, emphasizing the containers over the inputs; 4) the type was too small. The consensus and the math has been that the new admin theme solves these issues, while appealing to a broader audience than the old theme. Keep in mind there's no way to make everyone happy, so it's entirely expected to have a hater or two (I'd be more concerned if there weren't). Also keep in mind the old admin theme has a consensus of haters, among those that don't use it every day. So it's a bottleneck when it comes to new users. Is the new theme meant to be some kind of design masterpiece? Absolutely not–it is intentionally trying to avoid making design statements, and focused on reduction to essentials (though not to the point of looking like Craigslist). When it comes to the bigger design project (PW 3.0), we'll hand this off to Felix and Phillip (and perhaps others), who have already nailed the concept. That's my opinion, but we'll seek the input of the community to decide. My experience has been that small team design=good results, community/committee design=bad results. But that's another conversation. We'll move onto talking more about that once we've got 2.4 final. Regarding the Inputfield containers: yes there are still situations where the boxes-in-boxes (emphasizing the containers over the inputs) might suit an individual installation or preference better. But there are more where it doesn't. As a result, it's not as well suited as a default (and we've already been through this to excess), but it is something we always want to offer as an option. The new admin theme system allows for configurable spacing between the Inputfield containers via a setting provided to the InputfieldWrapper. We may even make it configurable within the default admin theme at some point, but I'd rather see other themes focus on things like that. As for the typeface: Arimo vs. Arial. I agree with most with the points about Arial, and I think the arguments presented here against using any webfont make sense. As much as I like Arimo and as good as it looks on my own computer, I think we've got to revert to Arial–it makes more sense with this theme's goals and in the big picture.

it is true that the more sites you build with PW the better you get at using it and thinking in terms of a collaboration between yourself and the api, and the more you read the forum, view the source code of the profiles, modules etc, you are constantly improving and becoming less of a 'beginner', but that term also implies that PW is comparable to the big 3 (and that eventually when you are no longer a beginner you'll be able to achieve those things in the same time as you would in W/J/D), and as Ryan recently pointed out, it's really not, and probably will never be something that can be compared 1-to-1 with those fully interfaced options. The more you know about and work with PW, the more you come to realize that there really couldn't be a generic frontend user management 'module' since the needs of any such system would be unique to the business/application logic of that project. The productivity and simplicity that the clients get through having their site be 100% custom in terms of both the front and backend is really priceless, and that extra time it might take to build something custom as opposed to using a pre-built component/module/plugin pays off over and over again for years to come. I have built a lot of sites with Joomla and a few sites with Wordpress. In 90% of those sites (that are stuck on those CMS) the clients still regularly contact me to perform content management work, because as simple as they might seem to techies, they are incredibly confusing and complex for the average user especially those people who update their site only once in a long while. When i compare that to the processwire sites built for clients, the result is that none of them ever contact me for content management, they can do it themselves, none of them break their sites, or destroy the formatting or look of the pages through gross violations of the wysiwyg... so my response to your post would be of course, it would be great if someone could write those modules, but I think they would need to be subsidized... maybe start a kickstarter campaign for whichever one you think is most helpful?

I know too well how difficult it is to hit everybody's wishes - you ought to try designing a site for a gaming community. "The whites! They hurt my eyes!!!" "I have a condition and your design will give me an epileptic fit" "Why would you use a bright colour?" And my favourite when we put a picture of a Troll (from a game) in the forum header: "We think your use of a troll is highly insulting - are you trying to drive all the players away?" I think that was more or less the point that I went into graphic detail about exactly where they could shove their 50 inch, 3d, multidimensional, ultra-HD, luminescent, thought-controlled monitors. It is enough to make you yearn for the world of old fashioned, stiff-shirted corporations.

Ipa, catch the Exception and print out the message, for example: try { // Login } catch (WireException $e) { // Print out message of exception echo $e->getMessage(); }

Hi everfreecreative I actually don't have much to say on the boxes in boxes thing as it isn't something that actually troubles me! By adding 3 or 2px radius in the right spots and selecting appropriately colored borders, panels, headers and playing with wrapper widths in my own themes, I find little that disturbs me in this area, personally at least. I have found that as the dev version moved from 3.6? to 3,8? some styling things had changed. And a little change can have a big effect. So depending on which version and which colors, you and I might have been looking a totally different things. Definitely on the last one, some important borders changed from a light transluscent blue to a light gray and it changed my perception considerably. And for the better. But whilst I did want to answer your question, I hope you understand that I want to leave all talk of issues of styling behind me now. I'll just do my own thing. As to extra line height issue, my personal thoughts are something like this... if your dealing with a short single line of text like a one or two word title, it makes little difference whatever you set it to. But when it will be expected to wrap over 3 lines of text, then line height becomes extremely important. I personally like line heights in the region of 1.1 to 1.25 depending on the font and it's size. Currently it was set to 1.6. Often I will set a unique line height for each 10/11px, 13px, 14px 15 px and 16px sizes on my client themes as I believe that it makes for heightened readability. I also play with letter spacing and color shade a lot to find the ideal presentation for each of the various functional pieces of text. It's like a Formula 1 setup. Critical attention to every minute little detail collectively matters a great deal. One of the few things I always do or now did with the old admin theme, which with one or two tweaks, I really liked the old admin theme BTW!, is change the line height of the description text as I found the default at 1.3 to be too much especially when you use it in the context of say a 30% widget. I will leave you with these screen shots that reflect my somewhat different philosophy on line height. I think I can guess which one 99% this tough crowds sympathies will choose.... hee hee! I will say thous that I set this one up first pass. I have not optimised mine yet as I was working on so many things at once. But Im happy to say my table styles are around the 90% mark to being finished. To me the standard 1.6 line height and the soft cells ( Heh heh any new wave teens here remember Soft Cell !!? ) are taking it towards almost a wall of text. Given the right i.e wrong display characteristics of the viewers device, these border might not even be seen! Again I say, like I said before in all my other posts, these are just my opinions. It can also be considered to be way too crammed and too vertically concise. It's all perception yes? As for WillyC, I give you full creative license to take my latest screenshot and make whatever edits you want and post them up here. For the rest of you, you obviously enjoyed laughing at them. And so in the true Christmas spirit, please have a great laugh at my latest screenshot for WillyC. Let's see what he can come up with ! I'll leave the closing remarks for Joss and let's all hope for something as positively sterling as the last one in true English fashion... Consider it my sporting Chirstmas gift to you all. So everfreecreative, thank you kindly for your taking the time to comment constructively. That's very kind of you. Merry Christmas to you! Btw, some many years ago I got myself printed a box of business cards. I was very happy with the design and all my friends loved them. Out of chance I happened to show them to an old family friend and little did I know that he came from a real old school traditional printing background circa early 60's. He even set up a printing school here in Malaysia in the 80's. It had like 4 4 color Heidelberg printing presses and 30 other printing presses. He gave me such a shelling when he saw them and told me what an absolute utter piece of crap my card was. It was a pivotal moment for me and I took it positively and took the the opportunity to learn, own my own, the subteties of typography and am ever so grateful to him that he did what he did. It's a life long journey but at least I have made some progree and continue to do so. My own personal journey is now focusing on trying to give discreet elements a little more vertical breathing space. I tend to make some things just a little too close together. Manfred 62. Thank you for your comment and focus on the idea rather then the presentation. If you'd like I would be happy to give you the link to download it and examine it and see where you can take it and what you would adjust. It was designed as a rather neutral starting point. Just PM me. Merry Christmas to you too! Are you a German in Germany? Do you ever get to listen to any of the Bach or Telemann Cantatas live? If you do, do pm me and let me know what it's like. I managed to listen to a Handel one in Sydney which was a wonderful opportunity. But I'd love to experience a Bach one! And thanks to the kind gentleman who sent me a very encouraging PM. Im out of this thread now and wont be back into this particular one. So no more questions please. But I will be back in some new ones next year to ask for help. See you guys then. Merry xmas and a happy new year to all! God Bless

yes of course, but it could seem that way to the 'beginners' who won't then be able to adapt the module to their site's logic; so i'm suggesting to have a site profile (that may include modules) where the full logic of the relations of fields-templates-modules can be studied and then reworked to the developer's needs;

And I do the opposite Joss. Almost always use double quotes, except when defining variables with straight strings. ps, I love curly and I love strings.

$getTest = $findit->ProfName->title; assuming that a field title is used for the template that is being used for the pages that are being selected.

One interesting thing about working with ProcessWire is that since you have to program in your own bells and whistles, rather than just installing some extension, it makes you pause and think whether you actually need them or not. The trouble with Drumlapress is that it is easy to just hit buttons and add things - so you do** Web design, like any sort of creative discipline, should be about the minimal. Even Van Gogh with his layers of oil was minimal - we don't know what he MIGHT have added to his pictures, but we do know that what he did put in he meant to put in. Oil painting is slower than sketching (especially for a lazy bugger like Van Gogh) and there was no way he was going to shove in anything that didn't work for its living. And so it is with ProcessWire. PW is not hard, but it requires you to actually do some work rather than hit buttons like most CMSs, and that makes the lazy ones of us take our time, keep it simple, and make sure we only put in things that actually need to be there. --------------------------------- EDIT I added two asterisks above and forgot to put why! So .... ** The situation has been slightly alleviated since, in Joomla at least, so many of the extension updates are now commercial (even some of the ones that really shouldn't be!)

You may already be aware of this, but apparently Isotope has a memory leak which the original developer's failed to address. More details and a fix are https://github.com/khiltd/isotope-leak-free

Hello, Since I last posted I've used processwire to create a simple content managed website and as an API data source for a Content-Publishing mobile application. I still intend on using it as a data source from within the Yii framework for the following reasons: Views I like that processwire gives you a raw template file and allows you to do what you like to output your HTML, but I found myself just trying to re-create the Themes/Layout/Partials structure provided by Yii. Folder/Class organisation With processwire I found myself just adding files to the modules folder, which is fine for a smaller project, but for a large project I would need to implement some sort of system that separated out the different types of modules and organise them accordingly, whereas with Yii I have the out of the box separation of Actions, Behaviors, Components, Extensions, Modules and Widgets. URL Management Processwire URL's were perfect for the small site I built, but I felt I had more out of the box control over URL's using Yii, with it's CBaseUrlRule class. Automated Testing Yii provides support for automated testing: http://www.yiiframework.com/doc/guide/1.1/en/test.overview In Summary - I really like processwire and I will definitely continue to use it stand alone, but I also still see how I could benefit from bootstrapping it into Yii, so I will be going ahead with that also.

Hot off the oven, a bookmarking application built with PW framework http://processwire.com/talk/topic/4175-bookmarking/?p=43258 And an intranet office suite: http://processwire.com/talk/topic/2920-web-application-intranet-office-suite/

Yep, admin uses the checks, but on API level the user & pass is created. There's no check in $u->pass("1234"); I tried it and $session->login("test", "1234"); and works as aspected

Read my previous post onjegolders.

Setting the password or any value directly through API won't give you any validations. This is a functionality the inputfield is usually doing and processed in a certain way (input). If used on non interactive level the API doesn't restrict you from doing things you can't do or aren't allowed in the admin. So you ultimately you have to take care of those thing when using the API directly. So while this works: $u = new User(); $u->name = "test"; $u->of(false); $u->pass = "1234"; $u->save(); "1234" isn't a valid password if PW's password inputfield would validate it, but it's correctly saved and works. Just not recommended to code public sign up form like this. So you have to take care and add some checks to make sure its min-max length is ok and also that there's some at least 1 number and letter. If you're doing it manually and want to use the validation of the password field in PW you could use InputfieldPassword. // "_pass" = the confirm password / actually two inputs $p = new WireInputData(array("pass" => "1234", "_pass" => "1234")); $inputfield_pass = $modules->get("InputfieldPassword"); // load the inputfield module $inputfield_pass->attr("name","pass"); // set the name $inputfield_pass->processInput($p); // process and validate the field // if any errors found if($inputfield_pass->getErrors()){ print_r($inputfield_pass->getErrors(true)); } // or if coming from a form (POST) with the field names already "pass" and "_pass" $inputfield_pass = $modules->get("InputfieldPassword"); $inputfield_pass->attr("name","pass"); $inputfield_pass->processInput($input->post); // process and validate the field // if any errors found if($inputfield_pass->getErrors()){ ... } After all if you're setting a Password directly manually with the API you don't need validation, you are directly responsible to make the password strong.

The notices system actually doesn't have anything to do with jQuery UI other than that the default admin theme makes use of jQuery UI class names when generating the markup for notices. But for your own front-end, you can make use of the $notices API variable to output them however you want. It can be as simple as this: echo "<ul>"; foreach($notices as $notice) { $class = $notice->className(); $text = $sanitizer->entities($notice->text); echo "<li class='$class'>$text</li>"; } echo "</ul>"; Then you would want to style the two type of notices in your CSS: .NoticeMessage { color: green; } .NoticeError { color: red; }

Any modules that extend: Inputfield, Process or ModuleJS will auto-load their CSS/JS files if they have the same name as the module and appear in the same directory. However, in order for that to work, their init() method has to be called. So if your module extends one of those, and has an init() method, then make sure to call the parent init() method: public function init() { parent::init(); // ... then your code }

If I had to put it shortly: PW gives you (that are missing from many more traditional frameworks): Admin, users and access management UI for building your data schema (clicking on admin instead of coding) Url mapping to pages (no need to define routes) Something pretty similar to most (with a twist of course): PW API == GOOD ORM Controllers == template files can be easily used as a controllers What is missing (what some frameworks have): Crazy amount of helpers (as others have noted, using zend classes or flourish can be good help in that kind of situation) Routing (I hate doing routes... mostly repetition) Custom template languages Strict rules how to construct your code What pw "requires" that you might not like in your app: Unique database schema: you don't have single "posts" table, instead you end up with field_title, field_body, field_author, field_date etc.. tables MySQL, MyISAM