Robin S

Related?

Awesome, I think that's a great plan. ?

Hi Margaret, Maybe you could attach or link to one of the original images that is exhibiting the problem to see if anyone else can reproduce the issue?

If you have a large number of images in the gallery it would be better not to load all the pages into memory only to display a portion of them with slice(). Better to use start and limit in your selector to get only the pages you will display. You could adapt the example given here:

Works for me too, but would depend on what $config->urls->root is (e.g. if developing in a subfolder?) If it's just MSN you are concerned about the simplest thing is to use the features built into MSN for just this purpose. Either then "xitem_tpl" option or a "getItemString" hook: // MSN hook for external_link template $nav->addHookAfter('getItemString', function($event) { $child = $event->arguments('page'); if($child->template == 'external_link') { $event->return = "<a href='{$child->link_url}' target='_blank'>$child->title</a>"; } });

Did you copy the .htaccess file? Does your server support mod_rewrite? It's a good idea when considering moving to new environment to first run the PW installer as this will check to see if the environment is compatible. If all good you can delete the installation and copy over your existing files and DB. Also see this: https://processwire.com/docs/start/install/troubleshooting/#the-homepage-works-but-nothing-else-does

The relative dates will come via WireDateTime::relativeTimeStr().

I can reproduce. Seems like a bug. Issue here: https://github.com/processwire/processwire-issues/issues/826

I'm not sure what's going wrong in your module, but maybe it helps you to look at this proof of concept module which adds a config field named "Animal" to every field and allows setting the field in template context. ExtraFieldConfig.module <?php namespace ProcessWire; /** * * ExtraFieldConfig * * @author Robin Sallis * * ProcessWire 3.x * Copyright (C) 2011 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class ExtraFieldConfig extends WireData implements Module { /** * Module information */ public static function getModuleInfo() { return array( 'title' => 'Extra Field Config', 'summary' => 'Test module for adding and extra config field to Fieldtype config.', 'version' => '0.1.0', 'author' => 'Robin Sallis', 'autoload' => true, 'requires' => 'ProcessWire>=3.0.0', ); } /** * Ready */ public function ready() { $this->addHookAfter('Fieldtype::getConfigInputfields', $this, 'addConfigField'); $this->addHookAfter('Fieldtype::getConfigAllowContext', $this, 'allowContext'); } /** * Add config field * * @param HookEvent $event */ protected function addConfigField(HookEvent $event) { $field = $event->arguments(0); $wrapper = $event->return; /* @var InputfieldText $f */ $f = $this->wire('modules')->InputfieldText; $f_name = 'animal'; $f->name = $f_name; $f->label = $this->_('Animal'); $f->value = $field->$f_name; $wrapper->add($f); } /** * Allow setting config field in template context * * @param HookEvent $event */ protected function allowContext(HookEvent $event) { $allowed = $event->return; $allowed[] = 'animal'; $event->return = $allowed; } }

@fmgoodman, you could experiment with different values for $config->sessionFingerprint (add the line to /site/config.php) to try and track down the issue. See the $config docs and the code comments for Session::getFingerprint().

If the page you are loading in the iframe is on the same domain as your site you can get the title by finding it within jQuery contents() - google it for details. If the page is not on the same domain then you cannot get the iframe contents (and therefore the title) via Javascript. You could get the page contents via PHP (e.g. PW WireHttp) and use DOMDocument or similar to find the title, but the simplest thing might be to use an external API like http://textance.herokuapp.com/index.html Would be smart to cache the title for a while with WireCache.

You would need to exclude by ID withing the children selector or else the first page of $news_archive would be an unequal quantity (or empty depending on the value of feed_count_full) because pages would be filtered out after they are found. $news_archive = $page->children("template=news, id!=$news_full, limit=50"); If all of the results are appearing on the same page (no pagination is used) then you can achieve it without needing a second DB query... $news = $page->children("template=news"); $news_full = $news->slice(0, $page->feed_count_full); $news_archive = $news->slice($page->feed_count_full);

It wasn't working when I checked shortly after the OP posted - the "/about/" portion of the URL was missing IIRC. Must have been fixed since then.

@bluellyr, your screenshot shows a modal. Make sure you do not have the Tracy debug bar disabled for modals in the module config: @adrian, I wonder if it would be better to not have Tracy disabled for modals by default, and people can disable it if they are finding the debug bar annoying. And perhaps spell it out that no debug bar = errors if you try and use a dump method.

Both of these are the same and they work like this: $files->send($page->file->filename); And you can force the download for file types that might otherwise open in the browser like this: $files->send($page->file->filename, ['forceDownload' => true]);

Without steps to reproduce I doubt Ryan could/would do anything about it. Might be best to wait until you notice it again in a situation where Custom Upload Names is not involved and raise an issue then. I do think it's odd that the formatted/unformatted value should be different with regard to temp files - I'll open an issue for this. Edit: issue is here.

You haven't said what method you are hooking, but it sounds like if the page is not yet saved the logical thing would be to either hook after Pages::saved or else to save the page within your hook before you try and get the images from it.

Aha, great that you have found the source of the issue. In terms of a bug report, I don't expect anything can be done to guarantee to always successfully remove the temp status in all circumstances - I guess there can always be upload glitches of one sort or another. But what would be helpful is to make sure that files with temp status are removed when a page is (re)loaded in Page Edit, so you are not scratching your head wondering why you can see an image in the field that isn't accessible from the API. The thing is, I thought this already happened, which is why if you upload an image then refresh without saving the image is removed from the field. So I suppose it could be a matter of working out why an image with temp status is remaining in the field and is not removed.

I know how this feels. I'm sure there is some core issue with the admin login that semi-regularly gives me CSRF errors when I attempt to log in but I haven't been able to isolate the conditions to reproduce it - my gut feeling is that it's something to do with an expired cookie. I'm always in a hurry when it happens so I just back button and resubmit the form. To get to the bottom of your issue I expect it could be traced by dumping within the chain of methods that get the data from the database and ultimately deliver the formatted value. But who has time for that when you're on a deadline?

As discussed above, I'm thinking that it is somehow related to multi-language features. I don't work on multi-language sites which might explain why I've never seen it across dozens of sites. I use this option on every site, but never with the "Automatic" option - I prefer to always set the formatted value manually to align with the max files.

Very strange, I've never experienced such a thing before. A couple of ideas... 1. Any chance there is a name clash for "document_pdf" on $page - something setting a custom property named "document_pdf" on the $page object? 2. Does changing the field name to something different fix it? Then maybe change it back to the original name and check again.

I don't believe any such solution is possible. PW relies on SQL for sorting in $pages->find() selectors and SQL doesn't support natural sorting. So I think you'll have to do one of the following: 1. Load all the pages you want to sort into memory so you can sort them with PHP. Not a good solution if you have a large number of pages. 2. Request that content editors insert leading zeros to the numbers you want to sort on, so that standard SQL sorting will be sufficient. This would be subject to human error/oversight and would probably need to be done in a separate field to allow the title field to remain in the desired format without leading zeroes. 3. Use a saveReady hook to automatically parse titles into components and save these to dedicated sort fields. This seems like the most promising option to me. An outline of how you could do option 3... Add 3 new fields to the painting template: prefix (text), number (integer), suffix (text). Add the following hook to /site/ready.php: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'painting') { // Find the last number in the title and get the prefix/suffix before/after the number preg_match('/^(.*\D)(\d+)(.*)$/', $page->title, $matches); if(count($matches)) { // There is a number so populate each sort field $page->prefix = $matches[1]; $page->number = $matches[2]; $page->suffix = $matches[3]; } else { // There is no number so put the whole title into the prefix field $page->prefix = $page->title; $page->number = ''; $page->suffix = ''; } } }); When a painting page is saved this results in a division of the title like below. You would set the visibility of the sort fields to "hidden" for production but I have shown them below for clarity. Now when you want to find painting pages sorted naturally you sort on the three sort fields in order: $paintings = $pages->find("template=painting, limit=10, sort=prefix, sort=number, sort=suffix"); You can sort the painting pages (children of a page with the "paintings" template) in the back-end with this hook: $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); $page = $event->arguments(1); // If page is the parent 'paintings' page if($page->template == 'paintings') { // Set the children selector to sort on the three sort fields $selector .= ', sort=prefix, sort=number, sort=suffix'; $event->arguments(0, $selector); } });

Thanks for the info @adrian. I think for this specific case I'll write a custom import script. I'm already using a custom script for exporting the data so will be pretty straightforward to whip up an equivalent import script. Will definitely spend some time playing with BCE later though - looks really nice.

Hi Adrian, I need to import data to existing pages from CSV and am wondering if BCE might be a solution. I've read the GitHub readme and the module looks like a powerful beast but I'm not quite clear on a few things. 1. My data includes a Profields Textareas field, with the data for the individual subfields in separate columns. My guess is that this will require a custom import script (e.g. using AdminActions) but thought I'd check first to find out if BCE supports importing to fieldtypes that contain subfields. 2. I'm sure this is a silly question, but when BCE is enabled for a page or template in the config options this is for the parent of the pages that you want to batch edit, right? So when it comes to mapping columns to fields BCE is looking at the template of child pages under that parent? Does this mean the module can only work where there is a single allowed child template under the parent? 3. I have BCE set to Update mode but on my first attempt at importing a CSV I get an error message saying that the number of columns in the CSV doesn't match the number of fields in the template. Does this mean any CSV that is submitted for import must contain a column for every field and only columns for fields that exist in the template? There isn't a second step where you connect column headings to field names and can selectively import some columns while ignoring others? 4. The readme mentions CSV field pairings but I'm not sure where this is configured. I couldn't see anything about this in the module config. 5. Does BCE support a Page ID column in the CSV data, so there can be a rock-solid connection when importing data to existing pages? And if I use an ID column can I leave out page name and page title data from the CSV so I don't risk accidentally changing those? Sorry for all the questions, and thanks for the module!

I created this module a while ago and never got around to publicising it, but it has been outed in the latest PW Weekly so here goes the support thread... Unique Image Variations Ensures that all ImageSizer options and focus settings affect image variation filenames. Background When using methods that produce image variations such as Pageimage::size(), ProcessWire includes some of the ImageSizer settings (height, width, cropping location, etc) in the variation filename. This is useful so that if you change these settings in your size() call a new variation is generated and you see this variation on the front-end. However, ProcessWire does not include several of the other ImageSizer settings in the variation filename: upscaling cropping, when set to false or a blank string interlace sharpening quality hidpi quality focus (whether any saved focus area for an image should affect cropping) focus data (the top/left/zoom data for the focus area) This means that if you change any of these settings, either in $config->imageSizerOptions or in an $options array passed to a method like size(), and you already have variations at the requested size/crop, then ProcessWire will not create new variations and will continue to serve the old variations. In other words you won't see the effect of your changed ImageSizer options on the front-end until you delete the old variations. Features The Unique Image Variations module ensures that any changes to ImageSizer options and any changes to the focus area made in Page Edit are reflected in the variation filename, so new variations will always be generated and displayed on the front-end. Installation Install the Unique Image Variations module. In the module config, set the ImageSizer options that you want to include in image variation filenames. Warnings Installing the module (and keeping one or more of the options selected in the module config) will cause all existing image variations to be regenerated the next time they are requested. If you have an existing website with a large number of images you may not want the performance impact of that. The module is perhaps best suited to new sites where image variations have not yet been generated. Similarly, if you change the module config settings on an existing site then all image variations will be regenerated the next time they are requested. If you think you might want to change an ImageSizer option in the future (I'm thinking here primarily of options such as interlace that are typically set in $config->imageSizerOptions) and would not want that change to cause existing image variations to be regenerated then best to not include that option in the module config after you first install the module. https://github.com/Toutouwai/UniqueImageVariations https://modules.processwire.com/modules/unique-image-variations/