ryan

This is possible. Lets assume that you have already created your two roles. "News editor" has all the page editing permissions. And "Member" has only view permission (ProcessPageView). Edit your /news/ page and add the "News editor" role to it (from the page's settings tab). Edit your /members/ page and add the "Member" role to it. Make sure this page doesn't also have the "News editor" role. For users that you want to be able to edit /news/ and only view /members/, they should have both the "News editor" and "Member" role. Such users won't be able to edit the /members/ page(s) unless you've also turned on the "News editor" role for that page. That should achieve what you want. If it's not for some reason, check that you haven't assigned the "News editor" role to the homepage. Roles added at a lower branch are inherited through the site tree until cancelled at a higher branch. Assuming ProcessWire is working correctly, both the user and the page have to have the same role before the permissions from that role apply to the user. This is how it should work, but let me know if you find it isn't.

You shouldn't have to give edit access to the homepage in order to give edit access to a page below it. If you have a role that assigns edit access, remove that role from the homepage, and instead add it to the page where you want them to be able to edit. If you get an admin page without a list of all pages, then what's missing is the ProcessPageList permission. Make sure that is turned on for the role. ProcessPageList does not imply edit (ProcessPageEdit). So you want to give the ProcessPageList permission to all administrative roles. If a user doesn't have edit access to a page, they will still see it in the admin list (unless they don't have 'view' access), but they won't be able to edit it. Also wanted to mention that roles can be used in combination. You can assign as many roles to a user as you want, each with different permissions. They will only receive the permissions assigned to that role on pages that are also assigned that same role. It's powerful in that you have very fine grained control over access. But it's also complex and confusing, which is why I'm changing it.

The admin theme files are a combination of HTML/PHP, CSS, JS files and images. For the most part, it is no different from what you would create in your own site files (in /site/templates/). By default, the admin theme files are located in this directory: /wire/templates-admin/ STEP 1: To create a new admin theme, you would copy the default admin-templates directory (/wire/templates-admin/) to here: /site/templates-admin/ When ProcessWire sees /site/templates-admin/, it will use it instead of the default one. STEP 2: Now you can modify any of those files in /site/templates-admin/ and your changes should be reflected in the admin control panel. STEP 3: To distribute it to other people, you would just zip up the dir and then anyone else can unzip it to /site/templates-admin/ and have it work. I will be glad to setup a directory of admin themes on the site if anyone else decides to make one. That is all there is too it. But here are some other details and recommendations you may find helpful: MORE DETAILS: Why not just edit the files in /wire/templates-admin/ ? You certainly could do this, but you should consider everything in /wire/ specific to ProcessWire, and everything in /site/ specific to your installation. If you were to modify the files in /wire/templates-admin/, then your changes would get overwritten every time you upgraded ProcessWire. Whereas, /site/templates-admin/ is not overwritten during upgrades. What if I only want to change stylesheets and images? If you only need to change stylesheets and images, then I would recommend having your /site/templates-admin/default.php just include the one in /wire/templates-admin/, i.e. /site/templates/default.php: <?php include("/wire/templates-admin/default.php"); And likewise for any other files in there that have markup that you don't want to modify. This includes notices.inc and debug.inc. You'll also see a controller.php file there, but that is already just a placeholder so no need to make any changes to it. What are all the files in ProcessWire's admin theme and what do they do? Files you can edit: debug.inc - An HTML/PHP file that is included when $config->debug is true. It outputs general debugging information in the admin. default.php - The main HTML/PHP container template. All admin output goes through this file. notices.inc - Generates the markup for admin messages and error notices that appear at the top of the screen. scripts/ - Directory containing jQuery/javascript files. scripts/main.js - Main jQuery/javascript file that is run on all admin pages. All this does currently is setup a few minor form interactions. styles/ - Directory containing CSS files/stylesheets styles/main.css - Initial layout and styling for the admin control panel. styles/reset.css - Resets all browser styles styles/ui.css - User interface override styles. This is the last stylesheet loaded so it can more easily modify styles that came before it as needed. styles/JqueryUI/ Directory containing jQuery UI specific stylesheets and images. You can use jQuery UI's themeroller for these if you prefer. http://bit.ly/eTVbDC styles/ie.css - Styles specific to IE styles/ie7.css - Styles specific to IE7 and below. Because we don't support those, this basically just turns off IE7 support. styles/images/ - Images used by any of the above stylesheets. Files you shouldn't bother editing: controller.php - This is just a placeholder that includes a controller in /wire/core/. You should leave this file as-is. install-head.inc - These HTML files are used by the installer. You can edit them, but ProcessWire will still use the one in /wire/templates-admin/ since they are only used before installation. As a result, you can delete them from your /site/templates-admin/ if you prefer. install-foot.inc - See above. scripts/install.js - See above. styles/install.css - See above. Modifying form widgets with jQuery UI Most of the form inputs in ProcessWire are based on a jQuery UI theme. It is located in this file /wire/templates-admin/styles/JqueryUI/JqueryUI.css (and the images directory below it). Like the other CSS files, that can be edited directly. But since this was originally built using JQuery UI's Themeroller, you can continue to modify it with that if you'd prefer. Here is a link to it with ProcessWire's admin styles already pre-populated: http://bit.ly/eTVbDC Copyrights and Logo You should leave existing copyright notices, links to processwire.com and the name ProcessWire in place. You should also add a notice indicating "[Admin theme name] copyright [your name]", i.e. "Widget admin theme copyright Gonzo Deutschdeung". We also prefer that you keep a copy of the ProcessWire logo somewhere in your design, but it's up to you. A photoshop file of the logo at high resolution is attached to this message. pw2-logos.zip

The reason that's happening is due to a MySQL setting called ft_min_word_len. By default, MySQL doesn't index words less than 4 characters. This only affects partial match selector operators like *= and ~=. If you use an exact match selector like =, then that should still work regardless of how short the word is because it uses the exact index rather than the fulltext index. Below are instructions on how to change MySQL's ft_min_word_len setting so that you can use it with words as few as 2 characters. Before making these changes, it's good to know that this change affects all tables with fulltext indexes on the server (regardless of what database they are in). Such tables will need to be repaired after this change is made (to force them to rebuild their indexes). This is fairly simple if you have PHPMyAdmin, because you can just select all tables and choose "repair", without really worrying about whether it has a fulltext index or not. This is easy to do if you are running your own VPS or server, but may be challenging or impossible on a commercial web host (though some will have already done this). To make MySQL index words down to 2 characters, a change needs to be made in MySQL in this file: /etc/my.cnf (or wherever your mysql config file is located). Add the following to this file: [mysqld] ft_min_word_len=2 If [mysqld] is already there, then just add the ft_min_word_len=2 part. Following that, MySQL needs to be restarted, so that it reloads it's configuration file. Once restarted, everything should be back online, but you will want to run the table repair to force rebuild of indexes before your 2-letter words will actually work. REPAIR TABLE [table name] QUICK; In the case of ProcessWire, I would rebuild all the field_* tables. If you are using PhpMyAdmin, just repair all of ProcessWire's tables to make it easy. Choose the checkbox for "check all" at the bottom. Then select "Repair" in the select box to the right of it. Following that, you should be good to go with words down to 2 characters. If there are other (non ProcessWire) databases on the server, you may want to repair them too. If any are using fulltext indexes, those indexes will eventually get corrupted if not repaired. By corrupted, I don't mean data loss, I just mean that the index may not work properly until it's repaired. Let me know if I can be of any help.

Superuser is the only role that can actually edit the admin pages, and that is intentional, so that you can add stuff to it as it suits your needs. That part is hard coded, so it doesn't matter what permissions/roles you assign, it's not going to let any role other than superuser modify those pages or even see that they exist (unless you write something to do it from the API). So when you edit the /processwire/ (admin) page to add a role to it, all it's doing is giving them access to use the admin. It might say that they have edit access there, but in this instance they don't. There aren't any bugs that I'm aware of in the current user/roles system. Though definitely let me know if you found any? The main limitation is just that it's not yet designed for large scale use (i.e. lots of users or data attached to those users), and it's not as refined as other parts of the system in terms of description and messages. However, if you need to setup a role to provide edit access to just another part of the site, then the system should work quite well. This user system is going to be replaced in the near future by something that is built for lots of users and custom data attached to those users.

Hi Peter -- This has now been fixed and you should be able to install at Media Temple (and other servers that alias their document root) without having to do anything extra. I just spent some time on an MT gridserver account to make sure. PHP's realpath() function came to the rescue for this one.

Welcome to the ProcessWire forums! I'm not sure that I understand your question -- can you post more specifically? Also, the skyscraper profile is available for download. Send a request at http://ryancramer.com/contact/ and it'll send back a link to download the profile along with some information about it.

There won't be any limits, at least not any that aren't already present with pages. Though with 100k users... that's a lot. It will likely be a good test to help us introduce new performance optimizations and ways of filtering them. The existing user system was not designed to be scalable, as it was always seen as a temporary solution. Granted a temporary solution that suits the needs for most of the sites I work on. But it's not ideal if you have to deal with more than a couple dozen accounts. Sevarf2 - how many accounts are you dealing with now?

It looks to me like this problem is here: if($session->login($user, $pass)) { // login successful $session->redirect("/members/". $user); } That's where you should put your isSuperuser() check. if($session->login($user, $pass)) { // login successful if($user->isSuperuser()) $session->redirect("/processwire/"); else $session->redirect("/members/". $user); }

The current user system is bare. It's only designed to hold a few admin users. The new system will be designed for broader scope of course.

Since you are doing redirects, make sure that these are done before you output anything. Redirects use http headers, which have to come before any markup. Another thing to check is that there is no template caching being used. Check that in Admin > Templates > your template > Advanced, that the cache time is not set (or is 0). If neither of these are it, please post everything that comes before this snippet you pasted in your template (or just the whole template).

The passwords are double salted, meaning the "salt" column with each user in the DB has to go along with the password. In addition, the $config->userAuthSalt at the bottom of your /site/config.php has to match between the two sites you are trying to share the passwords with. For the users, you'll have to do this at the DB level rather than with the API. That's because ProcessWire randomizes the salt for that user every time you change the password. With the $config->userAuthSalt, you can just edit your site/config.php file to change that. Let me know if you need any help with either part. The point of all this is better security. But you can disable all of the salting if it suits your needs better by setting $config->userAuthHashType to null (which will force it to do nothing but md5 hash). You would need to do this before installation, or use the API to reset the passwords of an existing site, as any passwords already in the users table would already be salted and thus non-functional until changed.

If you are okay with the security implications of it (unencrypted or unhashed passwords), you could also just keep a copy of their current password in your /members/ pages and email it to them when they forget. You wouldn't want to do this on a site used for anything sensitive, but it may be fine to do for your needs.

I need to add some new forum sections here. I was just wondering what you all would suggest? I was thinking of possibly one or more of these, but would appreciate any suggestions. ProcessWire News + Announcements General Web Development Sites Running ProcessWire ProcessWire Tips and Tricks Bug Reports Site Optimization and Fine Tuning Core Development

I've been looking more and more into the multilanguage (internationalization and localization) capability here. There are two parts to it: 1. Predefined languages for the admin control panel 2. Built-in user defined multilanguage capabilities for sites Number 2 is broader in scope than 1, but it's also something that can be handled at the API level any number of ways. I know Adam and others have been doing this already. Whereas number 1 is something that can't be changed without it being built into the product itself. As a result, number 1 has the priority in the short term, and is actually the next item up on the roadmap. I haven't yet determined what approach we'll take, but am slightly leaning towards structuring it around GNU Gettext, since it's built into PHP and has a track record with other CMSs. That would make the translation process for each language roughly like that of WordPress: http://codex.wordpress.org/Translating_WordPress It would also make the module/plugin implementation of it roughly like WordPress: http://codex.wordpress.org/I18n_for_WordPress_Developers I'm curious what others experience has been with other CMSs with installing and/or translating with different languages? What solutions have you seen that you like, and what have you seen that you didn't like? Thanks, Ryan

Yes, the tags would be parsed in the same manner as ProcessWire selectors, so there would be that consistency in the API access. This is the recommended approach now, though with includes and functions. If I'm understanding you correctly, tags used as definable snippets would make that approach accessible from the tag level, which sounds great. But I see this as always being user defined as to how they want to modularize (perhaps in defining their own tags or templates), because ProcessWire intentionally not get involved in any output generation except in rare cases (like with pagination). For instance, the term "blocks" as it's used in Drupal is an approach I want to avoid because it gets the CMS mixed up into the structure of the markup. It's not necessarily a bad approach -- there are positives and negatives, depending on the intended use. But ProcessWire's concept is the opposite of Drupal's in this regard. However, I think you are using that term in a different way, just to refer to user defined blocks or areas within their template, so that's the way I read it and am agreeable to it. If I'm understanding you correctly, this is about what I had in mind too. But I wasn't planning to have it convert (compile) to PHP code directly, just because the result would have to be eval'd, which isn't an ideal way to execute PHP, unless there aren't any other options. Instead it would identify the function in the tag ($pages->find() in this case) and send everything after it directly to the selector argument of the function. The result would be cycled through the given markup/tags. But I'm going to make note of this for when I get closer to it, as I want to have as many ideas in front of me when implementing as possible. What I think before implementation and during implementation are often very different things. I like the creativity in the idea here. My two concerns would be conflicts with regular use of the API, and how a user would maintain this. But I'll assume there is a solution for the maintenance question. Templates are actually PHP include files rather than files that are eval'd separately (like in some other CMSs). Templates are likely to include other templates. A user can assume in their template file that it is a blank slate for building a PHP application. ProcessWire can be used as a PHP framework with lots of functions provided to it. Or you can even pretend that ProcessWire isn't there in your template code... using it like a blank PHP script that has it's own URL and some variables provided to it. But this flexibility necessitates that we don't make assumptions about what they are doing in the code. If we have alternate compiled versions of templates, suddenly PHP vars like __FILE__ would fail and relative includes would fail, among other things. Still, I appreciate the idea and will keep thinking about this to see where it might be applicable in the future. For instance, maybe a module could provide this capability and people would use it with the understanding some things may be a little different from the PHP side. I like this thinking! But I should note that PW is already ready to output any format. It doesn't get involved in output generation. It has no idea that it's used to output HTML most of the time. It provides the data to your template, and your template decides how to output it. So having output of RSS/XML, JSON, etc. at the core level goes against the concept of the CMS. But having that in modules or user-defined templates is consistent with the concept of the CMS. What I believe you are describing are modules (perhaps called as tags) that output in different formats, and that's always good. But I'm not totally sure I'm reading you right, so I'll just put in a short snippet of how we would currently make a page template that outputs a list of it's children in either HTML or RSS (determined by a GET var). Then maybe you can post an equivalent tagged example, if available. <?php $children = $page->children(); if($input->get->rss) { $rss = $modules->get("MarkupRSS"); $rss->title = "Children of " . $page->title; $rss->render($children); } else { include("./head.inc"); echo $children->render(); // or foreach for your own output include("./foot.inc"); } Thanks, Ryan

The passwords in ProcessWire are not reversible (unless you keep a copy of them somewhere else), so you would need to email a password reset email, as opposed to a feature that emails them their actual password. This is something that will be included with the new user system. However, if you wanted to do it now, you would have a "forgot password" link that they click on. It would click to a page with a template that would look up the email address for the user (email address stored per our earlier thread) and it would send them a special URL where they can reset their password. Likely it would be the same URL as the "forgot password" page, but with a special token in the URL to identify that they really did receive the email. There are a lot of security considerations with a feature like this that go beyond the scope of what may be practical to write in code here, but the actual password resetting part is the easiest part: $user = $users->get("user's name"); $user->pass = "user's new password"; $user->save(); You will want to be very careful before resetting the password to ensure that the user really is who they say they are. Because ProcessWire doesn't have email addresses in it's current user system, there isn't any way for it to confirm that the person really is who they say they are in a lost password function (which is why there isn't one). But since you are storing email addresses (per our earlier thread) it will be possible for you to implement a password reset function. When someone requests a password reset, you will email them a URL with a sufficiently complex randomly generated code as a GET var. I recommend something like sha1(microtime() . mt_rand() . $email). You will also want to store that code locally with the user in a new field, as well as in $session (i.e. $session->code). When they click the URL to your site (from the email they received), the template handling that page will examine the code and verify that it matches up with the code stored with the user, and likewise matches up with the code stored in $session. Now give the user a form where they can enter a new password, and set a new $session variable with the same code but under a different name, like $session->confirmed_code, and make $session->code blank. Once submitted, get the confirmed_code from the $session and find the user that has it stored. Change the password to the one they submitted (per the PHP snippet above). Be sure to remove the password reset code from the user's record in the database, and unset $session->confirmed_code. This is roughly the approach that will be taken with ProcessWire's new user system, but with a couple extra security checks (code expiration for one).

Glad that worked. Thanks for posting the final code too. The only other thing you'll want to be mindful of is when you delete a user, you'll also want to delete the associated page (just to keep things organized). I can show you how to create a module that hooks into the user deletion and handles the page deletion. Or you can periodically foreach the /members/ pages and check if there are any extras there. As you know, the users system is being redone. There are a few reasons, but one of them is that the system is designed just to have a few users in there, primarily for administrative purposes or for role placeholders for another user system. If you start getting hundreds of users in there, it's going to affect performance. In the new system, it won't matter how many users there are, since they will be built on top of the pages system.

Glad you like ProcessWire! Nice work on the site. The duplicated tree does seem like an easy to manage approach. Though if your pages are simple, and you only needed to support a couple languages, I would think that a duplicated field approach might also be good, because you could edit the two translations together on the same page. So you might have these fields in your template: headline_en headline_fr body_en body_fr And then just display the one that corresponded to the language you wanted to show. To determine the language, you could use one of the approaches Adam mentioned, or the approach I mentioned in the previous message. Or, if you didn't mind having the en/fr segment at the end of the URL, you could just look at the first url segment: /some/url/fr/ For this URL, the page is actually /some/url/ and the 'fr' part is what you added to the URL when generating it or linking to it. <?php if($input->urlSegment1 == 'fr') { $headline = $page->headline_fr; $body = $page->body_fr; } else { $headline = $page->headline_en; $body = $page->body_en; } echo "<h1>$headline</h1>"; echo $body;

I will put some thought into this and come up with a more official roadmap to place on the site. Thanks, Ryan

In this case, you'll want to use the 'more' link that appears at the bottom of the list. Keep clicking 'more' until you have the page you need to move in view, along with the place you need to move it in view. Then drag it to where you want it. If working from the main Page List, you can also drag the page you want to move to a temporary place, then drag it back to the new location once it's in view.

I think that I must have added a special case to the login process. If you could disable the login for the guest role, then you would essentially close your site off to edits and prevent yourself from being able to login. It should probably be the case with the logout role too, but this particular login/logout process was really made more for administrative use. I recommend making your own login/logout templates for non-administrative use.

This thread might have some more useful stuff too: http://processwire.com/talk/index.php/topic,37.0.html I didn't realize there was a need for more, but I can definitely add more. I can see the value with what you are mentioning here. Another possible way to handle a /en/ or /fr/ at the beginning would be to install ProcessWire in a directory named /en/. Then create a symlink on your file system called /fr/ that points to /en/. Your template code could examine the URL it's being loaded at to determine which version of content to show: <?php if(strpos($_SERVER['REQUEST_URI'], '/fr/') === 0) { echo $page->body_fr; } else { echo $page->body_en; } I haven't actually tried it, but I think it would work.

Thanks, I will definitely need help testing. Also wanted to mention that you can always take the approach mentioned here: http://processwire.com/talk/index.php/topic,54.msg917.html#msg917 This essentially duplicates what you could do with the new user system (in the areas you are describing), though it just takes more work on your part. Also see this thread too, for another approach: http://processwire.com/talk/index.php/topic,17.0.html Thanks, Ryan

Thanks for taking the time to write this up. I think what you are describing is very similar to what I'd like tagscript to progress to in terms of capability, so I appreciate having this written in more detail. My thought is that you will be able to define a new {tag} either with a function (like in that module above), with a separate module, or by pasting the tagscript snippet into an admin field (which doesn't yet exist, but will be built as a module). If you have the tagscript module installed, it will always translate tagscripts in you templates when you enable it. You'll also be able to selectively turn it on for any custom fields (like if you wanted to enter tags in your bodycopy or something). Being able to turn it on in custom fields is one area where I think tags bring something very useful to the table... you wouldn't ever want to enable PHP in a field, whereas I'd have a much higher comfort level (security wise) with enabling tags in a field. In terms of syntax, let me know what you think of this? Tagscripts can be simple like: {tag} Tags can have arguments, like: {tag, name="value", name="value"} Or tags that translate directly to an API function, and be "open", allowing you to create the markup (the closed version would generate it's own markup): {pages.find parent=/news/, featured=1} <li><a href="{url}">{title}</a> {date}</li> {/pages.find} That would be the equivalent of: <?php foreach($pages->find("parent=/news/, featured=1") as $item) { echo "<li><a href='{$page->url}'>{$page->title}</a> {$page->date}</li>"; } I like the open-tag approach, where you can define your own markup. I'm less comfortable with tags that output markup on their own (level 2 templates, as you described them), but also recognize that not everyone wants to recode the markup for everything, all the time. That's why the pagination and comments modules generate markup... because I don't want to have to code that markup for every site. So that's an admission of value for tags that output markup, but I think you always have to be careful with anything that's generating markup you didn't write. So my though is that for any given tag, you can write a closed version like {tag} that generates it's own output, or you can write an open version (like in the example above) or {tag} ... {/tag} where it uses what's in between for output, allowing you to substitute additional tags to obtain the raw values of fields within the {tag} ... {/tag}. I believe this is similar to the approach that Expression Engine tags with it's tags. When working on a site that involves a team of people responsible for design/development, you are absolutely right about this. For most of the sites I work on lately, it's just me building it and then maintaining it over time. But that's a unique situation, and not how it works half of the time in other work environments. I would agree that tags would be preferable with the site you are describing. While I personally find native PHP solutions simpler and easier to maintain for my own use, I would be inclined to use tags in situations where I knew other designers/developers were going to be making edits too. I plan to keep ProcessWire's core always PHP API based, but am very enthusiastic about building/collaborating on a module that can make the API fully accessible to tags, and let users define their own tags/snippets in a format that is easy to do and easy to share among sites. I think this will broaden ProcessWire's appeal with one of it's main target audiences (designers), though you said it better than me. Thanks, Ryan