teppo

In function scope you'll have to use wire('page') or $wire->page instead of $page.

Thanks guys, that was a lot of fun! I hope we can make this a habit.. and Antti, don't forget that tournament we talked about

Bash, mostly Kongondo explained the main reasons already and the rest was pretty much summed up by Paul M. Jones in his 2008 blog post titled "Another Smarty Emigrant": To be fair templating engines do have valid use cases, but those are almost entirely related to keeping things secure if you need to allow external or otherwise untrusted users (however limited) access to your codebase.

Nothing wrong with asking, but the scope of your question here makes it difficult to answer in sensible timeframe. There's also a lot of valuable content floating around here that already answers different parts of your question, but I'm assuming you've browsed through those, considering that you even started a thread about that. Something you said in that thread made me cringe a bit, though: "I need to chat less and read more". As I've been repeatedly told, we all learn in different ways, but IMHO you need to read less and do more. As they say, "the best way to improve at building software is to build software", and that applies to sites too. Build a couple of sites of your own and you'll have a lot better idea about what works for you.. and what doesn't. Nevertheless, this is an interesting subject, so I'll start by trying to answer your questions briefly based on my typical process: I don't "create a database and install PW", I've got a script for that. Repetitive tasks are boring and automating them is fun. I use a previously created site as my starting point. This base site includes common templates, template files organised exactly as I like (something derived from Zend Framework file structure and an implementation of the front controller pattern), various include files (functions.php with common and usually render-related functions etc.) and modules I often end up installing. I don't know what a "base template code system" is, but if you're talking about template engines (Twig, Smarty etc.) the answer is "never". Those things are are horrible and wrong. If you're referring to something like partials (as in "not full template files but files you'll include within your template files") and helper functions, then yes -- both are useful in their own ways. The projects we've built before are my "code clip folder". I could go on and on about this and probably will at some point post something about the directory structure, template logic etc. but don't really have time for that now. If you'd like to know something more specific, please don't hesitate to ask. You'll definitely get more (and more helpful) answers if you limit the scope of your questions a bit.. though don't be offended if people point you to existing threads either, as that's just the way things work around here. In some ways this forum serves as our collective data bank and the more discussions about same subject are grouped together the easier it is to dig into that subject later

Values for page type fields that store multiple values are PageArrays. Since PageArray extends WireArray, you can use it's methods here -- such as removeAll(). Running $page->countries->removeAll() before adding new items should do the trick. It'll clear the PageArray and you can start from clean slate, so to speak. You should also take a look at other WireArray and PageArray methods, as those provide some nice ways to manage stored items etc.

Begging, you say? Seriously speaking, agreed. This is why I prefer selling apparel etc. over simply asking for money. $100 for a printed photo of Richard Stallman, even if it's autographed, is a bit much, but people still buy those to support a cause. Too bad someone already invented skyscraper plushies..

According to Inputfield.php, collapsedLocked should be exactly what you're looking for: visible, but not editable. Is the description there outdated or am I missing something here? Edit: right, "otherwise same as collapsedYes".. that's a bummer. Sorry, can't see an obvious way to do this without some custom hooks right now.

First of all, I'll assume that you've read enough to know that there are more than a few gotchas to be taken into consideration. The tricky part, IMHO, isn't implementing this for ProcessWire -- getting it right and making it secure is way more complicated. Once you got that figured out, you could set the token or whatever method you're using right after successful Session::login. Other part, logging the user in, depends on how and where you prefer this to happen. ProcessLogin::execute is one option you might want to consider. Hope that helps a bit.

I don't see a problem with commercial modules. In fact, if that little extra cash allows the developers to spend more time working on them and publishing higher quality stuff others can buy (for a reasonable price) and use in their projects, everyone benefits That being said, high quality free modules (or commercial ones made available with a PWYW model) are still more than welcome and (IMHO) have a very important role in the future of this project. Personally I'd like to see that "donate now" button one day too.. and definitely some non-software products (clothing, mugs, pins etc.) When it comes to raising funds, FSF is a model example of doing it right.

Based on the screenshot menu_item is definitely a page field. $pages->find() gives you an instance of PageArray and like @diogo already mentioned, you can't ask field "menu_item" of that PageArray -- it contains multiple Page items and doesn't have any fields of it's own. You'll have to first get individual Pages out of that PageArray: // this gives you first Page object found with your selector; if you're sure // that there's never going to be more than one Page, this should be fine $items = $pages->find('template=menu, title=Toolbar Menu, include=all'); foreach ($items->first()->menu_item as $item) { ... } // another thing you can do to get only the first result is use 'get' instead of 'find' $items = $pages->get('template=menu, title=Toolbar Menu, include=all'); foreach ($items->menu_item as $item) { ... } // if there's a possibility of multiple 'menu' pages, you need to use another foreach $items = $pages->find('template=menu, title=Toolbar Menu, include=all'); foreach ($items as $menu_page) { foreach ($menu_page->menu_item as $item) { ... } } Got it?

@renobird: sounds awesome -- hope you'll find the time to do that. Shibboleth has come up a few times in the past and I'm sure a module integrating with it would be good thing to have @Pete: cool.. I'm starting to like ADLDAP too, looks like it makes a lot of things possible and the API isn't too bad either.

Call me overly cautious, but I'd advice against self-managed VPS if this service needs to be highly secure and especially if you need a high level of availability. Anyone can manage a server when things go smooth -- install updates, add a few rules to a firewall and tweak Apache/PHP/MySQL settings. The real question is how well can you handle things going wrong; someone attacking your server, hardware or software failures (hardware issues are still very real even in this age of cloud computing, I'm afraid), restoring corrupted data etc. What about availability requirements -- do you need high availability and 24/7/365 support.. and if, can you really provide and guarantee that? A lot of time I'd recommend going with managed solution in one form or another rather than trying to do everything yourself. It depends a lot on the requirements and the nature of the service you're running, but the bottom line here is that unless you can guarantee that you're able to handle everything yourself, don't make any promises to the client you'll end up regretting.

Two thoughts: writing something like that is simply awesome and an exceptional example of the kind of things devoted community (and a devoted member of that community) can do for an open source project.. yet at the same time the idea that one would need to read a book in order to create menus sounds kind of scary Of course I've no idea of the actual context here, what this Wayfinder is etc. so I guess it has to be about a lot more than just adding some navigational elements. It has to be, right?

Same story here; I know just enough work with it. Never written any code that would've connected with AD either, mostly just used an in-house integration and query tool We've got a bunch of clients that use AD actively and based on that experience I'd say that a "proper" integration module wouldn't really have to do that much. Authentication, creating local users for AD ones (depends a bit on the use case whether that's actually desired, though) and finally a flexible way to connect users with roles (and possibly even custom entities, such as groups, if something like UserGroups is in use) based on OU's and/or groups would make it very useful already. Based on my (admittedly rather limited) experience usernames very rarely change -- can't remember a single case where this would've happened and caused problems -- and even if they do, it should always be possible to re-create (or rename) an old user account. I guess a changed username could cause quite a few other side-effects too, which might explain why admins seem to be rather reluctant to change these On the other hand, according to this SO thread and some MS resources, there are actually multiple unique identifiers for users, so perhaps one of those could be used instead if usernames seem too risky?

I feel like that all the time.. Seriously speaking, what I've been missing most is automated checking, logging and reporting for broken links. This is partially solved by Page Link Abstractor, but I don't really like it's approach that much.. and it only works for local links. Manually running something like the W3C link checker helps a bit, but doesn't really solve the issue yet. Another thing I'd love to see is proper Active Directory / LDAP integration. At least around here that's pretty much a requirement in order to build intranets etc. for larger organisations, as they all seem to use AD for managing their local users. I know that there's some code floating around for this and Antti has apparently already used it in at least one project, but last time I checked it didn't really look like a finished product -- more like something that could probably be used to build on. That's all I can think of right now.

There's an issue with your proposed approach; namely the way isLoggedin() works. As you can see, it only checks if this user is guest, i.e. if it's ID matches that of the guest user. It's going to return true for any user you've fetched with $users->get(). Putting that aside for a moment, there's an even bigger issue here. If I'm getting this right, you're logging user in, and later trying to check if that specific user (123) is logged in when anyone opens URL like http://example.com/user/123. Isn't that a huge security issue right there? How would you validate that the user opening this URL is the same one that earlier authenticated using correct credentials? I really wouldn't recommend pursuing this. There are going to be severe security implications no matter how you approach it. .. but if you really have to, I'd consider some sort of token-based authentication method. When the user logs in, provide an URL she can visit to log in. Typically that URL would be invalidated after single login (and after certain period of time) to make it slightly more secure. Automatically generating something like this would still be very risky (please don't do it). It's more often used in combination with, say, valid email: user types in her email and receives an URL that's valid for certain period of time and allows her to login (preferably once) before it's invalidated.

What @clsource said. This definitely isn't typical AJAX behaviour. Something you're doing is very resource intensive; most likely retrieving or rendering pages -- though that's also all we know about your use case, so there could be something else involved we just don't know about. Agreed about the headers, too: by default POST requests are not cacheable, unless specifically forced using Cache-Control and Expires headers. You don't need to define any of those headers here unless you're somehow forcing caching for POST requests (although if you're just fetching records, not altering them, I'm equally confused about the use of POST here in the first place).

Thanks for mentioning this, Soma. Looks like I'll have to take a closer look at the new format.