ryan

If I'm reading it right, it seems to meet both criterion A and B. It is currently required by the system for "transmission of communication". And it is "strictly necessary" in order for the system to function. If I can find a way to make it optional, I will. But for the time being, it is required by the system.

On a file system, you can't have two of the same filename in the same directory. Filenames as keys ensure that same remains true in memory.

Based on the time of your post, I'm guessing you might have hit it when I was pushing updates (at exactly 6 am yesterday). I managed to break it for about 5-10 minutes before realizing it. Let me know if it still doesn't work for you. @nico I'd love to have a look. I need to setup something similar (outlining a route on a gmap) for another project.

I don't often use that syntax, but if trying to make something consume as few characters as possible, it works.

Actually in this case /cities/ is not just about admin organization, it's an important landing page in the site's navigation and breadcrumb trail: http://processwire.com/skyscrapers/cities/ In ProcessWire we really try to push that URLs are structure and should represent actual structure. What makes sense for the site's structure also makes sense for the URLs, because they are one in the same. If there's a strong desire to have actual city pages off the root level, then you can create them off the root level. While I would question whether that's really the best strategy for either side, there's nothing stopping you from doing it. You can always take the URL segments route too, but when URL segments are used as beginning points (foundations of structure) rather than ending points, you always have to question whether it's really what is best for structure and URLs, or whether it's giving preference to short-term style over proper structure.

Never underestimate the importance of word separation. It's the difference in readability between "pen-is-broken" and "penisbroken". Beyond the potential misunderstandings is raw readability both to users and search engines. While I have a readability preference for underscores, my understanding is that hyphens are the best balance when all factors are taken into consideration. Lastly, this may be obvious, but what gets populated in that name box is only an auto-generated suggestion. After populating the title, one can go modify the name as they see fit (which I often do), before saving the page.

I agree with AnotherAndrew. The indicated error line is the mysqli_connect function, which means it attempted to connect to the MySQL server and was denied. I don't see how the scope of this could go beyond your web host and their MySQL server. If it's only occurring to certain people, chances are they are seeing an error message that was cached somehow or another (perhaps via a proxy). I wouldn't look past the web host, the problem has got to be there.

Tina your example also has an extra '$' before the session variable: $this->$session->redirect($pages->get(1)->url); that should be: $this->session->redirect($this->pages->get(1)->url); Make sure that you've got $config->debug=true; in your /site/config.php during development so that you get more verbose error messages, which should highlight these things rather than giving you a 500 error. I also recommend replacing your "init()" method with "ready()". Technically either should work here, but since $page isn't yet available at init() time, anything that inquires $page would be non-functional. There doesn't appear to be anything here that needs $page, but since you are making a $pages call, I think it's just a little safer to use ready() rather than init(). Note however that you'll want to keep the init() method around, since it is required. But just leave the implementation for it blank, while moving your code to a ready() method. Lastly, since this has to do with front-end, you might just want to make your own login form for the front-end. PW's login form is for login to the admin, but it wasn't intended to be used as a front-end login form (even if you can technically do it). You may find it a lot simpler and more flexible just to have a separate form for your front-end login: Here's a couple examples: http://processwire.com/talk/topic/2937-creating-a-front-end-admin/?p=28954 http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=15919

Template permissions can be inherited to other pages via their template, whereas family settings can't. So there can be a situation where you are dealing with a template that already has children, you change it to "no" to prevent further children, but existing children using inherited permissions should still have the "add children" permission.

I don't think that particular setting requires advanced mode? It is on the 'advanced' tab of the Template editor though. But that tab is unrelated to $config->advanced (despite the name). Regarding advanced mode: I never use it, except when developing ProcessWire itself. I recommend people stay out of advanced mode unless temporarily needing to access some specific setting. The need for advanced mode never comes up in my own sites, at least. It can be dangerous to leave it on, just because some of the things you can "enable" (like 'system' status) are not easily reversible.

That's correct. But it also allows it to be changed in the page editor. Here is the description field that goes along with it: "When checked, pages using this template will have an option to change the 'created by user' (for superusers only). It will also enable the $page->createdUser or $page->created_users_id fields to be saved via the API." Note that in order to access this setting, $config->advanced=true; has to be set in /site/config.php

It looks good to me. I would probably compare the $user's id rather than name, but I don't think it matters here.

I tried to reproduce that here, but it seems to be returning the expected result for me: $items = $pages->find("title|body|parent.title%=France"); Here's the results I got. The "title" matches the first item, and "parent.title" matches the rest of the items (which don't include "France" in any of their fields). They all have a blank 'body' field. /regions/europe/france/ /regions/europe/france/arles/ /regions/europe/france/avignon/ /regions/europe/france/beaune/ /regions/europe/france/blaye/ /regions/europe/france/bordeaux/ /regions/europe/france/cadillac/ /regions/europe/france/chalon/ /regions/europe/france/conflans/ /regions/europe/france/giverny/ /regions/europe/france/les-andelys/ /regions/europe/france/lyon/ /regions/europe/france/normandy-beaches/ /regions/europe/france/paris/ /regions/europe/france/pauillac/ /regions/europe/france/rouen/ /regions/europe/france/saint-emilion/ /regions/europe/france/strasbourg/ /regions/europe/france/tournon/ /regions/europe/france/vernon/ /regions/europe/france/vienne/ /regions/europe/france/viviers/

The skyscrapers profile is available for download so you can see how it's put together. But for the most part, you would build these things the same way as if ProcessWire wasn't there. Then once working, take advantage of the fact that you can pull the data to populate these things from PW. This is not something PW will do on the front-end for you, since it's not generating markup. But this is something you can do very easily on your own… again set it up as if PW wasn't there, then modify it to pull the data to populate from PW. While we're probably not big enough to be a target, I feel good about the security of the core product and have always made security the first priority in development. But security is a factor that goes well beyond the core product. First, PW will only be as secure as the modules you have installed to it. I do my best to keep up-to-date with modules that go into the directory and notify the author if I find any potential security issues. However, this isn't guaranteed as I can't always keep up with everything. Secondly, PW is about as secure as PHP. Meaning, it can be very secure, or not secure at all, depending on how you code your own templates and use PHP. So if you get into handling user input, as you would with processing forms, search engines, etc., then you yourself have to follow PHP best practices towards maintaining good security. ProcessWire does provide several helper functions via the $sanitizer API variable, and I recommend using them when handling user input.

Templates are the recommend way to manage access. While you can accomplish almost anything with this access control, sometimes you can find a more specific way better for your own needs by using PW's access control hooks. The most common being: Page::editable and Page::viewable. However, if you really are talking about only 4 section pages, I would save yourself the trouble and use the built-in recommend method with access control templates. Locking the section pages for edits (like Soma mentioned) is also a good way to keep them from modifying them outside of template access control. If the user doesn't have page-lock permission, then they won't be able to unlock the locked pages. If you ultimately decide you want the fine-grained control of access control hooks, let us know and we can post an example or two to get you started.

I don't think we can do that because a parse error generated as a result of wrong PHP version will occur before ProcessWire can even perform a getModuleInfo() call on it. Module info would have to be stored in a separate file in order for PW to identify and prevent that sort of thing. Even that, or PW would have to file_get_contents() the PHP file and manually parse it looking for that info (which doesn't seem worth it). Though adding support for optional external module info files is something I would like to add at some point.

I think the main value/intention of template labels is for language support. In this manner, you can have something that makes sense with the editor's language, even if different from the developers language. Most of the time, I do not use template labels, as I prefer to just have the template name. Though if I was doing a lot more multi-language sites, I would probably prefer template labels.

I'm not sure that I follow exactly what you are trying to do. But one thing to keep in mind is that a Page can literally be mapped to anything. So while your form field may involve a page selection, you could then say "this page maps to this form" and "that page maps to that form". You could even make the template for that page load a specific form. In Form Builder, you can also specify defined lists of selectable items outside of Pages. So you might just enter each of your selectable items to be the same as the name of a form.

You saw this when first starting the installer, or after completing the database config screen?

How much do you need to know about the portal.domain.com authenticated user on client1.domain.com? Do you just need to know that they are logged in, or do you need to connect them with another account on client1.domain.com? I'm just trying to better understand the extend of access control needs at client1 and whether this is a simple authenticated "yes or no", or broader in scope.

@chim77richalds do you have access to the Form Builder support board? If not, let me know your order number so I can update your access. Also, please post the exact text that you are pasting in the success box.

(Topic moved from Getting Started to Dev Talk) Looks like a good setup! I'm not totally clear about exactly what Homebrew is, but I love the name.

If you need to retrieve a bunch of pages by ID, then getById() is much better than a foreach with get() simply because getById() does its primary work with one query, whereas get() does at least one query per call. But getById is also one of those things that most people will probably never use (it's largely an internal use thing). As a result, it probably just belongs in the 'advanced' API section.

I would really avoid using the h4 title as a URL segment as it seems like a potentially very fragile solution. Page numbers would probably be a little less fragile. If the editor really can't handle repeaters, I'd suggest using <hr> (or something else nice and direct like this) as the page delimiter rather than an <h4>, and sticking to page numbers rather than URL segments.

We have always used ASCII on fields within tables that are for page names (or other names that can't ever contain anything UTF8). Though the tables themselves are always UTF8, even if an individual field within might be defined as ASCII collation. Can you see any potential problems with doing that? Maybe some MySQL version or setting doesn't like this? The "/?/" means the error occurred before PW determined what the current $page was going to be. Everything is UTF8, except for "name" fields. They certainly could be UTF8 too, but figured it would be a better practice and more efficient to enforce ASCII on a field where only ASCII characters allowed. But it sounds like maybe there are issues with doing that I'm not aware of? Though if that were the case, I would also wonder why MySQL would let you change the character set on a field-by-field basis if it wasn't okay to do. This is the first "Illegal mix of collations" error I've heard of in PW.