ryan

Thanks! We need all the backlinks we can get. Always much appreciated. Some of my clients don't want anything to say who made the site or what it's running, so I totally understand there are many cases where it's simply not possible too.

Thanks diogo!

Thanks for finding a solution here Soma. I will test and add to the core source.

It seems like a great way to do it. Admittedly, i'm not quite at the level with Git where I understood everything that was going on in that tutorial (and you just motivated me to put in an order to Amazon for a book on Git). But this seems not far off from what I'm already doing to keep my PW installations up-to-date, as well as 3rd party modules. I've not used Git submodules before, so that's something new to me. Currently I'm keeping my 3rd party modules as individual repositories. Since I'm running multiple PW sites on one server, I'm using symlinks to link in any modules I want with a site (1 repo per module, shared among multiple sites). It seems really simple, so not clear what advantage submodules would have over this. Though there may be some significant differences in the file layout structure of Symphony and PW that necessitiate the approach they are using. But like I said, you motivated me to buy a book so I can put some real time towards getting more in depth with Git. I have a feeling I'm missing something obvious. Ultimately I'd like for people to be able to add and update modules from the admin without having to go through version control or even their file system. It'd be great if they could just plug in a URL to the module and then have PW take care of installation and notifying them when it needs an update. That's a ways off, but I'm just thinking that it's got to be as easy as possible. To me, the people using Git to manage their site are more the hard core users and open source developers that really know their way around, and that's just one segment of our audience. I think that almost all the PW modules are available on Git at present. Usually we'll post to the forum for test versions, and then post to Git once things are pretty well set and ready for distribution. This is what I'd recommend for all modules. Perhaps this should be a pre-requisite to be listed in the module directory on the new site.

It sounds like a bug, but it's actually just something that's not automated in the system (and I'd forgotten that it wasn't). A page checks for changes when something is set or added to the page itself. But a property down two levels of objects is not something a Page knows internally to check (and it wouldn't make sense for it to). So that object has to instead notify the page, or at least its parent object, that something has changed. So it's something that I think I can automate, but it's one of those things I'd want to do a lot of testing with to make sure I'm not screwing up anything else. So in the short term, I would suggest continuing to use the $page->trackChange method to let the page know about the change. In the future when this is built in, it won't be necessary, but also won't hurt anything to keep it there. The reason this isn't an issue with PageEdit (for example) is that PageEdit doubles up on change tracking by checking the Inputfields themselves for changes. It basically does this: if($inputfield->isChanged()) $page->trackChange($inputfield->name); Btw, the purpose of change tracking is so that PW can avoid the overhead of saving all fields on the page, and instead just focus resources on the fields that have actually changed.

I'm worried about implying that one is editing the properties of the field within the context of the template. Whereas a field is something that exists separately from a template and can be used by any templates. As we move forward, I would like to have a way for fields to have a template context, so one could modify their labels or behaviors according to the template they were placed in. Once we've got that, then I think the edit links will be right at home. This one will be easy! We've got the ProcessPageSearch built to support selector queries, so it could be done with a simple link to: /processwire/page/search/for?template=basic-page (or substitute name of template) I agree about dropdowns, and this is something I will definitely be adding to the default admin theme. I like what Soma has done here too. Though I want the template names and field names to be directly selectable from the second level of the dropdowns as well. The only reason dropdowns aren't already in place in the default admin theme is that I'm determined to get this multi language support in place before anything else.

Martin, do you know if there are any documentation/demonstrations/videos of Symphony's method here online? Just looking for a good starting place to read more about what they are doing in this respect.

Pete, thanks for your great work on this module!

drilonb, in your case it would be more efficient to use PW's built in pagination. The only reason Robert Zelnick had to use the method he did is because he wasn't working with pages. Pages are built for pagination, so they have things to make it more efficient and easier. When you call 'children' without any selector, it has to load all the children. If there are hundreds or thousands, that could be lot of unnecessary overhead. This is a preferable way to do it with pages: // only has to load $limit children $pages->get('/events/')->children("start=$start, limit=$limit"); Whereas this is not a good way to do it with pages: // has to load ALL children $pages->get('/events/')->children->slice($start, $limit); Also, using the "start=" isn't necessary when using built-in pagination because PW does that automatically behind-the-scenes from the page number. Though you can certainly use it, but it's just not technically necessary. Lastly, when using built-in pagination for your 'next page' link, you want to use $children->getTotal() rather than count($children). The reason is that count($children) would only have $limit items, whereas $children->getTotal() would have the total number of items if it had loaded them all. So you'd want to replace this: if($start + $limit < count($pages->get("/events/")->children)) { …with this: if($start + $limit < $children->getTotal()) { And there's no need to keep your own $start or $limit variables since PW is already keeping them for you. So you could just do this instead to determine whether to show a 'next page' link: if($children->getStart() + $children->getLimit() < $children->getTotal()) {

That's correct, the template has to manage access to control what it's behavior will be here. Otherwise, it'll inherit the behavior from what parent is defining access.

There's actually nothing wrong with using the PHP vars like $_GET and $_POST (or $_REQUEST if necessary). But ProcessWire saves you the step of having to check for magic quotes, so it's usually easier to use the ones that PW supplies. But if you are checking for non-string type stuff (that would never have quotes) then it doesn't matter much what you use.

I agree with all this. Though the languages module lets you specify date formats, and I was thinking the InputfieldDate would be able to pick up the date formats from the language definitions. But still thinking about this one. I didn't want to put a lot of work into the date Fieldtype until we had the multi language stuff down because it seems like the two would ideally go together.

Thanks for your work in testing this stuff. The way it works is that a checkbox label is supposed to toggle the on/off state of the checkbox. So when you've got something like <label><input type='checkbox' value='1'> Click Me</label>, clicking "Click Me" is supposed to toggle the checked state. So in the case of that trash icon, the icon itself is the label, while the checkbox is hidden.

Can you try adding this right before your save? I'm wondering if this makes it save: $page->trackChange($field); // where $field is the name of the field, 'images' or whatever it is

Thanks for posting this Sevarf2, it's good and interesting to see one approach to this. One thing I wanted to mention in your code for checking existing email, it's preferable to sanitize the value before including it in a selector. Less important, but it's also preferable to get it from wire('input') rather than from something like $_GET, $_POST or $_REQUEST since it will account for annoying server-side settings like magic_quotes. So here would be an update to that script: <?php require_once('../index.php'); $email = wire('sanitizer')->email(wire('input')->post->email)); $sql_check = wire('users')->find("email=$email"); if(count($sql_check)) { echo 'false'; } else { echo 'true'; } Also I recommend leaving the closing PHP tag "?>" out if it's the end of the file. The reason is that it's unnecessary, and causes problems if any whitespace happens to end up after it. Of course the whitespace is invisible, so it leads to difficult to find bugs. Best just to skip the ?> at the end of the file.

Nice job Jasper, thanks for posting! Makes me want to take a trip to Stockholm.

Just wanted to mention that the default for $session->redirect($url) in PW is a 301 (permanent) redirect. If you want a 302 redirect then give it a second param of false, i.e. <?php $this->session->redirect('http://processwire.com'); // 301 permanent redirect $this->session->redirect('http://processwire.com', false); // 302 temporary redirect http://processwire.com/api/variables/session/

What error message are you getting? If you export the structure of the field_$name table using your field, what does the structure look like? (can you paste in)? Since you are keeping $img->crop as an array, do you have something in your sleepValue that converts it to a string (like the CSV one I mentioned) or something to keep it consistent with the format needed in the DB?

For your new Fieldtype, I'm assuming you are extending FieldtypeImage or FieldtypeFile. There are a few methods you'll want to override to provide your new cropping fields. I'm using CSV rather than JSON here just because it seems like it would take up less space in this case, and be almost as simple. Though you could also take the approach of just making each of the cropping fields individual parts of the DB schema, but I'll go with CSV for this example. <?php public function getDatabaseSchema(Field $field) { // use the existing parent schema $schema = parent::getDatabaseSchema($field); // and add new field with CSV cropping info (x1, y1, x2, y2, w, h) $schema['crop'] = 'varchar(60) NOT NULL DEFAULT '''; return $schema; } // function called to convert values from DB to Pagefile/Pageimage public function ___wakeupValue(Page $page, Field $field, $value) { if($value instanceof Pagefiles) return $value; $pagefiles = $this->getBlankValue($page, $field); if(empty($value)) return $pagefiles; if(!is_array($value) || array_key_exists('data', $value)) $value = array($value); foreach($value as $v) { if(empty($v['data'])) continue; $pagefile = $this->getBlankPagefile($pagefiles, $v['data']); $pagefile->description = $v['description']; if(!empty($v['crop'])) { list($crop['x1'], $crop['y1'], $crop['x2'], $crop['y2'], $crop['w'], $crop['h']) = explode(',', $v['crop']); } else { $crop = array('x1' => 0, 'y1' => 0, 'x2' => 0, 'y2' => 0, 'w' => 0, 'h' => 0); } $pagefile->crop = $crop; $pagefile->setTrackChanges(true); $pagefiles->add($pagefile); } $pagefiles->resetTrackChanges(true); return $pagefiles; } // function called to convert the pagefiles to array ready for DB storage public function ___sleepValue(Page $page, Field $field, $value) { $sleepValue = array(); if(!$value instanceof Pagefiles) return $sleepValue; foreach($value as $pagefile) { $sleepValue[] = array( 'data' => $pagefile->basename, 'description' => $pagefile->description, 'crop' => implode(',', $pagefile->crop), ); } return $sleepValue; }

First thing to try is to edit /site/config.php and locate this line near the bottom: $config->dbLowercaseTables = true; Change it to false. Then see if it starts working. If that doesn't do it, change it back to true and lets see if we can rename the table manually. If you don't have easy access to PhpMyAdmin I can post a quick PW code bit that'll do it for you. But lets wait and see if that is even necessary first.

Not sure how you had it before, but I think that the script would have to be added before ProcessPageEdit::execute rather than after. I'm not sure I understand about the level of the page–and can't think of any reason it would matter. But if you find it's doing this in a before(execute) hook, let me know and I'm sure we can track it down.

Did contactname have any uppercase characters in it? I'm just wondering if it's a database upper vs. lowercase thing that didn't translate through the upgrade.

I think what you are looking for is the Page fieldtype, which is the one used by ProcessWire for handling single and multiple selection. With this fieldtype, you can utilize selects, checkboxes, radio buttons, asmSelect, PageList select, etc.

To add something to the settings tab, hook into ProcessPageEdit::buildFormSettings It returns an InputfieldWrapper that you can append() or prepend() fields, or you can even do something like this: <?php $wrapper = $event->return; $templateField = $wrapper->get('template'); $myField = wire('modules')->get('InputfieldText'); $myField->attr('name', 'hello'); $myField->label = "Hello there"; $wrapper->insertAfter($myField, $templateField); $event->return = $wrapper; But I think it's better to just append or prepend to the the wrapper, because you don't really know for sure which fields will be active on the settings tab. Also note that on some pages, there is no settings tab.

This is relatively minor, but I realized a lot of us were repeatedly using the same code to populate a required 'name' field when creating new pages via the API. As a result, I figured I'd build it in. Here's the commit note: Previously if you tried to save a page without a 'name' field it would throw an exception. Now it won't, as long as the page has a title. This should not affect any existing code. But it does mean that future page imports may be a little simpler since you don't have to consider the 'name' field.