ryan

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).

Btw, if you need some old $_GET/$_POST references in core modules converted to $input so that you don't have to have duplication, let me know and I'll be happy to update any that you want.

Sounds like potentially a good use case for a date field in a repeater?

Pretty much. The $input API var didn't exist before some of the other code did. And the code you mentioned (PageList, PageEdit, PageAdd) is some of the oldest code in the system. Since most of what happens during these processes actually happens in other modules, this code doesn't see much action… no squeaky wheels there, so I tend to leave it alone. But when I'm working in a file that might have some older code (like that referencing either $_GET or $_POST), I'll usually change it over to use $input instead. Granted it doesn't matter that much at present, but I prefer $input for consistency. The only benefit that $input->get/$input->post are delivering at present is abstraction from the magic_quotes setting. Longer term, I plan to connect some of the sanitization methods with $input vars so that you an pull variables pre-sanitized. So I think using $input is a better practice, but won't feel strongly about it until we're delivering more value as a result of it. I know there are a lot of people that think there must always be layers on top of PHP's native input variables in any framework. I'm not one of them. $_GET and $_POST (and their friends) are universal, instantly understandable and always portable. Eventually there won't be any $_GET or $_POST references in PW's core. But I don't see any problem with others using $_GET/$_POST in templates if they want to.

Your ProcessWire template files are just like any other regular PHP file, so you can do anything with them that you could with a PHP file on it's own. Since you are wanting to generate a static KML file, your main consideration will be to determine where you generate it. ProcessWire will create a writable files directory for any page, which you can get to by accessing the filesManager() function, like this: $path = $page->filesManager()->path(); $url = $page->filesManager()->url(); So to generate the file, you'd do something like this: $data = "say this is your KML data"; $filename = $page->filesManager()->path . "my-data.kml"; file_put_contents($filename, $data); Then you could access that file from your browser at: $page->filesManager->url() . "my-data.kml";

I'm not sure what it could be, but I think it would be worth trying another browser just in case it's client side. Since you are using FF, try it in Chrome just to see if it makes any difference. What is the exact size of the file you are uploading? I can try to find something similar here to test with.

Form Builder isn't currently setup to modify existing entries. It's also not a page editor like what you have in the PW admin. When a form entry is saved, it goes into a database kind of like a CSV file. Then the entry from that database can optionally be imported to a page. This can happen automatically too, but that's what's happening behind the scenes. So there isn't actually any direct form-to-page capability beyond that. This is great for creating pages, but not modifying existing ones (at least, not yet). The capability you are talking about is pretty similar to what we're doing on the modules.processwire.com submission form. You can submit a module through there, and you can also edit any existing module. You have to have the email address and password that you originally submitted the module with in order to change it. It seems to be working out quite well. I'll be happy to send you the code for it if you'd like. It's not using Form Builder at present, though I will probably upgrade it to use Form Builder at some point.

In the example above, it would actually only hook into rows for ProcessTemplate when it is doing the template list (execute) function. This could be a good way to go. There are several instances of tables in the admin, so was just trying to think of an overall solution that would apply to all tables rather than one just for ProcessTemplate. That way the next time someone asks how they can hook into a table, I'll be able to give a better answer than I could this time. Since when do you care about PHP prior to 5.3? Between you and SiNNuT, I've been convinced we need to exit 5.2 sooner rather than later. GitHub isn't loading for me right now so can't see what the link is pointing to, but I'll be happy to make any adjustments necessary.

Session fingerprint also keeps track of useragent. So if your useragent or IP is changing, then the session is considered no longer valid. This can help to prevent session hijacking. But it can be a nuisance if your IP and/or useragent are changing for a valid reason. In that case, you should disable session fingerprint from your /site/config.php file. Locate this line and changed it to 'false' as shown below: /** * sessionFingerprint: should login sessions be tied to IP and user agent? * * More secure, but will conflict with dynamic IPs. * */ $config->sessionFingerprint = false;

This one has been on the @todo list for a long time, as it's kind of a tricky query to implement. Go ahead and try out the latest dev branch, which should implement this capability. So far it seems to be working here, but could definitely use more testing.

Thanks, I will update that now…

It should do that automatically. PW requires a user to at least have that role, so it'll add it if it's not there. You could do this with a hook. Add this to the top of your form-builder.php template file: $forms->addHookAfter('InputfieldForm::processInput', null, 'hookProcessInput'); function hookProcessInput(HookEvent $event) { $form = $event->object; $field = $form->get('username_field'); // substitute the name of your username field if(!$field) return; // probably a different form you don't want $username = $sanitizer->pageName($field->attr('value')); $user = $users->get($username); if($user->id) $field->error("That name is already taken"); } This was written in the browser rather than tested here, so may need tweaking, but let me know if you find it provides the capability you needed or doesn't?

I'm definitely willing to build it unless anyone else has been interested in this. I need to spend a little more time playing with Redactor as I'm still not totally clear about what advantages it has over TinyMCE (other than being smaller). Though the API for it looks quite nice, but that's an advantage to the guy coding the module, not necessarily the end user.

Another one to add to the mix: $count = count($page->children)-1; foreach($page->children as $n => $child) { $class = "a$n b" . ($count - $n); echo "<li class='$class'>"; } Using this method, you can target the first item with class "a0" or the last item with class "b0". You can also target any item from the start or the end by specify "a[n]" from the start, or "b[n]" from the back, where [n] is the zero-based index of the item from the start/end.

Welcome WinnieB! Thanks for the kind feedback, glad that you are liking ProcessWire. The skyscrapers profile was originally written for PW 2.0 (the first open source release) and so I worry that techniques on the back-end of it aren't so up-to-date and wouldn't be particularly helpful to people. It does run in the current ProcessWire, but I feel like it's kind of outdated so a little worried it would confuse more than help. I do want to update it to be distribution ready again though--definitely on the to-do list. I haven't tried Renoise but really like current tracks by Mosaik (aka Radix) and know that he uses that. I did play around with Sunvox a bit this year, and was quite impressed by it. But time is hard to come by these days, so don't think I'll be back into making music for awhile. But I kind of want to get one of those recycled propane Tank Drums just to chill and play once in awhile.

This used to be the case but isn't anymore.

Here's the reply I got from the Redactor folks: Sounds like they are aware of Candy CMS (which I'm guessing is using the older version). Either way, it sounds like they are recommending we build the Redactor module as a commercial add-on.