ryan

It should be no problem to get that setup, and we've done it many times. Take a look at the CMS case study, in the case studies board, as it describes how to do something with the same approach.

Thanks for letting me know. Looks like there was a limit set in there, and I went ahead and removed that so hopefully it works now.

Thanks for submitting your sites! We're now up to 106 sites in the sites directory. Keep them coming! I added the FieldtypeLikes module so that you can now click "like this site" for any of them (this is also used in the modules directory for the recommendations feature). I figure this will be useful for sorting and ensuring that some of the best examples of PW sites rise to the top, down the road. Perhaps we'll display the top 3 on the homepage or something. Currently "most liked" is a sort option, but default sort is by date modified. Anyway, if there are any sites you think are especially good examples in the directory, please go there and like them. The other addition is that the sites directory now uses Philipp's excellent ProcessImageMinimize module for all the screenshots.

I agree, that looks great. I'd say it's brilliant even. It's a "P" both in positive and negative space, and the whole thing is constructed from a wire. I'm wondering if the Bitnami folks would mind if we used that elsewhere.

I've posted the first iteration of the directory here: http://processwire.com/about/sites/ – I plan on doing a lot more with it (including a landing page for each site), but just wanted to get something posted quickly since we may be getting more traffic coming in soon with the Bitnami release. Thanks to those that have submitted their sites so far. Thanks especially to Marty (stillmovingdesign), one of the most prolific ProcessWire users, for taking the time to submit all of his ProcessWire sites in there. We went from having about 5 sites to having 30 after he submitted his. Now we've got about 64 sites in there. Please keep submitting posting your ProcessWire sites. We want to show a comprehensive diversity of work in the directory, and it's already coming along really well! I've added a few of your sites for testing purposes. If you already see your site there and want to change something about it, just re-submit it and I'll overwrite the existing one.

Please add your ProcessWire sites to our directory, immediately before or after posting to this board. We want to make sure that everything posted here is also posted in our official directory.

Nickie, please send me a PM indicating which product you got so that I can upgrade your access to the board. We assume that you are going to using the product key on one or more staging and development servers. We don't place limits on how many times the key can be used, other than if a product key intended for single use starts showing up on multiple production servers for different sites, then we'd inquire about it. But we all use the same key between development and production servers for an individual site, and that's encouraged.

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.