Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Webrocker last won the day on August 17 2015

Webrocker had the most liked content!

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

3,385 profile views

Webrocker's Achievements

Sr. Member

Sr. Member (5/6)




Community Answers

  1. Hi Robin + Adrian, thank you, will have a look and if I come up with something, will PR. cheers, Tom
  2. 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
  3. Thanks @Robin S @kongondo , will make an submitted an issue on github: https://github.com/processwire/processwire-issues/issues/772
  4. Ok, I think you are referring to the "Table" field; but my issue is with the "PageTable" field. 🙂
  5. 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 (?)
  6. @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) 🙂
  7. 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.
  8. 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
  9. 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
  10. 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
  11. 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 :-))
  12. 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
  13. 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
  14. 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.
  15. 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); }
  • Create New...