Leaderboard

Hello everybody, a few weeks have been passed since the last update. As you maybe remember, we introduced LdapSignIn, a module which allows you to sign in via an LDAP server account. Since you guys reported that there are many features missing to call it a "solution for Active Directory". Well, during the last weeks, we've thrown the module away, restructured and rebuilt it from the ground up. So we can now truely say: yes, this is a real solution for this porpuse. First of all, we've split the LdapSignIn module into 3 different modules WireAD handles the connection between ProcessWire and the Active Directory. It delivers a straight-forward API for authentication and accessing objects in the Active Directory. So your modules can access it as well. LoginAD extends the ProcessWire login process, so users from the Active Directory can log in. LoginSingleSignOnAD enables Single Sing On for ProcessWire using an Active Directory. Second, the modules also include a set of realy nice features: User and Group Migration You can define rules to map Active Directory user and group attributes into ProcessWire user and roles fields. Groups in Groups WireAD is able to detect groups in groups. So if user A is member of group B and group B is member of group C, user A is migrated as member of both group B and C. TLS and SSL WireAD handles connections via SSL or TLS to your domain controllers Load Balancing You can specify more than one domain controller to load balance between them Auto-detect Base DN or manually specify it Unique User and Role Objects Users and groups are migrated using their Active Directory GUID, so they are mapped as unique objects in ProcessWire Third, I created a demo video to show you some of these features: So what do you think? Please leave a comment below. Greetings from Germany Marvin

Just to tell you I'm not a coder, I'm a designer and artist who happens to like coding as it's also a creative process. I used Tpyo3, Wordpress, Joomla, WebEdition, Modx and other CMS when starting with CMS's. I barely could code php. I only struggled with those platforms and had to deal with stuff I didn't want to, be it security issues or updating, learning something arbitrary platform specific. Modx happen to be a tool I worked with before ProcessWire. Within days and many hours I had a prototype of a module which didn't do anything other than say hello. All those system never really let me do what I wanted without getting in the way or installing some plugins that didn't work really. It's because they're too opinionated to be useful in a wider range of contexts. They're all cluttered (I think you got that all wrong). Which all lead to frustration and hours and hours of wasting fighting a system. They try to save you time but in fact they put you in constraints that often make little to no sense. Now all those systems try to solve certain issues by putting yet another layer of complexity and so on. Then I discovered PW and finally I was in charge, saving time, focusing on things that really matter. Within an hour I had my first module "HelperFieldLinks" working without even reading a manual other than the HelloWorld.module. It's so simple, it didn't take me long to see the simplicity and power of PW. I am able to put contrains where the project demands and not the system. It's all so simple even I could as a non coder. PW makes me shine, and people think I'm a good coder. lol. So wrong. I have built websites for my mom and sister, and never had to explain or show them how to edit their site, they found out them self, which speaks a lot of the usability of PW.

Iisandi, that's a pretty good summary, and again, you've got some very good points there. At this point I'd really suggest dividing this thread to separate discussions about more specific features / areas of interest, though; this discussion is getting way too big to manage and keeps branching into all sorts of directions It's not about WordPress Though that's definitely not the core of the discussion here, the truth is that this has nothing to do with a specific system. WordPress is popular, so it's an easy way to address the difference between ProcessWire and many of the old school CMS products out there, but we don't hate WordPress specifically (well, some of us might). We do get annoyed when people jump in and start telling us what to do without considering that what we have now might be a well thought out product when it's just not what they expected. This forum gets regular posts from folks who jump in, take a quick look at ProcessWire, and based on that tout that "you're doing a, b, and c wrong, do them like system x".. or, more simply, "why can't ProcessWire be more like system X?". While some of the points they make are valid, they're missing the big picture, which is that ProcessWire really doesn't aim to compete head-on with some of those other systems. There's no point in that; it's the red ocean of web platforms. We don't want ProcessWire to turn into a site builder In it's heart PW is a tool that allows people to build anything they wish, exactly the way they wish. It's true that building sites with ProcessWire requires knowledge of how stuff on the web is built, and if you're looking for a simple "site builder" tool then perhaps something like Squarespace really is closer to what you're looking for, but at the same time the stuff already built with ProcessWire should be as easy-to-use for non-developers as possible. That's definitely something we should focus on, and if you take a look at what's been happening around here, you'll notice that we have been focusing on that (As a related note, I personally wouldn't be surprised to see tools like WordPress, as it is now, eventually die out in favour of site building tools like aforementioned Squarespace, or evolve into something very similar, while frameworks like ProcessWire will be needed much longer to empower those platforms.. but that's another discussion entirely.) You get what you give To get back to this topic, I'm starting to think that you're really not against all that. Your initial messages touting the death of ProcessWire, telling that it's only for developers, and pretty much stating out cold that those developers don't know shit about working with / for the end-user didn't exactly suggest that you "get this". Those comments took the discussion exactly to the wrong direction, so as a friendly tip, refrain from that sort of stuff and you'll get much better results around here. Many of us are designers, developers and people who've worked with a lot of of clients on a myriad of projects, and to suggest otherwise is just plain rude and provocative (and unlikely to yield the results you wish for) Extend ProcessWire, don't try to bend it The point is that as long as ProcessWire remains flexible and framework-y at it's core, none of us will be offended by modules built on top of that. That's the thing you need to keep in mind here: if you're saying that the core has to go to this or that direction, you're likely to face negative attitude. The core has a great direction, led by Ryan, and we're all behind that. In short, as long as possible try to keep the discussion in extending, not modifying, ProcessWire. The things you've mentioned, like admin themes, modules that do things out-of-the-box, packaging ProcessWire with things you need it to contain in your projects, integrating other tools, etc.. none of that requires ProcessWire itself to change. That's all you stuff you can build on top of ProcessWire, by extending it, and that's exactly because it is what it is now -- a flexible and non-opinionated platform form building just about anything (though mostly stuff that lives online). Also: I've built a CRM of sorts with ProcessWire, I've built a lot of application-type stuff using it, and most of my ProcessWire projects involve quite a bit of behind-the-scenes magic from integrations to imports and so on, but none of that will ever be described here as public examples, as they are not public per se. That's the "problem", really: most of the time we won't be able to show those things to others, even if we wanted to. They contain private information, and in a way they are private information. While you can tell a lot about ProcessWire simply by looking at the (public) sites built with it, that's not the whole truth. -- Now, please do discuss these things further -- none of us are against the discussion or the ideas, as long as you keep in mind some of the (hopefully understandable) things I've tried to point out here

Teppo has nailed it. It's the unfriendly comments from earlier on that derailed it and hence the replies - it shouldn't be surprising that people got upset when you talk about the death of a platform that is alive and healthy because it's not headed in the direction you want and basically ignoring the many others who are happy with it doing what it does. But let's put that aside for now or we will be going in circles. So firstly, as teppo says, Processwire is a framework. It is possible to extend ProcessWire to work in the way you want, but I know this is frustrating you as you want examples. There are too many examples - I have a whole Intranet running news, asset tracking for thousands of assets, purchase orders and invoicing, health and safety observations, contract information and tracking, ship tracking (with some maps integration) and a knowledgebase that links heavily into the assets so we have instruction manuals and guides on how to fix them as well as their fault history). What I can't do is show you any of it because it was built for a client. So that is a Web application - when its function is to process business data. The back-end of an ecommerce shop to me is an application too. The reason people say "you can do anything" is because you can. Your imagination should be allowed to run wild - because Processwire is essentially a framework that still let's you use PHP you can theoretically build anything you can see out there that is already in PHP but it depends on programming skills to make any of it happen.

There is a way, and it works exactly as you described Only your syntax is slightly off. You need to pass an array like so (or prepare it beforehand): $SomePage->render('optional_non-default_template.php', array('recipient'=>'Mr. North')); Then on that page’s template you can simply call $options['recipient'] and it will === 'Mr. North'.

This looks great Marvin. My only suggestion would be to have the GUID as a separate field and not use the name field. I think I know why you have, but for example I already have an Intranet with a lot of code that relies on the name field doing what it does now for some other checks I have (yes, it's a bit selfish of me ). What you could do is have the module install a new field for the GUID and attach it to roles template as well as the users template so that the role name displays in the list instead of the GUID - same with the user name at the bottom-right of the screen. You could then have the module hook into field delete to make sure that field doesn't get deleted by anyone unless they uninstall the module. You also then have some meaningful content in the name fields if someone did un-link their site from AD for whatever reason. Either way, this is amazing work and I would happily pay for it if it's a commercial module

Marvin, this looks great -- the feature set has most of the things I can think of right now, and, in fact, this looks like something we could use pretty much out of the box. Many of our sites these days are using the UserGroups module, so I'd probably be looking into adding a few fine-tuning settings to make these modules work together nicely, though What's your take on cleaning up users/sessions, i.e. does this module check if user account is still valid and active (and, preferably, if groups have changed) in the AD? That's something we've found pretty important in "more serious" use cases. Also: do we get to play with the source, is this a free or commercial package.. what's your plan here?

I think I am graduating from a total PW newbie to some murky status that would announce "I know just enough to be dangerous..." I currently have four PW sites under development. Things are going well for the most part. The more I spend with the system the more I like it. Anyways, to the topic at hand. Have any of you produced a guide for your clients on how to manage their Processwire sites? Not looking for a site building guide or how to develop stuff in Processwire, rather just some clear explanation/tutorial/guide for site owners on how the admin works, how to edit page content, how to use the CKEditor, working with images, etc, etc. Of course each developer's sites are going to be different. But I bet the majority of this information would be common to most Processwire sites. Any video screencasts on this topic? Love to see what others have produced. If this is an area that is lacking for the Processwire community then I would gladly contribute to any combined effort here. I am far from a Processwire expert but there might be value in a guy like me who has writing experience. Sort of like taking well intended "geek speak" and helping to translate it into plain english that new site owners would appreciate... Thanks, Max

Please excuse me for referring to myself: discussed "a zillion times" ... This sentence should become part of the forum rules. Maybe some of you know the funny story written by Paul Watzlawick in "The Situation Is Hopeless, But Not Serious: The Pursuit of Unhappiness"? A guy is seeking for his lost keys under a lantern but can't find. Asked if he lost it under the lantern he replies: "No, I lost it somewhere else, but only here is enough light to find it."

@Zeka, There would be several ways to do what you want and it will depend on some factors. I would guess that the majority of PW sites that configure products would be using pages to store the products (1 product per page); Your product template would contain these fields: product_name qty_per_unit unit_price You could either use the ProFields lister to make your list as above, or create a page-table on the parent page of the products and then when you view the product parent page you would see that list. - - - - However, if your needs are simpler, then you could use ProFields Table to make a table like you have, and then you would actually be able to edit the fields inline like that. With pages you would have to click to get a modal and then edit the 3 fields. - - - - And then there is yet another way you could do it using a hybrid of both things described above; I'm actually doing this 3rd approach on a site now (and the reason is to save time on entering many rows really fast, but we need the products to be pages for other reasons..) 1.) setup the ProFields table with the fields (and it would look almost identical to your screenshot) 2.) write a simple module to create products (using pages) when you save the page containing the table. The module would cycle through the table and check to see if the product already exists, and if it doesn't it would create the product; it would also check each page-product for changes/edits to the fields and update as necessary; so your Table would become sort of a proxy entry-instrument for the product-pages;

Worked for me also. Now I am using it as practice on how to update Processwire. Crosses fingers.

It worked. I'm uploading it, then sharing the link here. Edit: Here it is: https://github.com/NicoKnoll/site-skyscrapers

new german updates for actual PW dev 2.5.8 (06 November 2014). https://github.com/M...ang-de/tree/dev PW dev translation now contains 126 files

I don’t have a custom example, but it’s always a good idea to check out the source code of the module itself. You’ll find the render() and processInput() functions particularly interesting. In the end though, you can pretty much do anything you want, as long as the name-attributes of your inputs match the ones processInput() expects. So if you want more control than the options array gives you, you may just write static mark up into your template file, or you may put in the effort and take the fieldtype’s configurable settings into account, depending on your needs.

I totally agree with this. I would not be pleased if the core changed but am more than happy to see Processwire further extendable via modules. Nicos WiteThemes idea does appeal to me as far as themes go. This would keep both sides of the camp happy as far as accommodating those that wish to create or sell and use themes for Processwire and I think beneficial to both sides. I am still a little confused why there is opposition to this. I understand that there are some worries that the standard of the forum would go down but this could be sorted by making a dedicated section or forum for such discussions on this topic. It's just an idea before anyone sends the dogs after me. .

I tend to do something different each time. But i use Soma's notes module to write halp for each template. That keeps it in context

Just my little contribution, and for a change, I fancy being a bit annoying. ProcessWire is NOT Wordpress or Joomla It is not in direct competition with those platforms, but is meant to be something far more versatile and powerful for the professional user, yet open enough that the less knowledgeable user can learn and get their head round it in a way they enjoy and can find beneficial. The mistake, in my mind, that has been made in all zillion and one discussions about this is that they all start with making a comparison between the Drumlapress user base and the ProcessWire user base. They are different solutions in a different marketplace. If you want to make a comparison, choose the correct marketplace: Modx, Expression Engine, Liferay, even and loads of others which are about DEVELOPING solutions, not gluing them together. And when it comes to usability, when I used Joomla, I spent a huge amount of time making sure that clients could NOT update modules, user permissions and all the other things that would break the site. Trouble was, even with the new persmissions systems, that still wasn't properly possible. This "successful" application turned out to be inflexible, bloated and not fit for the modern application developer. Our job, as developers, is to create a solution for our clients that allows them to update those bits that fit with their skill set and their needs. They are experts on their products, their brand, their business structure, but not web development - that is why they hire a web developer in the first place. When I teach someone to use their PW interface, I find it a very short process. They get it immediately. There are three reasons for that: The interface is simple I remove everything they don't need or should not use I create the forms and the descriptions in a way that is completely in tune with their business process. Processwire allows me to do that. Wordpress and Joomla do not. I might not be a certificated Montessori teacher, but I have spent 35 years in advertising and communications working on high end internal and external communications solutions for some of the biggest companies in the world - Philips Electrical, British Airways, British Gas, Philips and Drew to name but a few. (Just in case anyone was wondering where my writing skills come from) Based on all that experience, I love the way I can use ProcessWire. I love the simple approach; the clearness and the focus on letting serious developers and communicators do their clients proud. I only see it getting better and stronger and more respected - but I see it doing that WITHOUT having to imitate a bunch of blogging software!

Hi lisandi, while I support your effort to discuss matters of user friendliness, please note that the matter "PW compared to Joomla, WP, XYZ etc." has been discussed a zillion times. So, I think this question has the potential to distract from what you originally intended. Better leave it to threads that already exist.

@Macrura Glad this worked out for you. Actually, the PW admin interface does what you are after already (if I understand you correctly.) If you edit a template and look at the AsmSelect list of fields in the template - each one of them is clickable and brings up a modal edit for that field's properties when used in that particular template. This would suggest that everything you need is already built right into AsmSelect so I'd suggest you have a look through the source code and see what's commented in there and how Ryan uses it.

Wire Mail SMTP An extension to the (new) WireMail base class that uses SMTP-transport This module integrates EmailMessage, SMTP and SASL php-libraries from Manuel Lemos into ProcessWire. I use this continously evolved libraries for about 10 years now and there was never a reason or occasion not to do so. I use it nearly every day in my office for automated composing and sending personalized messages with attachments, requests for Disposition Notifications, etc. Also I have used it for sending personalized Bulkmails many times. The WireMailSmtp module extends the new email-related WireMail base class introduced in ProcessWire 2.4.1 (while this writing, the dev-branch only). Here are Ryans announcement. Current Version 0.8.0 (from 2024-09-25 -- initial version 0.0.1 was pushed on 2014-03-01) Changelog: https://github.com/horst-n/WireMailSmtp/blob/master/CHANGELOG.md Downlod: get it from the Modules Directory || fetch it from Github || or use the module-installer in PWs admin site modules panel with its class name "WireMailSmtp". Install and Configure Download the module into your site/modules/ directory and install it. In the config page you fill in settings for the SMTP server and optionaly the (default) sender, like email address, name and signature. You can test the smtp settings directly there. If it says "SUCCESS! SMTP settings appear to work correctly." you are ready to start using it in templates, modules or bootstrap scripts. Usage Examples The simplest way to use it: $numSent = wireMail($to, $from, $subject, $textBody); $numSent = wireMail($to, '', $subject, $textBody); // or with a default sender emailaddress on config page This will send a plain text message to each recipient. You may also use the object oriented style: $mail = wireMail(); // calling an empty wireMail() returns a wireMail object $mail->to($toEmail, $toName); $mail->from = $yourEmailaddress; // if you don't have set a default sender in config // or if you want to override that $mail->subject($subject); $mail->body($textBody); $numSent = $mail->send(); Or chained, like everywhere in ProcessWire: $mail = wireMail(); $numSent = $mail->to($toEmail)->subject($subject)->body($textBody)->send(); Additionaly to the basics there are more options available with WireMailSmtp. The main difference compared to the WireMail BaseClass is the sendSingle option. With it you can set only one To-Recipient but additional CC-Recipients. $mail = wireMail(); $mail->sendSingle(true)->to($toEmail, $toName)->cc(array('person1@example.com', 'person2@example.com', 'person3@example.com')); $numSent = $mail->subject($subject)->body($textBody)->send(); The same as function call with options array: $options = array( 'sendSingle' => true, 'cc' => array('person1@example.com', 'person2@example.com', 'person3@example.com') ); $numSent = wireMail($to, '', $subject, $textBody, $options); There are methods to your disposal to check if you have the right WireMail-Class and if the SMTP-settings are working: $mail = wireMail(); if($mail->className != 'WireMailSmtp') { // Uups, wrong WireMail-Class: do something to inform the user and quit echo "<p>Couldn't get the right WireMail-Module (WireMailSmtp). found: {$mail->className}</p>"; return; } if(!$mail->testConnection()) { // Connection not working: echo "<p>Couldn't connect to the SMTP server. Please check the {$mail->className} modules config settings!</p>"; return; } A MORE ADVANCED DEBUG METHOD! You can add some debug code into a template file and call a page with it: $to = array('me@example.com'); $subject = 'Wiremail-SMTP Test ' . date('H:i:s') . ' äöü ÄÖÜ ß'; $mail = wireMail(); if($mail->className != 'WireMailSmtp') { echo "<p>Couldn't get the right WireMail-Module (WireMailSmtp). found: {$mail->className}</p>"; } else { $mail->from = '--INSERT YOUR SENDER ADDRESS HERE --'; // <--- !!!! $mail->to($to); $mail->subject($subject); $mail->sendSingle(true); $mail->body("Titel\n\ntext text TEXT text text\n"); $mail->bodyHTML("<h1>Titel</h1><p>text text <strong>TEXT</strong> text text</p>"); $dump = $mail->debugSend(1); } So, in short, instead of using $mail->send(), use $mail->debugSend(1) to get output on a frontend testpage. The output is PRE formatted and contains the areas: SETTINGS, RESULT, ERRORS and a complete debuglog of the server connection, like this one: Following are a ... List of all options and features testConnection () - returns true on success, false on failures sendSingle ( true | false ) - default is false sendBulk ( true | false ) - default is false, Set this to true if you have lots of recipients (50+) to ($recipients) - one emailaddress or array with multiple emailaddresses cc ($recipients) - only available with mode sendSingle, one emailaddress or array with multiple emailaddresses bcc ($recipients) - one emailaddress or array with multiple emailaddresses from = 'person@example.com' - emailaddress, can be set in module config (called Sender Emailaddress) but it can be overwritten here fromName = 'Name Surname' - optional, can be set in module config (called Sender Name) but it can be overwritten here priority (3) - 1 = Highest | 2 = High | 3 = Normal | 4 = Low | 5 = Lowest dispositionNotification () or notification () - request a Disposition Notification subject ($subject) - subject of the message body ($textBody) - use this one alone to create and send plainText emailmessages bodyHTML ($htmlBody) - use this to create a Multipart Alternative Emailmessage (containing a HTML-Part and a Plaintext-Part as fallback) addSignature ( true | false ) - the default-behave is selectable in config screen, this can be overridden here (only available if a signature is defined in the config screen) attachment ($filename, $alternativeBasename = "") - add attachment file, optionally alternative basename send () - send the message(s) and return number of successful sent messages debugSend(1) - returns and / or outputs a (pre formatted) dump that contains the areas: SETTINGS, RESULT, ERRORS and a complete debuglog of the server connection. (See above the example code under ADVANCED DEBUG METHOD for further instructions!) getResult () - returns a dump (array) with all recipients (to, cc, bcc) and settings you have selected with the message, the message subject and body, and lists of successfull addresses and failed addresses, logActivity ($logmessage) - you may log success if you want logError ($logmessage) - you may log warnings, too. - Errors are logged automaticaly useSentLog (true | false) - intended for usage with e.g. third party newsletter modules - tells the send() method to make usage of the sentLog-methods - the following three sentLog methods are hookable, e.g. if you don't want log into files you may provide your own storage, or add additional functionality here sentLogReset () - starts a new LogSession - Best usage would be interactively once when setting up a new Newsletter sentLogGet () - is called automaticly within the send() method - returns an array containing all previously used emailaddresses sentLogAdd ($emailaddress) - is called automaticly within the send() method Changelog: https://github.com/horst-n/WireMailSmtp/blob/master/CHANGELOG.md

I've created a new Textformatter in the last couple of days: TextformatterSrcset will add a srcset attribute to all your images inside a Textarea. Depending on your configuration, it will create all sizes for the images, make a double-sized one for HiDPI/Retina devices and you can even create a low-quality placeholder. Read more at Github and make sure that you read the examples. It was build to work perfect with the two scripts from Alexander Farkas, respimage and Lazysizes. Do yourself a favor and try them out. They don't require jQuery, they have wonderful fallback and are fast and easy to use. More information and downloads on our Github repo. This module is currently quite stable and tested against multiple configuration variations. It works Some code improvements are needed, so use with care. Feel free to ask any questions you might have.

See them as "not" fields but a system property that is consistent with when a user edited or created a page that never changes. Don't try to use this as the article created or modified, instead I advise to use custom datetime fields. This makes sure you get a "real" creation and modified date you can rely on for maintenance or rechecking what happened when and so on. Many times this can be good to have. Adding custom date fields for the editor is then only used for output.

@onjegolders, thanks for starting this topic. I've been working a lot on my email thingy, it has ballooned into a fledgling CRM now, and can do all kinds of neat tricks.. lately i have been implementing HTML templates, and i'm trying to keep it dead-simple; this is still sort of a WIP, but in short: the template (email-template) has fields: title body, ckeditor - specially configured to accept almost all markup; body_atts (for example [bgcolor=#161616" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0]) images custom_css (for example [a:link {color: #61c7dd;}a:hover {color: #59b8cc;}] ) // If using a template, if($message->template_select) { $bodyatts = $message->template_select->body_atts ? ' ' . $message->template_select->body_atts : ''; $body = " <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN' 'http://www.w3.org/TR/html4/strict.dtd'> <html lang='en'> <head> <title>{$message->title}</title> <meta content='text/html; charset=utf-8' http-equiv='Content-Type'> <style type='text/css'>{$message->custom_css}</style> </head> <body$bodyatts> "; $body .= $message->body; $body .= "</body> </html>"; $body = str_replace('/site/assets/files/', $base_url . '/site/assets/files/', $body); $mail->bodyHTML($body); } now i'm thinking of making it more flexible and having a field for the head since some of the templates i have tried to use more recently needed different head markup... how this works is that when you crate a new message, my system clones all of the fields from the template into the new message and then you edit from that clone; so there is a module running on save of the email that checks to see if a template is selected and then replaces the body of the current email you are editing (and the other fields) from the template, but leaves the image references in tact, so that the images used in an html template are still stored with the template, but the body, css, and body_atts can be adjusted if necessary on a per-email level..

maybe not exactly what you are asking for, but related: https://processwire.com/talk/topic/5704-module-wiremailsmtp/page-2#entry68098 (a description from macrura how he uses an own mailsystem, - this post and the few next, with code examples)

For some strange reason I believe I kept copying the old version of pw. Now it works. Thanks

Using pages to build the letter, parent renders all the children's markup. - parent (page in the page tree, this is the newsletter) this markup is used for the news letter. - header (contains markup from header) - article (contains markup from image text header link etc.) - article etc.. - image - article - footer

Yes, I do this every time I deliver a new site. I record a few very short screen casts explaining how to accomplish specific tasks. I publish it via Google Sites and keep it online for their reference "forever". Thus, I don't have to do time consuming trainings and they can repeat as often as they want. Unfortunately all this tutorials are confidential as they refer to the clients admin, can't show it here.

Well, one of the main things that attracted me to Processwire in the first place was how to sell the backend admin to clients. I have explored several CMS platforms over the years but I have always focused on how smooth and workable the system would be for the end site owners. PW delivers in this regard...

I don't get to London often, but I suspect next time I do I am going to be walking around constantly thinking that I am being followed by the Finnish contingent. Mind you, it wont be the first time. Many joyous hours spent with this chappy back in the late 80s: http://en.wikipedia.org/wiki/Erkki_Toivanen Well, since I am single these days, if you all invade, I am happy to show you around the bars sights - as long as someone volunteers to carry my liver.....

Yeah, when is that? *prods ryan* We've already done the "if you build it, they will come" part - just needs everyone driving to a cornfield in the middle of nowhere now doesn't it? Preferably with good eateries.

When we have first international pw meetup, I reserve my seat next to Joss.

@lisandi: I truly appreciate your enthusiasm, but clearly you and I see many things -- including what "success" really means, what ProcessWire should become, and what we'd like to do in the future -- in a very different way. Considering that, you may take my comments here with a grain of salt In a nutshell, I believe that there's a market for systems that do things differently, they don't all have to be WordPress clones, and they don't all have to do whatever it takes to become popular. In fact, I believe that trying to copy what others have done and doing what everyone is expecting -- and not thinking for yourself -- is what leads to "digging your own grave" in the long run. I don't want ProcessWire to ever become "the most popular system out there", even if it would mean "lots of jobs", if in the process it has to turn into something I can no longer respect and enjoy. I'm here exactly because I believe in what ProcessWire stands for. It's that simple, really. Those things aside, I think you've made some valid points, and we all have something to learn here. Out of interest (and assuming that I'm reading you correctly) you mentioned finding some interesting modules that aren't in our modules directory yet.. would you care to mention what and where?

So sad to hear you've only read a third of my ramblings

ProcessWire IS successful. I've not read all but think it's all kinda way off to what PW is in its philosophy and core. Sorry, but I usually am too lazy to read more than 2-3 paragraphs. You need to work on your end-user usability (me reading your post, or not).

ProcessWire (PW) is a very flexible and accommodating system. You can basically add any Front-end framework and with a little work, integrate it with PW. For me, there are no usability issues where the PW core is concerned. It does what it needs to do and if I feel it doesn't, I can easily find a solution that can be added to whatever project I'm working on. The forum is very open and accessible to anyone. People are very helpful and give of themselves. The functionality and usability that some want can indeed be added to PW. That's the great thing about PW, it's very extensible. What I don't understand is that there is nothing that is keeping others from adding these features. I, as an user will buy, support or make use of these enhanced capabilities whenever they are created/contributed. I also enjoy hearing about new use cases for PW, however I greatly hope that the core of PW remains lean, mean and powerful. I look forward to reading about how others are contributing to the PW ecosystem by adding capabilities that are not in the core. I personally believe Ryan or the core team are not responsible and have no responsibility for adding a bunch of kitchen sink features.

Now after working quite a while with it, the only thing what is bother me a bit is that when I hide the left menubar by clciking the hamburger-icon and save a page, it is visible again. It should remember the last state and only should change back when clicking again the hamburger icon. Otherwise really love and use many of the features!

(For some reason I thought I'd clicked post on this at lunchtime but it's been sitting in my browser waiting for me and I nearly lost it all - it should go before dazzyweb's post in the order of things, but that post serves to confirm that everyone has their own opinions and that we're not all clones ). - - - - - - - - - - - - I've only skim-read bits of this topic because I disagree with much of what you have said lisandi (everyone will have slightly different opinions of course ), but I think maybe reading the other threads on comparing PW to WP/Joomla/etc will help understand why you may be getting replies that confuse you. This one especially where from start to end where some people share your views to some degree, but specifically the post from ryan that I linked directly to: https://processwire.com/talk/topic/7565-making-pw-more-userfriendly/?p=73748 I don't think anyone's being obstinate in not wanting to change interfaces drastically, but the very short version of the counter-argument to your points is that not all CMS' have the same audience a more user-friendly interface is subjective (that thread above proves that) and the end user in theory should just be managing content, not modules/plugins/themes if the person/company who installed the CMS has done their job properly but of course it depends what kind of site you are building and who it's for Whilst nobody is ignoring these conversations completely, being the "zillionth-and-one" person to post a lot of the same stuff suggests having not read the other topics, and perhaps asking for change that simply isn't happening for good reasons as mentioned in one of those topics. If you understand ProcessWire and the infinite number of directions the front-end can go in whilst it doesn't make any assumptions out of the box, you will see that you simply cannot have one-click installs for frontend modules that will work with a theming system, or a library of themes that could even work from one site to the next. That said, it is relatively simple to convert any HTML template to ProcessWire if you are willing to learn (and there is an element of learning in any system). There is nothing about this that will spell the doom for ProcessWire that you keep mentioning and that is the part I disagree most strongly with. There has been rapid growth here these past few years and many success stories that prove your statements about digging ProcessWire's grave wrong. The majority of us (and those countless others who don't participate on the forums) are making a decent living using ProcessWire in some way to make that happen. There is no desire from the majority for ProcessWire to be the "one-click-install king" and rightly so - it is a more flexible system than the others the way it is and, if used correctly, can help you build bespoke websites without limitations quicker than other systems with interfaces that are easier for customers to use (you can build some really intuitive admin template layouts with just a few minutes' work and I would be happy to share in another thread if I get time). That's not to say that the blog module and others aren't worthwhile efforts. They do add a level of accessibility that you are talking about, however it is not the primary focus of the project and the project will not fade into obscurity by staying true to its current path - to suggest that is silly. On the other hand, it is silly for you to mention we should start digging ProcessWire's grave and equally silly for me to say otherwise. In ten years' time will anyone be using Facebook or Wordpress any more? Will "normal" websites still be a relevant marketing platform or will everything be mobile or displayed on a watch? Who knows - the point is that technology moves on and ProcessWire is a very modern bit of kit that is not trying to be like other systems based on older ways of thinking and legacy code. Will this mean that less techy people will use one of those other systems for a simple blog? Sure, it almost certainly will, but if you want a blog and lots of themes then use Wordpress - we're all for people using the right tool for the job and it won't always be ProcessWire (but for us, most of the time, of the time it is ). ProcessWire will do just fine continuing down the path it is on. User feedback is welcome (I'm just the forum admin by the way, so I'm speaking for myself and not the wider project) but no project will incorporate every suggestion, no matter how often some may arise, if it doesn't fit with the goal of the project or its intended audience - in this caseit is those people willing to learn a little more than in other systems if they want to build a site for themselves. The audiences are a little different - call it "the thinking person's CMS with endless possibilities" if you like, and assuming that's not too offensive a tagline

Using wireSendFile() for flexible download is great to mask the real file location on the server or to select the file according to the language, but it comes with an issue that appears for large files or slow connections: until the download completes, any other access to the website from the same session is blocked. For a user viewing a page that contains such a download link, this means that when he clicks on the download link, the download starts as expected, but until the download completes, the user can not navigate to a different page of the site, which is probably not the expected behavior. The solution to avoid this issue is to call session_write_close() before wireSendFile(), like this: $options = array( // boolean: halt program execution after file send 'exit' => true, // boolean|null: whether file should force download (null=let content-type header decide) 'forceDownload' => true, // string: filename you want the download to show on the user's computer, or blank to use existing. 'downloadFilename' => $clientFilename, ); // Close the php session, so wireSendFile doesn't block other connections from the same session while downloading session_write_close(); wireSendFile($serverFilePath, $options); This should not have any unwanted effect as long as the 'exit' option is set to true (because wireSendFile() calls exit() just after readfile() in this case). Note: The issue comes from PHP's session management, where "session data is locked to prevent concurrent writes only one script may operate on a session at any time" (as says PHP session_write_close documentation ). A google search "php readfile session_write_close" brings many exemple of this lock problem.

BTW, I see you've used FontawesomePageLabel, that module isn't continued any more. It's now 'continued' as jQuery Plug-in included as example in AdminCustomFiles.

Great idea, and I've got nothing against such a discussion -- in fact I'd love to see more of it. Still, a few comments on the specific points you've raised here: Our customers (i.e. end-users) have had very few issues with ProcessWire. In fact, ProcessWire is just about as easy-to-use as you can get. I've said before that as long as one knows how to fill in a web form, one has what it takes to update a ProcessWire site. Sure, improvements can and should be made when possible (and by no means do I want to stand in the way of any discussions about this), but to say that "ProcessWire is built with focus mainly on developers" is simply not true. On the other hand, I'm wondering if you consider installing modules something a person with "no programming knowledge" should be able to do? Part of your message seems to point to that direction, but please correct me if I'm misinterpreting you here. If that's the case, I'm not sure that I can agree -- modules that do things out of the box are a tiny fragment of all modules available from modules directory. Personally I don't consider that an important aspect, considering that we really don't want to be "the next WordPress" (or any other system that is based on the idea of building sites via stitching barely compatible collection of pre-built pieces together). Sorry, but no -- this wouldn't be great. Quite the opposite, really The whole point of the official list is to keep track of the quality of modules. I know there are modules out there that just haven't been added to the directory yet (and perhaps should), but in those cases the right path to take would be suggesting to the author that they submit their module to the directory. If they're not around to do that, that's a good reason to avoid the module altogether, as it's obviously not well maintained. Note: your idea of donation / sponsor button isn't bad, though. Not sure if that's easily doable (I'm really not familiar with such services and the way they work), but at least an option to add something like that would be nice. You can achieve this by creating new pages into Admin and moving pages related to installed Process modules under those, it's your call. Well-built Process modules won't assume that they're always installed in one location either, so moving them to another section shouldn't be a problem. .. although you're probably thinking of something larger here, and in that case, please do elaborate this further

Please note that the Foundation 5 profile is rather out of date! I haven't updated it because to be honest, it is as easy for you to install what ever framework you need. See the tutorial here: http://processwire.com/docs/tutorials/installing-a-css-framework/

Some ideas I recently had to make it even better: Resort the icons and searchbar at the top right corner: (P.S.: In this case you would have to add a border at search suggestions right side, too) Select menu for "Pages" in configuration (Tree, Lister, Both (dropdown)) I never use "Lister" so it would be much better for at least me if I could choose that pages directly takes me to page tree. Don't need a accordion here. But maybe other people. So a config option would be the best, I guess.

Glad you figured it out. Unfortunately $_SERVER['SERVER_NAME'] can't always be relied upon because some cases have it populated with something other than the hostname of the current site (like the hostname of the server itself rather than the site). Though you also can't rely on $_SERVER['HTTP_HOST'] either, as that can be manipulated by the request. If you need the capability to automatically switching DB configs depending on dev or live, your best bet is probably to copy your /site/config.php to /site/config-dev.php and only keep that file in your dev environment. Your /site/config.php will be ignored when /site/config-dev.php is present, enabling you to accomplish the same thing you are now, so long as you don't upload config-dev.php to your live site.

HOLY SMOKES I FIXED IT!!!!!!!!!! For the longest time I have used the following setup $base_url = $_SERVER['SERVER_NAME']; switch ($base_url) { // LOCAL CONFIG case "mywebsite.dev": $config->dbHost = 'localhost'; $config->dbName = 'database'; $config->dbUser = 'user'; $config->dbPass = 'pAsSwOrD'; $config->dbPort = '3306'; $config->debug = true; $config->httpHosts = array('mywebsite.dev', 'www.mywebsite.dev'); break; // LIVE CONFIG case "mywebsite.com": $config->dbHost = 'localhost'; $config->dbName = 'database'; $config->dbUser = 'user'; $config->dbPass = 'PaSsWoRd'; $config->dbPort = '3306'; $config->debug = false; $config->httpHosts = array('mywebsite.com', 'www.mywebsite.com'); break; } I guess now that no longer works. @Ryan At your mention above about config-dev.php, I decided to remove my switch statements from the config.php file and it works fine. GEEZZZ MAANNN it's always the simplest answer, isn't it?

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

You can assign language-specific labels or descriptions to fields by setting either $field->label or $field->description with the language ID appended to it. Since the string value of a $language is its ID, this you can just do it like this: $es = $languages->get('es'); $fr = $languages->get('fr'); $field->set("label$es", "Spanish Label"); $field->set("description$es", "Spanish Description"); $field->set("label$fr", "French Label"); $field->set("description$fr", "French Description"); The above is resolving to something like this (where 123 is the ID of Spanish and 456 is the ID of French): $field->label123 = "Spanish Label"; $field->description123 = "Spanish Description"; $field->label456 = "French Label"; $field->description456 = "French Description"; When setting for the 'default' language, make sure you are setting just "label" and "description" without anything appended. For instance, this won't work: $en = $languages->get("default"); $field->set("label$en", "English Label"); // this is incorrect because default language has no ID appended $field->set("label", "English Label"); // this is correct $field->label = "English Label"; // this is also correct

It's hidden in the admin interface unless you've got advanced mode on. I've tried to keep the admin as simple as possible so that people can think of templates and fieldgroups as one in the same thing. But the reality is that they are actually separate things. The benefit of having them separate is that you can have multiple templates sharing the same group of fields. But currently we're not highlighting that behavior on the admin side just because I think there is more benefit to the clarity of templates just being a single thing. i had always thought we'd expand on the behavior on the admin side in giving people more options, but the need seems rare enough that it's stayed in advanced mode for now. Probably what I will end up doing is making the API itself abstract the behavior too, so that it adds a like-named Fieldgroup automatically when you access $template->fields and one isn't already there.

See the cheatsheet documentation at http://cheatsheet.processwire.com/ and click the "advanced" button, then click "WireArray/PageArray". All the methods for WireArray are at your disposal for this. Specifically the section on "Setting/Modifying Items" is probably the most helpful. A WireArray only carries one of each item, so if you add/insert/etc. an item that's already present, it'll move it in the array rather than add another copy.

Ryan, Thanks this gave me a great place to start. I thought I'd share the version I created in case anyone finds it useful. • Single template for the login/logout. • Automatically redirects the user back to whatever page they originally requested after they login. ./includes/login.php <?php // Handle logouts if($input->get->logout == 1) { $session->logout(); $session->redirect($page->path); } // If they aren't logged in, then show the login form if(!$user->isLoggedin()){ // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect($page->path); } else { $session->login_error = 'Login Failed. Please try again, or use the forgot password link below.'; } } ?> <!DOCTYPE HTML> <html lang="en"> <head> <title>Custom PW Login</title> </head> <body> <form action='./' method='post'> <div class="login"> <? if($input->post->user && $input->post->pass) { echo "<p class='error'>" . $session->login_error . "</p>"; }?> <p><input type='text' id="user" name='user' placeholder='Username'/></p> <p><input type='password' id="pass" name='pass' placeholder="Password" /></p> <p><input type='submit' class="btn" name='submit' value='Login' /></p> </div> </form> </body> </html> <? die(); // don't go any further if not logged in } // end !logged in ?> In any template you wish to protect: <? require("./includes/login.php");?> To trigger a logout: <a href="?logout=1">Logout</a> Note: I'm using the HTML5 placeholder attribute. Browser support is not 100%. You may want to use labels instead, or use some jQuery (like I did) to add the placeholder text for browser that don't support it. SideNote: How do you get code indents to stick when posting? I'm having to go back and add spaces to each line. I use tabs when coding.

This is the way to create template and fields with API: // new fieldgroup $fg = new Fieldgroup(); $fg->name = 'new-template'; $fg->add($this->fields->get('title')); // needed title field $fg->save(); // new template using the fieldgroup $t = new Template(); $t->name = 'new-template'; $t->fieldgroup = $fg; // add the fieldgroup $t->noChildren = 1; $t->save(); // add one more field, attributes depending on fieldtype $f = new Field(); // create new field object $f->type = $this->modules->get("FieldtypeFloat"); // get a field type $f->name = 'price'; $f->precision = 2; $f->label = 'Price of the product'; $f->save(); // save the field $fg->add($f); // add field to fieldgroup $fg->save(); // save fieldgroup All pretty much standard OO one can figure out looking at core and PW modules. But not someone unexperienced would figure out by themself. I think at some point we need to cover these in a documentation.