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

Hi, you first need a backend template for your users that has the fields you want to work with. think of the fields in a template as the columns of a row of data for the 'table' (here: "user", most times "page") (actually this is not how it works under the hood, but it helps to think of it this way in the beginning); the standard user template just has the minimum (data)fields required, aka name, password, and email and a bit of meta things. so to work with your new field 'fullname', you need to create a field 'fullname' in the admin, then apply this field to a new template (for example 'user_extended'; this template should have all the fields of the regular user template, plus your newly created one(s)) or. You can extend the user-template with your new field(s), by editing the user template (and setting the list to include system fields). once you have the template applied to the 'user'Once your field is in the user template, your $userObject->fullname = blablainputfield->fullname will work (assuming that the field for the full name in the template is named 'fullname'). hope this helps to get you started, Tom

Hi, I'm excited -- this feature now has found its way into the recent code base Thank you @Robin S for the initial nudge and @ryan for adapting this. https://github.com/processwire/processwire/pull/18#issuecomment-258186824

ok, I took the plunge an created a pull request: https://github.com/ryancramerdesign/ProcessWire/pull/1979 (I think it is a good omen that its ID is one of my fav songs of the Smashing Pumpkins :-))

Hi, Does the page/template in question has the view permissions set for the guest user? Seems like the check for the right permission goes wrong. According to the debug code, if you are logged in as a super user, this check won't happen -- this would explain why it works if you're logged in. cheers Tom

Hi, is it possible to have the result of an "search" selector like this one $matches = $pages->find('template=basic-page|journal__item|link__item,title|heading|subheading|excerpt|body%=' . $sq,limit=50); ordered by the number of matches, so that the pages where the searched term was found more often will be the first in the listing? (I don't think so, since the "%=......" looks for an occurance, and that's it, and since the fields are coupled with an "or", no info on how many times the searched term was found is available, right? -- but too often ProcessWire surprised me with its cleverness, so I thought I ask :-)) cheers, Tom

Hi, I'd give it a go -- I'm working with the 3.n on several production sites w/o any issues. But I am using only few non-core modules, mind. The only thing to look out for is the namespace addition; this presented me with some initial blank screens, due to not having it in the config.php <?php tag.

hi, just looked it up in my 3.0.30 install. seems the limit was raised with the 3.n version… public function init() { parent::init(); $this->setAttribute('rows', self::defaultRows); $this->setAttribute('maxlength', 1024*32); $this->set('contentType', FieldtypeTextarea::contentTypeUnknown); } protected function setAttributeValue($value) { if($this->maxlength > 0 && $this->hasFieldtype === false) { $value = $this->wire('sanitizer')->textarea($value, array( 'maxLength' => $this->maxlength, 'maxBytes' => $this->maxlength*3, 'stripTags' => false, )); } else { if(strpos($value, "\r\n") !== false) { $value = str_replace("\r\n", "\n", $value); } } if($this->stripTags) $value = strip_tags($value); return trim($value); }

Hi, where is this limitation set? Is that a ckeditor/handling consideration? The data column of a textarea field is "mediumtext" -- which can store millions of chars? Edited: For reference, here's a discussion about saitizer length and db limit: cheers, Tom

Yes, this is what I'd say. Can you find any similarities when or where the truncation happens? Is it after n characters or always after a certain char? Can you check the field table with phpmyadmin or something similar if a "tinytext" or a kind of charlength restriction is stated there? attached is a screenshot of my "body" textarea field. "mediumtext" indeed caps the amount of data the field will save, but shuld be enough for average sites (http://stackoverflow.com/questions/13932750/tinytext-text-mediumtext-and-longtext-maximum-storage-sizes#13932834 cheers Tom Edited: Hm, maybe the textarea() sanitizer is applied anyways, which would limit the amount to 16384 chars? http://cheatsheet.processwire.com/sanitizer/properties-and-methods/sanitizer-textarea-value-options/

I could have sworn that this was an option in the fields settings -- but I just looked up and down in my install (3.0.30) and the only reference to maxlength I found is in the $sanitizer options for text/textarea, which is not what I had in mind. Jut to make sure; you don't have a charset mix-up between what your site delivers and what your database expects? (just asking because I had such truncation issues back when WordPress moved from ISO-Latin to UTF-8, and weird things happenend with a utf-8 frontend saving into iso-latin DB tables and the other way round…) cheers Tom