ryan

PW's admin is built with the intention of administrative users, so doesn't do what you are asking out of the box unless you give each user their own template to edit. However, you may code your front end (site template files) to provide access to any page fields that you want to, and that's the recommended way to give non-administrative users access to manipulate data in your site. From that standpoint, you can do nearly anything, but it does take a little code. The option Diogo mentioned is a nice simple way of handing this kind of stuff. If you can go into more detail about what fields on a page a student might edit, we maybe able to get a rough example going in this thread. Also wanted to mention that you can achieve this on the back-end with a custom module, and it's not that hard to do. But since you mentioned students, I was thinking that sounds more like a front-end scenario.

I think it makes sense, and have recently had the same wish. Adam brought this up a long time ago, and I've been meaning to add it, but just haven't gotten around to it yet. Now that there's been another request for it, I'll push this forward sooner rather than later. Actually now that my mind is on it, I think I'm going to work on it over lunch break. The plan is that when you select a default sort at the template level, the option no longer appears with the page (i.e. template setting, if used, overrides page). If you select 'none' (the default), then it can still be set at the page level. When no sortfield is set, pages sort ascending by the database field 'pages.sort'. When you create pages in the admin, they should get added in the order you create them, as ProcessPageAdd manually sets this. That would look like 'created' order. But when you create pages in the API (or any kind of import process), and don't set the 'sort' field of a page, then they are all going to have the same sort value (0), which makes order unpredictable. I actually modified that yesterday when I was fixing the drag-sort issue that smd found, and committed it this morning. Now $pages->save() takes care of setting a $page->sort value if you don't, so it should be more API friendly. The reason we don't want to default sort by something like 'created' is for the reason Antti mentioned (no ability to manually sort).

For something like that, I think you'll be better off just importing from the API. Probably 70% of the time that I need to do any kind of importing of anything, I just use the API because it usually makes a quick and easy job of it, without having to consider any limitations. But if you want to get image/file descriptions in with the CSV import module, then I would probably create a temporary field to store them in, for import purposes. Then go back and paste a little code in a template to quickly convert them over: foreach($mypages as $p) { $p->of(false); $p->image->description = $p->temp; $p->save(); } Once you've done that, you could then go and delete that 'temp' field from the template.

Count me in to help if needed. I think this may be one that belongs in the core, though have avoided it thus far since it gets the core involved in specific fieldtype output. But this may be an okay compromise to make if done directly in ProcessPageList. Other than that, I think that a module is definitely a good way to do it too.

Thanks for posting Renobird. I'm confused on this section: if($session->login($user, $pass)) { // login successful $session->redirect($page->path); $error =""; $session->set($error, ""); } else { $error =""; $session->set($error, "Login Failed. Please try again, or use the forgot password link below."); } // ... further down echo "<p class='error'>".$session->get($error)."</p>"; It seems like that is just setting a blank session variable? Are you sure you didn't mean for it to be like this? if($session->login($user, $pass)) { // login successful $session->set("error", ""); // note: moved this above the redirect $session->redirect($page->path); }else { $session->set("error", "Login Failed. Please try again, or use the forgot password link below."); } // ... further down echo "<p class='error'>".$session->get('error')."</p>"; Good question--I have no idea. I've been trying to figure this one out for awhile. I have to paste any code in my plain text editor, then manually indent everything with 4 spaces. This editor appears to ignore tabs. Pete's been doing a great job of installing updates for us here, so we'll very likely see improvements here as the IP.Board developers make them.

Good questions RecycleRobot. This is really is going to vary from environment to environment, so my recommendations would be more general. Though awhile back Soma reported that some of his colleagues had run a stresstest called a "proxy sniffer load curves report", and the report came back quite good. But I don't know what all that entailed. I recommend giving it 128M memory (the PHP 5.3 default) or more, in your php.ini. If you need to deal with lots of traffic, it's a good idea for your server to have a PHP opcode cache like APC or eAccelerator. Beyond the server configuration, other performance factors depend on how you use ProcessWire. If you are doing anything heavyweight with the API towards markup generation, or just need to handle lots of traffic, it's a good idea to make use of PW's various caching options. From the template settings, you can tell it to use a cache from the 'cache' tab. Choose settings that maximize the lifetime of the cache, clearing only what you need to cleared when a page is saved. You'll also want to get familiar with the MarkupCache module, which enables you to cache individual pieces of markup in your templates. This is really handy for caching markup that may be expensive to build on every request, like larger navigation trees... or anything you want. You'll also want to look at these best practices for long term scalability, as well as the field autojoin option. If you need to work with a lot of pages in memory at once during the same request, the $pages->uncacheAll(); function can clear memory when you need it (at the expense of having to reload any pages you try to access again). How much memory a Page takes up depends entirely upon how many fields it has and how many are loaded/populated. ProcessWire generally tries to keep Page objects as lightweight as possible, and doesn't load fields until you actually access them. As a result, you could feasibly get thousands of pages in memory if all they had were short 'title' fields. But you might only get a few hundred if those pages have their fields loaded and all in memory at once. PW does create a new directory for each page at present. That behavior will become on-demand in the near future. But at present, this would mean your maximum quantity of pages (at least, pages that can also store files) could be limited by the file system and any hard limits present there. ProcessWire is not compatible with PHP 5.1. If you are running it, I'm not sure how because 5.1 lacks some things that PW depends on. I'm guessing 5.1 was a typo, but if not, let us know as I may have missed something. I recommend running PHP 5.3 if possible to maximize performance. Also, I may be wrong about this, but I had thought that there was some overhead with running PHP as a CGI as opposed to running it as a module. If that's still the case (?), you may benefit from running PHP as an Apache module, but I'm out of area of knowledge on this one.

I was able to duplicate this. The problem was the recently introduced version numbers that are appended to $config->scripts (and $config->styles). InputfieldImage manually adds InputfieldFile.js to $config->scripts, as it always has. But it knows nothing about version numbers. The result was that if you had both a file and an image field on the same template, the same InputfieldFile.js would get included twice (one with version number, one without). All that JS in InputfiledFile.js would also execute twice when you dragged in a file. Thanks for finding this bug--I just committed a fix for this. I don't want to have to append version numbers ever time I manually add a script/style from a module, so I setup PW to ensure uniqueness of these at the time they are added (regardless of version number). I'm not yet sure why the display thumbnails option would make a difference here, but will experiment more. Please let me know if you find any issues remain. Thanks, Ryan

You can always create your own login page (and template) and have full control over the flow there. Logging in a user in PW is as simple as calling $session->login('name', 'pass'); If it authenticates, it returns a $user. If it doesn't, it returns null. The $session->login might also be a good one to hook if you don't want to create your own login form. I think this would be preferable to trying to hook in ProcessLogin or ProcessHome.

It should be possible using the ProcessPageListRender::getPageLabel hook. That function is given a $page as an argument, and it returns the label to use for the page in the page list. If you hook in after it, or hook replace it, you should be able to have it return an <img> tag instead. This is something we may want to add to the core at some point too, but based on a quick look, it appears that a module could accomplish it pretty easily.

Someday we'll definitely have to have ProcessWire US meetup. Atlanta seems to be pretty quiet from a web development community aspect. I've been here for 9 years and don't know any other web developers around. On the other hand, Atlanta has the world's busiest airport and a worldwide air traffic hub of sorts (i.e. easy to get to). Still, I think if folks are traveling by air then it's better to combine it with a larger conference to maximize the value for everyone. For instance, an interactive conference like SXSWi in Austin, TX or something a little smaller. So there would be a ProcessWire meetup, but within the context of another related conference. I think that would be the ideal way to go for a US meetup since everything here is spread out a lot further than in Europe. I'm guessing it's a lot easier to have a dedicated meetup in Europe because things are closer and transportation options are much better (trains, etc.).

If it doesn't add any overhead, or interfere with anything existing, I'm cool to add it in the core as one of those things people can choose to optionally turn on. I think if I could see a diff or GitHub pull request that shows me what's different, that's all I'd need. I still don't really understand the Bramus CSS extras plugin or know how/why/when to use it, otherwise it would already be added. For instance, their "what is bramus css extras?" screen implies that one can't float images without it (which obviously isn't true), among other things. I only get lost in their demo, which seems to cross some uncomfortable boundaries of turning TinyMCE into a styling tool. So I've always been a bit perplexed by the value of this plugin. However, I do understand that it is apparently very useful, as many don't want TinyMCE without it. So if it makes life easier to have it as an optional component in the core, lets add it.

It's a bug. Thanks for finding this, and for the excellent description on how to duplicate it. I was able to duplicate easily, and have committed a fix to the source. This bug has apparently been there since the beginning. I'm guessing not many have used manual sorting with pagination, which is why it's not turned up earlier. Glad to have this one fixed--a particularly annoying bug for sure. Sorry for the inconvenience it caused you. Please let me know if the fix does or doesn't resolve it from that end too.

There's still some bugs in this, as you found. I've got this on my issues list, but just haven't had time to fix it yet. Hopefully will have this resolved soon.

I can duplicate that too in Chrome too (and not in Firefox or Safari). While back buttons are generally evil in web apps, that's definitely not an expected behavior. Not sure if this is a bug in Chrome or what it is, or if there's anything we can do about it. It's basically interpreting the code wrong. Will do more research. Let me know if you can think of anything too.

That's not a problem. Technically it's no different than any other link. One thing you may find useful is to do a $session->redirect() to another page immediately after a login or logout (and of course before any output). That way you are starting on a clean slate and don't have to think about the state of the $user API var.

The module isn't intended for non-interactive use. However, the PW API certainly is (and LazyCron), and pretty clean and simple for doing stuff like this.

I think either is a good idea. But maintaining the files ready-to-translate is good just so that people don't have to click to add each of them manually. So I will plan to prepare that. Currently I locate the files with a grep command in the shell to find them all: cd wire grep -Rl '[>_][_nx](' * | uniq It's not a 100% as it may include 1 or 2 things it doesn't need to, but should catch everything translatable. core/Fieldtype.php core/Inputfield.php core/InputfieldWrapper.php core/LanguageFunctions.php core/SessionCSRF.php core/Wire.php modules/Fieldtype/FieldtypeComments/CommentForm.php modules/Fieldtype/FieldtypeComments/CommentList.php modules/Fieldtype/FieldtypeDatetime.module modules/Fieldtype/FieldtypeFloat.module modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module modules/Fieldtype/FieldtypeRepeater/InputfieldRepeater.module modules/Inputfield/InputfieldAsmSelect/InputfieldAsmSelect.module modules/Inputfield/InputfieldButton.module modules/Inputfield/InputfieldCheckbox.module modules/Inputfield/InputfieldCheckboxes/InputfieldCheckboxes.module modules/Inputfield/InputfieldDatetime/InputfieldDatetime.module modules/Inputfield/InputfieldEmail.module modules/Inputfield/InputfieldFieldset.module modules/Inputfield/InputfieldFile/InputfieldFile.module modules/Inputfield/InputfieldFloat.module modules/Inputfield/InputfieldForm.module modules/Inputfield/InputfieldHidden.module modules/Inputfield/InputfieldImage/InputfieldImage.module modules/Inputfield/InputfieldInteger.module modules/Inputfield/InputfieldMarkup.module modules/Inputfield/InputfieldName.module modules/Inputfield/InputfieldPage/InputfieldPage.module modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.module modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelectMultiple.module modules/Inputfield/InputfieldPageName/InputfieldPageName.module modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.module modules/Inputfield/InputfieldPassword.module modules/Inputfield/InputfieldRadios.module modules/Inputfield/InputfieldSelect.module modules/Inputfield/InputfieldSelectMultiple.module modules/Inputfield/InputfieldSubmit/InputfieldSubmit.module modules/Inputfield/InputfieldText.module modules/Inputfield/InputfieldTextarea.module modules/Inputfield/InputfieldTinyMCE/InputfieldTinyMCE.module modules/Inputfield/InputfieldURL.module modules/Jquery/JqueryWireTabs/JqueryWireTabs.module modules/LanguageSupport/LanguageParser.php modules/LanguageSupport/LanguageSupport.module modules/LanguageSupport/ProcessLanguage.module modules/LanguageSupport/ProcessLanguageTranslator.module modules/Markup/MarkupPageFields.module modules/PageRender.module modules/Process/ProcessField/ProcessField.module modules/Process/ProcessForgotPassword.module modules/Process/ProcessHome.module modules/Process/ProcessList.module modules/Process/ProcessLogin/ProcessLogin.module modules/Process/ProcessModule/ProcessModule.module modules/Process/ProcessPageAdd/ProcessPageAdd.module modules/Process/ProcessPageClone.module modules/Process/ProcessPageEdit/ProcessPageEdit.module modules/Process/ProcessPageEditImageSelect/ProcessPageEditImageSelect.module modules/Process/ProcessPageEditLink/ProcessPageEditLink.module modules/Process/ProcessPageList/ProcessPageList.module modules/Process/ProcessPageSearch/ProcessPageSearch.module modules/Process/ProcessPageSort.module modules/Process/ProcessPageTrash.module modules/Process/ProcessPageType/ProcessPageType.module modules/Process/ProcessPageView.module modules/Process/ProcessPermission/ProcessPermission.module modules/Process/ProcessProfile/ProcessProfile.module modules/Process/ProcessRole/ProcessRole.module modules/Process/ProcessTemplate/ProcessTemplate.module modules/Process/ProcessUser/ProcessUser.module modules/System/SystemUpdater/SystemUpdater.module modules/Textformatter/TextformatterEntities.module templates-admin/default.php templates-admin/topnav.inc

You could also create and add a checkbox field to your template(s) and call it something like "sticky". When a page has the box checked, it will stick to the top of the list. Then when you perform the call to load your pages, sort by -sticky first, then by -date, i.e. $pages->find("parent=/news/, sort=-sticky, sort=-date");

Glad you figured out the start=0 thing for the news_index. When you are using pagination, PW will attempt to paginate all of your find() or children() function calls that have any limit=something. So adding start=0 is the way to keep them in check. For the categories template, the only "limit=" statement that I see says "limit=1". In order for pagination to be activated, there has to be a limit greater than 1. You may be able to get the result you want by doing a $pages->find("limit=2, start=" . ($input->pageNum-1)); and then just using the first page it returns.

The source files themselves are in English, so the only time translation files are needed is if you want to change them (whether changing the language, or changing the English). I could maintain an English translation pack (with unpopulated fields), though it would be something that would only be useful as a starting point for other language packs. Still, if that would be helpful to other people, I'll be glad to do it.

I'd definitely be interested if I wasn't so far away. I think it'll be a little while before there is any kind of PW meetup in the US because the general web dev population here is just now discovering what you can do with WordPress, Drupal and EE, about 5-10 years after the rest of the world did. I think I'm the only one in my state (GA) developing in it. For some reason, any time I bring up ProcessWire around another developer here, it always leads to us looking at their "cool Wordpress sites".

Are you outputting anything before the login() or redirect() functions? The login() function sets a cookie and the redirect() function sends a header, so those things need to happen before any output as started. Meaning, this stuff would need to go at the very top of your page, before any <html>.

I'm confused -- the site link you sent to me seems fully functional. I can't find any error messages?

I don't know what the capabilities or limitations of the software are, but I'm all in favor of anything multi language.

If it's alright with you, we might want to keep the topic here in case anyone else comes up with a similar issue in the future. I had thought that mysqli had some performance benefits over the older PHP mysql, but not positive on that. I think mysqli has been standard since PHP 5.0, though I recently came across a PHP 5.2.x server that did not have it (luckily all it took was a few clicks in WHM to install). The PHP developers started encouraging us to use mysqli rather than the old mysql functions when PHP 5 came out. As far as I know, the old mysql functions are no longer actively developed for PHP, just maintained for backwards compatibility.