adrian

Small issue with the debug tools in the API variables section. Everything under the name column is white (not visible) due to: #footer a { color: white; }

Always such great videos kongondo, and a great module too. Just also thought it worth mentioning that several of the 3rd party themes out there all display last created / last edited in either a sidebar, or at the bottom of the page, eg: Moderna and MetroWire. It's often as simply done as something like this: foreach($pages->find('limit=5, sort=-modified') as $p){ if ($p->editable()) { echo "<li><a href='".$config->urls->admin."page/edit/?id={$p->id}'>". date('d.m.', $p->modified) ." " . $p->title . "</a></li>\n"; } }

Something you could do in terms of creating the full table automatically: function maketable($pageid){ $current_page = wire('pages')->get($pageid); echo "<table>"; foreach($current_page->fields as $field){ if (strpos($field,'DMC_') !== false) { echo "<tr> <td>{$field->label}</td> <td>{$current_page->$field}</td> </tr>"; } } echo "</table>"; } maketable(xxxx); This will create the entire table for you from just the ID of the page and will make a table row for each field that contains "DMC_" in it's name.

Yeah I know but I can't see removing any of the options - I do like how configurable it is. Thanks for the width overwrite - it looks much better now.

Martijn has a very good point. I was off a little in my advice last night. In PW it is possible to specify a global label for a field, and also a label specific to a template. This is also true for the description and the column width, visibility etc. An even shorter way to get the context specific label would be simply: echo $page->fields->$field->label;

Hey Soma, Just noticed that with the new modal installation dialog, things can get a little crowded with the config settings for some modules, in particular my Custom Upload Names. I am wondering if you'd consider making the modal window larger - perhaps most of the window - maybe 95% width and 95% height - just enough of a reduction that it is still obvious that it's a popup. The alternative, in the case of my module anyway, might be to not float the settings side by side. If you think it's better to keep it small, then I'll look into that possibility.

You can get the label within your function like this: echo wire('fields')->$field->label; The details of the field (like the label) are part of the $fields array, and not the $pages array if that makes sense.

Try wrapping $current_page->$field in curly brackets like: {$current_page->$field}

davo, I am not sure what you are trying to achieve with $page->$current_page->$field, but you already have the page represented by the ID of $pageid in $current_page, so you should just be able to do: $current_page->$field Also, even if it was necessary, $page wouldn't work inside a function, you'd need wire('page'). Try that and let us know how you go. PS For debugging purposes, try this in your function: echo "label: $label<br />field: $field<br />pageid: $pageid"; just to make sure you have what you think you have in those variables.

Does anyone actually know exactly when this ends? Is it midnight on the 31st GMT/UTC? I have a feeling it will come down to who is on it right at the end, so it would be good to know when that is and in what timezone!

It is working fine for me on stable and dev versions of PW. That description field is stored directly in the alt field in the RTE. Do you have any unusual TinyMCE settings that could be causing it?

I have been getting the core tab on all my installs for several months now. Not sure what would cause it not to show up.

Ok, sorry for my confusion. $this->page is what is used in modules in place of $page - it's effectively the same thing. $page and $this->page will always reference the current page. Remember that URL Segments are not pages. They are just a way to pass variables to a page so you can control the content that is being output. I guess you're trying to apply the text formatter to the content that is being pulled in from page x, but I think I would need to see your template code to get a better idea of what is going on. Maybe someone else can visualize it already?

Have you read this: http://wiki.processwire.com/index.php/URL_Segments From what I think you want to do, you need to refer to x as: $input->urlSegment1 But then if x is a url segment, then I am not sure how it can have other fields, which is what you describe. Perhaps x is the name of another page somewhere in the PW tree? If so, then you could do: $pages->get("name={$input->urlSegment1}")->field_you_are_after_from_page_x But maybe I am completely not understanding what you want here!

I don't think TCPDF (the library used by this module) supports css background images. It can set background images (http://www.tcpdf.org/examples/example_051.phps), but I don't think it can convert from a css background image. Depending on your needs, you might be better off manually coding the creation of the PDF, rather than using this module. That way you can use all the options in the TCPDF API, or even use a different pdf generating library - there are lots out there. Of course this won't work if you want all your site pages to be available as PDFs, but it is possibly a better option if you just want to generate something specific like an invoice.

Have you set: $config->sessionFingerprint = false; in your config.php ?

A couple of PW modules: https://github.com/jdart/FieldTypeRate https://github.com/apeisa/CommentRatings Also some other relevant forum posts: http://processwire.com/talk/topic/2126-rudimentary-5-star-rating-system/ http://processwire.com/talk/topic/3630-need-slight-variation-on-existing-module/ Hope something in those is helpful.

I'm afraid I have to run out in a few minutes so won't be able to help more today, so I am going to have to leave you in someone else's capable hands for now. The key thing though is that 500 error being returned when trying access: http://[website]/contact/contact-form/ I would definitely recommend trying the module's demo files exactly as they were and see if that works so you can figure out a working starting point again and modify to your needs. Hopefully that way you can figure out where you went wrong. Good luck.

Ok, I now understand that you are using: http://modules.processwire.com/modules/form-template-processor-mailer/ and not: http://modules.processwire.com/modules/form-template-processor/ My fault for not noticing "Mailer" in the title of your initial post. Let me get my head around this other module and I'll see what I can figure out.

I still think it would be helpful to see all your code. Does contact/contact-form have a template file available? I noticed this is your first post: D:\WAMP\www\client_emerald\site\templates\_inc\php\contact-form.php Just wondering why the template file is not at the root of the templates folder. I can imagine doing something like that for actual include files that aren't assigned to PW pages, but in this case I think you need this to be linked to contact/contact-form, but again, I am not exactly sure how you have things set up.

Hi, and welcome to PW. Did you have a read of the usage instructions here: http://modules.processwire.com/modules/form-template-processor/ That error message suggests that you haven't set the template for the form. As per the instructions, something like: $form->template = $templates->get('my_contact_form_template'); // required Please try that and see how you go, and also post the code you are using in your template to display the form so we can help figure out where you are going wrong.

Well you could do that by using render in your template: echo $referencedPage->render();

Hey Nico, I installed a local copy of latest dev yesterday without a db password. Are you installing stable or dev?

Hey Ryan, I will update the GitHub repo for sure. I was hoping to improve the hook for uploading via the API first though - I'd really like to delay the rename until after the file has been copied into the assets/xxxx folder so I am not messing with any file manipulation code that a front-end form might use. If it uploads the file to a temp directory and then makes the api call to install the file, eg: $page->images->add("/local_temp_path_to_image/image.jpg"); then the form won't know the new filename and so won't be able to delete the file from the temp location. Also, some of the front-end upload scripts posted to this forum suggest moving the file to the final assets/xxxx folder before using ->add, in which case the Pagefile::install won't even be triggered. I'd also like to be able to support images being added from an external URL. Any thoughts on how best to achieve all these requirements? My post #28 above talks more about the issues with Pagefile::install and the need to run it as a before hook, but the problems that also causes. I am sure I must be missing an obvious option.

I know I am hijacking this, but teppo brought it up first Although, I am not sure that anyone outside Australia got these ads, but they played for a long time when I was growing up! I'd also like to see an option for the color scheme to be chosen during installation!