ryan

Thanks, I have added this as an issue in the queue. https://github.com/ryancramerdesign/ProcessWire/issues/132

It shouldn't be. PW only sets this on login, and it should be retained for the session. There isn't any code preventing modification of it.l Double check that the value you are carrying in $user isn't the same one that's already in _user_id?

That code looks good to me, except for one thing: just change if($who) to if($who->id).

Since you'll be maintaining separate thumbnails from the large images, then I would just consider any images you upload to your PW install to be thumbnails. You can set the max width/height in the image field settings, so you'd just choose dimensions that are consistent with your thumbnails.

Not sure. It seems to work here -- This was one I actually tested before posting. The only thing I can think of is to make sure that you are putting those directives immediately after the "RewriteEngine On" and not after some of ProcessWire's directives. Though sounds like you may have already found another solution for this? Though admittedly I'm confused as to why that would work, because "site" is a directory that should exist, and thus PW shouldn't be getting control for a request like "/site/".

Michael, let us know how your event goes. Thanks for sharing ProcessWire there.

So it looks like PHP 5.2 is the common denominator. I must be doing some PHP 5.3 specific code without realizing it. I'll experiment more here and hopefully track down the relevant code.

Thanks, I think I understand what you mean and was able to implement a fix. Since it has potential to affect other things, I've put it in the dev branch for testing. If you want to try it out, replace your /wire/core/PagesType.php file with the one from the dev branch: https://github.com/ryancramerdesign/ProcessWire/commit/f2b63ec23cf8bb817eacf2c81434c354fc651dcd

Thanks for posting those, the screenshots answered it. Looks like I had an htmlentities() call without the 'UTF-8' in it for that header cite line. This has been fixed and committed to the source.

To redirect requests for just "/site/", you could do something like this in your main PW .htaccess file (after the 'RewriteEngine On' line): RewriteRule ^site/?$ / [R=301,NC,L] That would redirect a request for /site or /site/ to the root. If you have to account for additional URLs off of /site/, then you'd want to do something like this: RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^site/(.*)$ /$1 [R=301,L,QSA] That would redirect requests for /site/[any file or path that doesn't exist on the disk] to the same path off of root rather than /site/.

Great module! I'm testing here and it seems like a nice usability improvement. I'm going to use it on my site for a little while to test, but already thinking I agree this might be good to have standard… perhaps as something that can be enabled/disabled from the ProcessPageList module settings. Maybe a good core addition for the upcoming 2.3 version. As for module name, I think you've got a good name except for the 'Process' part, which we usually reserve for modules that extend the Process class. I would instead suggest maybe PageListPin or something like that?

It's a bug, but was fixed. You should be able to fix it just by pulling in a new /wire/ dir. I didn't update the version number for this one since it was pretty minor.

You should be able to drag them to the order you want. They are in the admin page tree as children of /processwire/setup/languages/. They may be set for alpha sorting, in which case you'll want to change to manual sorting. I think you must be running an older version of 2.2 because this issue was fixed 6 months ago. Update the version of your source and it should resolve the issue.

I think you are probably best off using 2.2. There aren't major compatibility differences between 2.1/2.2 (like there were between 2.0/2.1) so no real reason to stick with 2.1.

I have gone ahead and added this capability to the dev branch. Now pages with repeaters can access images within the repeaters, and repeater pages can access images from their containing pages.

I think it just depends what method you are using for your custom login. But of course, if you are doing a custom login then you don't need this module as you can just retrieve the user by email address (rather than name) and compare the password that way.

Thanks Kaster83, that would be helpful for me to get a look at your phpinfo. Also what version of ProcessWire does it say in the bottom of your admin screen?

Great module Netcarver!!

I tested it out on the desktop and watched lots of YouTube videos of people using it live. It seems to me like it'd be pretty challenging to use on an iPad (and especially on an iPhone). But clearly people are using it that way. I've been playing around with Animoog on my brother's iPad and must say that's a lot of fun. I have no idea how to make any sort of music in it, but just experimenting with it is a blast. Love the sounds that come out of this app. I'm making my way through your tracks and really enjoying Ship to Shore and April Joy. Actually, I'm still on page 1 because I've put those on repeat. Very impressed by your diversity of styles too.

I'm still a little confused. I can't duplicate any issues with the å,ä,ö characters you mentioned, as they are showing up correctly whether I go to the comments manager, the page-editor comments field or the front-end. However, in checking this I did notice a problem in the page-editor comments field in that it wouldn't let me open/close the comments by clicking their header. I went ahead and fixed that and pushed an update. But I'm thinking this isn't what you were talking about? If not, can you try posting a comment at the bottom of this page, containing an example phrase, and then tell me where to look to observe the problem? I'll keep an eye out for your comment. Or a screenshot might work too.

Somehow I didn't put two and two together before, sorry. Since you are trying to get the $page property from ProcessPageEdit -- this property is already exposed via the getPage() public function. So your module could retrieve it via $this->process->getPage();

That's right, it just needs to be moved anywhere after the PW initialization (after init, after ready). JqueryCore is not an autoload module (since its only used by admin) so all the autoload modules init before it does. If your module has an execute() or render() or something like that, that's where you'd want to move your script loader. This is also important for an autoload module because some sites use $config->scripts or $config->styles for the front-end, and you wouldn't want your module loading into that context, because who knows if they are even using jQuery in their site.

ModuleJS and Process modules aren't meant to be autoload, so I think that's why you are seeing that behavior here. I don't see any problem with making them autoload, except that you'll need to load your JS/CSS separately. So I'd name them something different (maybe put an underscore in front of the filename), and move your script load to your execution rather than initialization. $this->scripts->add($this->config->urls->modules->MyJSModule . '_MyJSModule.js');

ProcessWire doesn't do any sanitization/validation beyond that from PHP's filter_var(FILTER_SANITIZE_EMAIL | FILTER_VALIDATE_EMAIL); I went in and tried addresses like ryan-@domain.com and ryan+cramer@domain.com and ry+an-@domain.com, but it accepted all of them (FieldtypeEmail / InputfieldEmail). I might need another example from you to reproduce the issue with?

This is what the 'ready pages' setting is for. You may want to bump it up to 2, 3 or higher-- whatever typical repetition you would have. The only other way I can think of that you could do this would be to stuff a bunch of predefined date fields on the template. And this would be a fine way to go if you knew you were never going to have more than 4, or some other predefined amount. But for an unknown quantity, I think repeaters would be hard to beat here (at least, I can't think of anything else short of a custom Fieldtype/Inputfield).