Autofahrn

Use $item->images instead of $product_gallery->images in your inner foreach loop.

Ok, so this differs from my symptoms. I've rechecked some of my sites and saw my various workarounds and also have a single language site with single file field explicitly set to array return. On other sites I've used a different workaround, which also fixes my language flag issue. Setting output formatting on before accessing the image, otherwise the field returns PageImages array instead of PageImage, so my loop now looks like: $languages = wire('languages'); foreach($languages as $l) { $l->of(true); // ensure $l->svg_image returns a PageImage $imgUrl = $l->svg_image->url; Output formatting is obviously off for some reason for the default (first) language if current session is not on default language. Just realized that on my other site (where I use SVG flags on the language template) I've also switched the field return to Array. So maybe this is more deterministic than I thought and indeed probably related to multi language sites.

Since I'm a software guy myself, I prefer reporting only if I am able to provide steps to replicate the issue. Since I couldn't find any rules for this one yet, so decided to stay quiet. Maybe not the best choice... Regarding the multi-language feature I probably can check If I had this on one of my single-language sites (easy, just check for single file fields set to return an array).

There is a Textformatter to get rid of the enclosing p tags. Go to Modules->Install and select Textformatter, there you should find "Paragraph Stripper". After installation go to your inputfield and on the Details tab add that textformatter. But be aware that CkEditor generates markup, so paragraphs are intentionally embedded in p tags, and CkEditor can generate plenty of other tags as well. If you only need plain text, then not selecting CkEditor is probably the better choice.

IIRC, I also encountered this randomly on sites without language support.

Well said, @LostKobrakai, things getting even more complicate for "beginners" when it comes to the various output strategies, only few are mentioned here: https://processwire.com/docs/front-end/output/ I'd probably recommend to jump into the tutorials and create some pages/templates to find out what fits your individual needs and requirements: https://processwire.com/docs/tutorials/

Seems I'm not alone encountering strange issues with File fieldtype configured for single items. I'm not sure if my symptoms relate to this one, but they are similar weird (work on one site/situation, fail on others). On one multi-language site I've added a single file to the language template which holds a SVG of the flag. The SVGs retrieve correctly for one language, but exactly one SVG can't be retrieved if the user is running from another language (I can try to replicate if required). Did the same on another site (using the same code) where it works ok. This does not relate to the language setting itself, I also saw a similar behavior with the same field used on different pages (can't remember exactly). As my personal workaround I've switched those fields to always return an array, even if they only hold a single item. Happens across any PW 3 version I've encountered so far.

Moving PageTable items between pages still seems to miss an official solution, so I'll bring this up again. Just stumbled into that myself after resorting some items between "categories" (parent page containing the PageTable field). My solution was rather crude, since I've simply removed the associated rows directly in the database and re-create the PageTable container using the existing "add child" mechanism. I guess it shouldn't be too difficult to use the same mechanism to detect orphaned entries (contained in the array but not a child) and offer a similar option to remove them.

Still no luck with sorting repeater items in the backend? I see the items nicely follow the sort settings in pagetree, but the order within the inputfield always stays the same.

Sorry, still not clear what you intend to do. For me a "friendly" url (seen in address field of your browser) would be "/autor/division-men". In that case the URL in the browser would read "autor.php?id=division-men", but the content is organized as regular pages in ProcessWire. The obvious question is, where are these URLs coming from? Something legacy? If you only want to tidy up such legacy URLs to friendly pathnames, I'd suggest sending a redirect to the client, which could be accomplished with a simple template. Create a new page template first, name it redirector, for example. On the URLs tab disable enforcement of a trailing slash for such pages ("Should page URLs end with a slash?" -> no). Then create a page using that template and name it autor.php. To be clear, I really mean the name of that page: Create the template code for the template, would be site/templates/redirector.php containing something like this: <?php namespace ProcessWire; $docsRoot = $pages->get('/docs/'); // Point to root where to search $pageName = $input->get->pageName('id'); // Get sanitized page name from GET parameter if($pageName && ($pg = $docsRoot->findOne("name=$pageName"))->id) // Find "the" page { $session->redirect($pg->url); // never come here! } // didn't work, throw 404 in this case throw new Wire404Exception(); So, if your client enters "autor.php?id=division-men" as the URL, he'll be redirected to "/docs/division-men" in this case. Note: $page->findOne requires PW 3.0.116+

Hello @gerrmen, welcome to the forum! Can you explain a little bit more about the why? For me its currently unclear if the client sends the parameter URL (?id=division-men) and you try to map this to regular pages, or if the client should send a friendly url (/ autor/division-men) and you want to process that one with php. If the latter is the case, then you don't need to modify your .htaccess but want to use URL segments instead. Your template processing the /autor page would then have to evaluate whatever comes next in the URL.

If this is the line with the error, then $home would be null.

When go to your template (Blank-Page), you should see a yellow bar like this: So, did you follow the hints from the two other variants of this question? Reading the docs, creating a template file named "Blank-Page.php" in your site/templates folder and placed your code there?

Blind shot: Could the PHP version had been changed on that site (hard to believe this could cause such an issue, though)?

For me removing the uk-width-expand from the inner div (the one with class=' uk-width-1-1@s uk-width-1-2@m uk-width-4-6@l uk-width-expand pk-col-bod') seems to fix it (not verified other aspects of the layout). But I won't consider a width of 1700 pixels to be a quite big resolution nowadays.

You mean something like UiKit's Scrollspy, Transition or Animation? That's regular CSS which you generate in your output and depends on your css framework (UiKit, Bootstrap, Bulma etc.), no special module required.

Ok, DOMDocument drives me crazy. It does not properly work without a surrounding container, so I've changed the loadHTML as follows: $dom->loadHTML('<div>'.mb_convert_encoding($str, 'HTML-ENTITIES', 'UTF-8').'</div>', LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD); This, of course, needs to be cleaned up at the end, which I quick&dirty done like this: // strlen('<div>') = 5 $markup = substr(trim($dom->saveHTML($dom)), 5, -6); The trim is required, since the return of saveHTML ends with a newline and I don't want to hard-encode this using -7 for the length parameter of substr, sigh. Edit: changed <dummycontainer> to <div> to make loadHTML happy.

Just realized that saveHTML automatically adds doctype and <html><body> frame around the content (from PHP 5.2.6). Edit: For PHP >= 5.4.0 better change loading the HTML from $dom->loadHTML(mb_convert_encoding($str, 'HTML-ENTITIES', 'UTF-8')); to $dom->loadHTML(mb_convert_encoding($str, 'HTML-ENTITIES', 'UTF-8'), LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD); https://stackoverflow.com/questions/4879946/how-to-savehtml-of-domdocument-without-html-wrapper http://php.net/manual/de/libxml.constants.php so that should be removed using something like (5.2.6 <= PHP < 5.4.0) : // Remove added doctype/html/body added from saveHTML $markup = preg_replace('/^<!DOCTYPE.+?>/', '', str_replace( array('<html>', '</html>', '<body>', '</body>'), array('', '', '', ''), $markup)); http://php.net/manual/de/domdocument.savehtml.php#85165

To have configuration fields for your fieldtype (displayed on the config tab) you'll need to implement ___getConfigInputfields(Field $field) in your Fieldtype class. To specify allowed overwrites you'll need to implement ___getConfigAllowContext($field) in your Inputfield class. As examples you may look at wire/modules/Fieldtype/FieldtypeTextarea.module and wire/modules/Inputfield/InputfieldTextarea.module. Edit: Please note that FieldtypeTextarea.module actually pulls additional configuration field from the InputfieldTextarea, so this is not a simple example for creating the config inputfields. A more straight forward example for ___getConfigInputfields would be wire/modules/Fieldtype/FieldtypeText.module.

Or use the option manager with a fixed string, something like this: $field->save(); // save field first $manager = new \ProcessWire\SelectableOptionManager(); $manager->setOptionsString($field, __("Yes\nNo"), true); $field->save();

@Steve_Stifler, if you are thinking database-wise, this probably needs some refinement. The database behind PW indeed has a table "Pages" which holds vital information about a particular page, which includes its unique identifier, the identifier of its parent page, the assigned template and a name, to name a few, but no real data. It primarily defines the pages location within the page tree. Data, in contrast, is stored in individual tables which directly relate to a particular field. One row of such a field table contains "the value" (like a string, integer etc.) and the id of the page, to which this particular row belongs to. For this reason a particular field can only exist once on a page (you may, of course, have multiple fields using the same fieldtype assigned to the same page). So, if a page hosts 10 fields, then accessing the data of these 10 fields requires access to 10 tables of the database (which is cached in PW, so you do not need to bother with that). On the other hand, with PW it is rather simple to create own fieldtypes which refer to multiple database columns. So, if your standard row of data consists of 10 values, you may create an inputfield holding exactly these 10 values, which are stored in a single row of a single table. As long as you can define your data from the existing inputfield types, creating own fieldtypes is really a no-brainer.

Sure that the error refers to RepeaterPageArray in that particular line? Should be RepeaterPage instead. And if it refers to RepeaterPage, are you sure running 3.0.126? Just tried on 3.0.126 and it works as expected.

Tiny explanation: The new directive only creates a fresh instance of a PHP class in memory, in this case a DateTime and a DateTimeZone object. The latter is initialized to 'Europe/Berlin' and used as the timezone parameter for initializing the DateTime object, which, in turn, is stored in variable $ct. Nothing affects the system.

All my test sites run from a virtual server managed by Plesk with NGINX in front of apache. Never had to bother with any configuration details, PW installs without any special attention to .htaccess or similar. It simply works out of the box for me.

Just in case someone else stumbles over this, you'll need to modify these lines at the end of method format() in TextformatterPrism.module: $markup = $dom->saveHTML($dom->getElementsByTagName('body')->item(0)); $markup = ltrim(rtrim($markup, '</body>'), '<body>'); Into this: $markup = $dom->saveHTML($dom->getElementsByTagName('body')->item(0)->nodevalue); Reason is, that ltrim/rtrim do not trim strings but character groups. So they do not stop after the <body> tag but continue to strip any following char if its one of "<>bdoy"... Using nodevalue (or textcontent) from the body element eliminates the need for the trim.