Webrocker

hi, I have no problems with a 3.0.185 currently, but wait with the update after reading this ?

My bad - it is working in the current dev version (3.0.185), not the master.

Hi, I updated to the currently latest master (3.0.184) and now a lister (listerPro 1.1.3) preset shows the info cited in the title. According to this closed issue this is supposed to work <del>in 3.0.184</del> https://github.com/processwire/processwire-issues/issues/1428 or is this a lister(pro) issue?

Hi neophron, sorry for the year-late answer. I think the first part of your structure, up to the "... will be redirected" (more on that in a bit), is managable in ProcessWire. I have a(n old) MultiSite setup that basically is the same. I have not bothered about the language at all in the $config->MultiSite, and have the what you call subdirectories, managed with the MultiLanguage set up, where I can define the "slots" for the language on the root (pid=1) page. this results in mydomain.global/ => / is the "name/slot" of the default language (en) mydomain.global/de/ => /de/ s the "name/slot" of the first language (de) mydomain.global/it/ => /it/ the "name/slot" of the 2nd language (it) and so on. In the $config->MultiSite: $config->MultisiteDomains = array( "mydomain.global" => array( // domain name is used to map to root page "root" => "mydomain.global", // page name for the root page "http404" => 27 ), "mydomain_second.global" => array( // domain name is used to map to root page "root" => "mydomain_second.global", // page name for the root page "http404" => 27 ), This works fine. What I haven't tried yet, is to redirect in one of those domains directly to a translation. I could do this with a .htaccess rewrite or maybe with a session->redirect() in ProcessWire, but with the inherited set up that "/" is the default language, AND a redirect from "/" -> "/de/" for example, it is difficult to switch back to the default language on that site. I wonder if "mydomain.global" => array( "root" => "mydomain.global/de/", "http404" => 27 ), would work, though. EDIT: nope. this does not work, I just tested it

Ah! ?Thank you. This is very good to know.

this file then needs to be in site/templates/, so site/templates/_init.php (but can be named anything you want) the cool thing is, you can still decide on a individual template setting level (under templates -> edit -> files) to NOT prepend this file, or to prepend a different file. Same goes for $config->appendTemplateFile, where you could state an always after the template file. see https://processwire.com/api/ref/config/ -> "Template files"

Hi, I'm wondering if I now stumble upon an intended behavior or if this has changed between PW2.6 and later Versions (I'm on a PW3 master currently, but with ooold templates). I have a use case where a newsletter is created (with the Help of the MailChimp Newsletter module) based on a news page/article and where the editor can preview the newsletter content. Before the update to PW3 (says the editor) it was possible to have the origin news page unpublished (so it is not visible in the front end), but preview the newsletter showing the referenced news' page contents. In the newsletter template there is a` if ($page->newsletter) { $n = $page->newsletter; ... } ` condition, where $n then "feeds" other content variables in that template. `$page->newsletter` is a page reference field and in there the origin news page is selected. but this page is unpublished - and `$page->newsletter` is false for that template. (I played around with the other options for the page reference input field, as an array it would be empty in this case). Now I'm wondering, since the news page is referenced and selected in that field (I have the option on to allow unpublished pages for the selection), why can I not access this (unpublished) page in my template? And, has this changed compared to earlier PW versions? My editor insists that this was possible before the update. Is there a way to "get" the referenced (but unpublished) page (ID) for this template usage? thanks, Tom

Hi Robin + Adrian, thank you, will have a look and if I come up with something, will PR. cheers, Tom

Hi, Imagine this setup: a "images" field (or a "file" field) in the page's basic template, lets call it "files" for the rest of this post. In the front-end, a list (or a gallery) is rendered, when "files" are uploaded and saved at that page. The editor created a page "documents", uploaded several files over the course of weeks, and later decides, that it would be smarter to make subpages for some sort of grouping of said files. Is there a way for the backend editor to "move" files from page A file-field to page B file-field in the backend without the need to re-upload them? I know that this could easily be done via the API or even by moving the files from assets/files/1234/ to assets/files/5678/ and modifying the "page_id" in the field_file table. But I thing this would be a nice addition to the editor's experience, if the already uploaded files could be transferred across pages, if the same fields are used. I know that the editor could link from the new page's text/body to the files "living" at the old page, but in my setting, where the front-end tries to look for files directly at the page level to spit out a list, this isn't so great. I also know that this is maybe a higher order design "problem" -- if I'd expect a greater flexibility regarding images or files, maybe I should work with dedicated "file"-template/pages, and use page-fields for the then file references. It is just that I came across this small innocent question from a user of a very small uncomplicated site, where the above happened. No big deal, we got it sorted, but it made me think. ? cheers, Tom

Thanks @Robin S @kongondo , will make an submitted an issue on github: https://github.com/processwire/processwire-issues/issues/772

Ok, I think you are referring to the "Table" field; but my issue is with the "PageTable" field. ?

Ah. But this is the interesting thing; I downloaded a plain new processwire w/o any additional modules. installed it locally with a new db. The module was already there, needed only to be activated. I think this used to be a ProField, but now is core, but kept the name (?)

@jmartsch that link seems broken? (btw I'm fine with moving to a more fitting place, posted here b/c I wasn't sure which module or the combination of modules and non-standard settings causes this) ?

Hi, there are some things that need to come together to reproduce this, so not sure if this is a bug, but since this fell on our feed in a production site just now, I wanted to document it here. Happened in production with a 3.0.33, tested additionally with a fresh empty local ProcessWire 3.0.98 Master in "blank" profile. Modules needed to be active: ProFields:PageTable v0.1.3, Page Clone (Core) v1.0.3. Settings (see settings.png attached): Have a dedicated page where the PageTable elements are to be stored (so not save them as a child of the page that has the PageTable field) Have the "Page behaviors" set to unpublish an element when its parent is unpublished Steps to reproduce: Create a page with the PageTable field. Create some content items with the page table field. Publish the elements and changes to the page. Look in page tree at the page that stores the PageTable elements. As is to be expected, you see the elements, published. Now, click on the name of the page with the PageTable field, and choose "copy" from the actions (this only appears when you have installed the PageClone core module). Now you have a (unpublished) copy of the first page. Look again in the page tree for the stored PageTable elements: Now you have twice as many elements, and ALL are unpublished. So by duplicating a page, the contents of the original page are altered/unpublished. Since this is unexpected and happens without any indication to the editor, this creates a bad situation esp. for pages where already a mix of published and unpublished PageTable elements has been before. Expected behavior: Leave the original page and Pagetable elements alone ? aka wouldn't expect that making a copy of a page will alter the published state of the origal page's contents. Also (not directly related to this effect) expected to see the copied PageTable Elements suffixed with "(Copy)" in the page tree, as it happened with the copied page. See screenshots for illustration.

hi, I would create the sections as sub-pages in the backend: - onepager -- section a -- section b ... -- section n For the onepager contents, you can query for the 'onepager' children and loop them out into the sections markup. For the id attribute you can use the childpage's id, like 'id="section-{$section->id}"': $onepager = $pages->find('selectorfortheonepagerpage'); // i.e find('/name-of-the-onepager'), find('template=onepager_template') $onepagerSections = $onepager->children; if($onepagerSections->count){ foreach($onepagerSections as $section) { echo '<section id="section-'.$section->id.'">(..........)</section>'; } } ... In the same way you can build the navigation, using the section id for the anchor. no need to use the simple nav render, just loop over the onepager children once again and build your navigation markup with "a href="{$onepage-r>url}#section-{$section->id}" ... if($onepagerSections->count){ echo '<ul>'; foreach($sectionNav as $item){ echo '<li><a href="''.$onepager->url.'#section-'.$item->id.'">'.$item->title.'</a></li>'; } echo '</ul>'; } ... This could be optimized to go in one loop, creating two output variables, one for the nav, one for the sections, and echoing them out later, but for illustration purposes I think this'll work. cheers, Tom