adrian

You might try making use of php's is_array to test the page field to decide if you need to foreach it and echo with commas between specialities etc, or just echo directly. Have a go and let us know if you need help. EDIT: Also, check out rtrim to remove the last comma at the end of your list. Also, just noticed that you have a typo: Average Fyling Time

What a waste of time, but I have managed to narrow down the debug accordion/source truncation issue to the ProcessPageDelete module and this code: public function addJavascript(HookEvent $event) { $js = ' <script type="text/javascript"> $(document).ready(function() { $("li.PageListActiondelete a").live("click", function(el){ if(!confirm("Are you sure?")) { return false; } }); }); </script>'; $event->return = str_ireplace("</head>", $js.'</head>', $event->return); } I am still not completely sure why it is breaking things and especially why only on one installation, but what I did was move that JS code into it's own file and call parent::init(); to have the module automatically load the ProcessPageDelete.js file. I'll submit a pull request to Nico.

Several options, but this post should get the juices flowing: http://processwire.com/talk/topic/2480-sort-children-by-the-sum-of-two-fields/

Speaking of the debug section, would you be opposed to this change so that it can be toggled closed again? $(document).ready(function() { $("#debug").accordion({ header: 'h3', heightStyle: 'content' }).hide(); $("#debug_toggle").click(function() { if ($('#debug').is(":hidden")) $("#debug").slideDown(); else $("#debug").slideUp(); var n = $(document).height(); $('html, body').animate({ scrollTop: n },'50'); return false; }); });

That's the weird thing though - the end of the debug.inc file looks perfect: <script type="text/javascript"> $(document).ready(function() { $("#debug").accordion({ header: 'h3', heightStyle: 'content' }).hide(); $("#debug_toggle").click(function() { $("#debug").slideDown(); $(this).hide(); var n = $(document).height(); $('html, body').animate({ scrollTop: n },'50'); return false; }); }); </script> Oh and I have already grabbed the very latest dev from today and deleted the old wire completely first. I'll keep investigating.

Ok, there is only one id of debug on the page. If I run that jquery from debug.inc in the console, it applies all that styling as it should. Turns out the page source was ending like this: <script type="text/javascript"> $(document).ready(function() { $("#debug").accordion({ header: 'h3', heightStyle: 'content' }).hide(); $("#debug_toggle").click(function() { $("#debug").slideD and generated source as: <script type="text/javascript"> $(document).ready(function() { $("#debug").accordion({ header: 'h3', heightStyle: 'content' }).hide(); $("#debug_toggle").click(function() { $("#debug").slideD</script></div></div><ul style="display: none;" tabindex="0" id="ui-id-1" class="ui-autocomplete ui-front ui-menu ui-widget ui-widget-content ui-corner-all"></ul></body> Weird!

Unfortunately there are no JS errors - not sure what the issue is here! I don't think I have seen "New Admin Theme" anywhere else either, but it had exactly the same config settings as Default Admin Theme" except that is was in the site modules. I did already get rid of it by uninstalling and deleting the folder from site/modules. Interestingly it couldn't be deleted using the new functionality via modules - the delete button wasn't there. The site/templates-admin was gone already and I believe wire was properly fully replaced. Anyway, I don't think this is likely to occur again with any luck.

I feel like I am interrupting a more important dialogue here, but another weird thing. I have some installs that look perfect, but at least one is not showing the debug accordion properly at all. The div is just: <div id="debug"> instead of: <div id="debug" class="ui-accordion ui-widget ui-helper-reset" role="tablist" style="display: block; overflow: hidden;"> which means everything loads completely open with no accordion styling at all. The broken one is a local install, but I also have a local one that is working fine.

Another quick comment. On one install that I have been updating, I ended up with two admin modules: "New Admin Theme" in the site modules section, as well as "Default Admin Theme" in the core section. I am sure this won't be an issue for new installs, but might be worth investigating for upgrades, although quite likely it won't happen anymore - I am guessing it was some specific recent version that installed the site "New Admin Theme" and this probably won't happen again, but thought I should report it just in case.

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 ?