ryan

Both guys here are correct. The session needs to be regenerated with a new session ID and some new cookies need to be set, etc. Redirecting after successful login ensures you are dealing with the new and authenticated session and $user, ready to work with.

You should be able to use has_parent=/root-parent/, replacing 'root-parent' with the name of your root parent page. That's assuming that you want to match all pages that live within the root parent and their children, etc. If you just want children of that root parent, then you'd do parent=/root-parent/

Mike, which tablet are you using again? I'm thinking it's an Android tablet, but don't recall. I've only tested on my iPhone and iPad, so probably need to expand the touch device testing into Android a bit more. We're using a separate mobile menu that's geared towards touch interfaces, but I'm guessing it's not appearing, and you are getting the desktop menu from the sounds of it.

I think Kongondo has it mostly right. But for the sake of keeping it simple, maybe ignore the part about making a copy of the AdminThemeDefault for the moment, and just make your edits to AdminThemeDefault. Once you've got them in place, you can always copy it to a different admin theme in /site/modules/ if you want to. But lets get down how to add color themes first. 1. Add your new color theme option to the AdminThemeDefault.module file like Kongondo mentioned. 2. Go into /wire/modules/AdminTheme/AdminThemeDefault/styles/sass/ and copy _vars.scss to _colors-pete.scss. The _vars.scss is based around the Warm color theme. If you prefer to use a different one as a starting point, then copy _colors-classic.scss (for example) to _colors-pete.scss instead. 3. In the same directory, edit the main.scss file and add your new colors file, making sure the others (except 'vars') are commented out: @import 'vars'; @import 'mixins'; //@import 'colors-classic'; //@import 'colors-modern'; //@import 'colors-futura'; @import 'colors-pete'; // ADD THIS LINE 4. Make edits to your _colors-pete.scss file as you see fit. You don't need to know Sass to do this, as everything is predefined with Sass variables that you can just insert new color values into it. However, read the following steps first, as you may want to setup your Sass watch to keep an eye on the changes for you as you go, so that you can see them take place in your browser as you make them. 5. Compile the styles/sass/main.scss file to styles/main-pete.css using whatever method you prefer. The standard method would be to use Sass watch. If you were currently in your styles/ directory, you could type this at the command line to automatically compile changes to main-pete.css. sass --watch sass/main.scss:main-pete.css This will keep running indefinitely, monitoring for changes and compiling them to main-pete.css every time a change is made to any one of the scss files. If you only wanted it to run once, then you'd just omit the "--watch" part. 6. Before or while you are making changes to your _colors-pete.scss file, go ahead and login to PW admin and go to Modules > Core > Default Admin Theme. Click "Settings" and change the color theme to "Pete", so that you can see your changes as you go.

@obrian7's issue report confirmed here and now fixed on dev.

Most fields require you to save their settings before they are committed. But the defaults should usually represent the unsaved state. In this case, we should probably make the default precision 0 since that's what it would be if the field hadn't yet been saved. Either that, or we should just not support a 0 precision (as there's probably no point in it for a float) and assume that to be some other default value like 2. I'll try to duplicate here, and if I can I'll adjust this behavior. Thanks for reporting it.

Avoid using dependencies in repeaters, as support is limited at present. I hadn't intended to implement them at all, and haven't written any code to support them as yet. Another user submitted a pull request to add basic support, but I think that only works with the equals "=" operator at present. If it proves to be reliable with that one operator, we will work to expand on that PR to add support for other operators.

@pers0n: go back to the first page in this thread. Events are not the purpose of this fieldtype. Events are just used as an example. The purpose of this fieldtype is for you to modify it specific to the data you need to represent, whether a table of inventory, prices, people, or any kind of tabular data you want. Even if you actually wanted to use it for events, you'd still want to modify it for the type of events given that it's not that useful in it's demonstration state. This fieldtype is meant to be changed by you.

rsync can also be used with the --delete option, which will synchronize deletions as well. rsync --archive --rsh=/usr/bin/ssh --verbose --delete account@domain.com:www/site/assets/files/* /path/to/domain.com/site/assets/files/

That line is too broad. If given the right ID, it could load anything in the site, including any user account. Narrow it down by supplying a template or parent or something to make sure you are getting what you expect. i.e. $theitem = $pages->get("template=item, id=$itm"); When comparing page objects (which is what users are) you'll want to compare the 'id' property: if($user->isSuperuser() || $theitem->createdUser->id == $user->id) { Also, you aren't checking that the page you retrieve actually exists. I'd suggest adding this: if(!$theitem->id) throw new WireException("That page doesn't exist"); That exception occurs when you try to delete a system page or a NullPage. When that exception occurs, it halts program execution immediately. If something still got deleted, it would have had to have happened before that exception occurred. It doesn't look like your code could generate that error, so I'd guess there's a hook into Pages::delete that is attempting to delete another page related to the first deletion. Also, before deleting the page, I suggest checking if it is deleteable from an access control perspective: if(!$theitem->deleteable()) throw new WireException("That page is not deleteable");

I would avoid putting it in /cache/HannaCode/. What does your include line look like? If your class file were placed in /site/templates/includes/ (for example) then your include line should look like this: require_once(wire('config')->paths->templates . "includes/YourClass.php");

Line 318 seems to imply that the page being accessed didn't yet have a template assigned to it. That sounds like a core error rather than a user one, so I'd be curious about how to duplicate that–maybe a potential bug. But if it was accompanied by a nesting level issue (via xdebug), and correcting the xdebug setting also corrected the issue, then I wouldn't worry about it. Are you still getting the Page.php line 318 error?

I agree with Teppo and this is the same method the core uses.

I have no idea why users are getting logged out in your case, but a few things I would look at: 1. How long was the user logged in at your site? Make sure they have completed at least one full page request as a logged in user before you redirect them elsewhere. You can accomplish this by redirecting to a local page first before redirecting to another site. 2. What URL does your payment gateway return them to? If the user started out on an http URL and returned on an https URL (or the reverse), that might be something to look at. What sort of switching between http and https does your site perform? 3. Is the user returning to the exact same hostname? i.e. www.domain.com and not domain.com ?

Also try enabling debug mode in your /site/config.php and look at the Debug link at the bottom of the admin theme. There is a list of all loaded modules (among other things). If you want to see how it's getting that from the code side, then have a look in /wire/templates-admin/debug.inc.

Another option would be to add a small module that hooks Page::render and replaces the paths directly in the output... when running on localhost. It could replace it with something like this: public function init() { if(wire('config')->httpHost == 'localhost') { $this->addHook('Page::render', $this, 'hookAfterPageRender'); } } public function hookAfterPageRender($event) { $event->return = str_replace('/site/assets/files/', 'http://domain.com/site/assets/files/', $event->return); }

Sounds like a good idea. What is the use case? Wondering if would be better provided as a data attribute or something along those lines.

The blog profile is also a good demonstration of how to implement tags.

Adrian, remember to restore the output formatting state of $user, i.e. $user->of(true); unless you sure you won't be outputting anything from user after that block of code. But safer just to restore it to of(true) after you've saved.

What version of PW? Are you sure that category is a field of type "Page" ? Does it work if you change it to this? if($input->urlSegment1) { $name = $sanitizer->pageName($input->urlSegment1); // remember to sanitize $category = $pages->get("template=category, name=$name"); $results = $pages->find("parent=$page, limit=10, category=$category, sort=-date"); } Also, just want to double check that you intend for the parent to be $page in that selector? That would mean your articles and category URL segments are sharing the same namespace. That's perfectly fine, but not that common to do that, so just double checking.

I just needed a couple more days to finish writing up the announcement and changes. I'm guessing you've already seen it by now but just in case you haven't it's located here: http://processwire.com/about/news/introducing-processwire-2.4/

I would bet that's got something to do with this line. That line may not be necessary anymore now that we've got CKEditor's ACF working properly. Try commenting it out to see if that fixes the issue? Please let us know.

I'm not sure that I understand, but you should have full control over your field names in FormBuilder. If you want a field to be automatically populated from a GET var, then you'd want that variable name (i.e. "myfield") to be what's specified in the URL, i.e. domain.com/path/to/form/page/?myfield=something. Likewise you'd want to use "myfield" (or whatever you named it) as the field name in FormBuilder. Also you mentioned populating those values programatically. You can do that like this: $vars = array('foo' => 'bar'); echo $forms->embed('myform', $vars); If using it in a non-embedded way (like method C) then you'd just populate the values to your form the old fashioned way, like you would with an Inputfield form.

You'll want to test ahead of time, but I think it'll still work. There are some bugs and security issues in PHP 5.3 versions prior to 5.3.8, which are good reasons for nobody to use those versions. That's the main reason I set 5.3.8 as the minimum. But the reality is that it should still work fine in any 5.3. Chances are it would still work fine in 5.2 as well, but I want to take that monkey off our back so we can move forward.

Nice work mvdesign! Very attractive look and lots of good thinking here. We* are actually working on a second core admin theme option that is quite similar in many ways to the look you've posted here (the overall layout of major elements is very much the same with regard to masthead and sidebar). Once released, I'm imagining it will also serve as a very good starting point for taking your design here to a full admin theme. *I say "We" because I assume I'll be working on it here soon too, but so far all the work has been done by someone else.