ryan

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.

I haven't tried this before, but theoretically it might work. You could try this: $process = $modules->get('ProcessForgotPassword'); echo $process->execute();

I like your idea of adding that. I'd also need to add another function for the table header too. Though wondering if there might be more mileage in just making the MarkupAdminDataTable methods hookable, as that would provide the same flexibility anywhere these tables are used (though with a little extra code to make sure you are hooking the right table, like below). Theoretical code (this would not work at present since MarkupAdminDataTable::row is not yet hookable) public function ready() { if($this->process == 'ProcessTemplate') $this->process->addHookBefore('execute', $this, 'hookTemplateList'); } public function hookTemplateList(HookEvent $event) { $this->addHookBefore('MarkupAdminDataTable::row', $this, 'hookTemplateListTable'); } public function hookTemplateListTable(HookEvent $event) { $arguments = $event->arguments; $row = $arguments[0]; $row[] = 'Another column'; $arguments[0] = $row; $event->arguments = $arguments; }

It sounds like you are adding images to a PW page. Here's how you'd do that below. When you are manipulating values on a page, you usually want to have output formatting off. When that is the case, an image field will always behave as an array of images rather than 1 image. So the code below would be the same regardless of whether dealing with a single image field or a multi image field. The example also assumes your images field has the name 'images', but it can be whatever you want it to be. $page->of(false); // turn of output formatting if in template context, not necessary otherwise $page->images->add('/path/to/file.jpg or http://domain.com/path/to/file.jpg'); $page->save(); Note that $page has to exist (and have an 'id') before an file/image is added to it. So if you were creating a new Page, you'd have to do it like this: $page = new Page(); $page->template = 'name-of-template'; $page->parent = '/path/to/parent/'; $page->save(); $page->images->add('http://...'); $page->save(); If you want to delete an image, do the delete and save before adding another: $page->images->deleteAll(); $page->save(); // commit the deletion $page->images->add('http://...'); $page->save(); Or if you want to delete a specific image: $image = $page->images->first(); $page->images->delete($image); $page->save(); // commit the deletion $page->images->add('http://...'); $page->save(); Note that when you add() an image, if you are pulling from an http:// address then your PHP must support allow_url_fopen. Some web hosts have this disabled, though most don't.

Static hooks apply to all instances of a class, whereas direct instance hooks apply to just 1 instance (the one you assign it to). For example, you'd use a static hook if you wanted to hook into or add some new method to all Page instances. Whereas, if you are hooking any API variable ($session, $pages, $modules, etc.), it's better to use a direct/instance hook since there is only ever going to be 1 instance of those variables anyway. While you could use a static hook anywhere, direct hooks are a little more efficient because they are stored with the actual object instance rather than in the larger pool of static hooks. Meaning, direct/instance hooks result in less for ProcessWire to sift through when executing hooks (though it probably doesn't matter much in the larger scheme of things). But this is also the reason why they aren't prioritized together, as they are stored in different places.

I've asked again if they can produce any examples of open source projects that are integrated and distributed with Redactor. So if we can follow some other project's lead, then that's cool with me. But so far it doesn't seem like any freely distributed open source project actually uses Redactor. I'm hoping they'll reply with an example or two though (they must be out there). One possibility is that we could use an older version, which is CC-noncommercial licensed. Can't exactly distribute it with ProcessWire itself, but could distribute as a free module: https://github.com/dybskiy/redactor-js

Glad you got it working. Static hooks ("Session::login") are treated separately from direct hooks. The direct hooks are more specific so they get executed before the static ones. But I wasn't really thinking much about priority level when building this, so not sure if that's the way it should be or not.

That's correct. At least, that was the intention. It's one of those things I thought would come in more handy than it has… I'm not aware of it ever being used. So I think the only time it has even been tested is when I originally coded it in there (at which time it was working). No recent confirmation of current functionality though. A quick glance in the code seems to indicate that it should work as intended, though please let me know if you find otherwise. Default priority level is 100 (that's what gets assigned when none assigned).

Unless you can find some way to use the existing user pages for this purpose… They are protected under the admin, somewhere you probably don't want your public users going. But like you saw, it's pretty easy to make any other page behave as a user page by using URL segments. So that's probably the way I'd do it.

Good to know there is still an RSS available. But if it's only for a few months, it's probably not the long term solution we need for this module (though great that it buys us some time). Is Twitter going out of business or something? Just wondering why they are closing things down. It seems unusual because the natural result of this change will be for people to create their "tweets" elsewhere… relegating Twitter to be a carbon copier rather than a source. Obsoletion. The last version of my "oneliner" software (for Wildcat BBS) came out in 1993. Now thinking I need to make a new version for ProcessWire.