BitPoet

A bit of a wild guess, but maybe there's something messed up in the FileCompiler cache (site/assets/cache/FileCompiler). Cleaning that out and checking that the web server user is the owner might be worth a shot.

But we can at least see that it's an InputfieldFormBuilderFile object. Since FormBuilder Inputfields inherit (I took a peek into the code) from the regular Inputfield class, you can refine your debug output to only show its value attribute (you're already reading $font->attr('value') - it's the way to go with all form fields). I'm pretty sure it's going to be some kind of array. wire('log')->save('form-builder-debug', print_r($image->attr('value'), true));

I think $image is likely an array of file paths. What I like to do in such cases is to dump the variable in question to a PW log. wire('log')->save('form-builder-debug', print_r($image, true)); This should give you a clue when you look into Setup -> Logs -> form-builder-debug.

You need to use wire('pages')->findOne() to retrieve your fontPage, find() returns a PageArray. Before adding the image, set $fontPage->of(false). Also, you have single quotes around $image.

Hehe, There are days, and there are days like these. At 0.0.9 now, even refactored the code a bit and added syntax highlighting for embedded PHP snippets. I think I'll call it a day now though.

Perhaps an issue with .htaccess? Try the first approach to set up the copy to check that, but replace the .htaccess file with a stock one. Otherwise, one of the log files involved should have more information - apache error log, mysql error log, php error log and last but not least site/assets/logs/errors.txt.

Just a missing dot. $this->files->copy(__DIR__ . '/templates/', $this->config->paths->templates);

New release: 0.0.6 Adds support for template files as well.

Aaand... Version 0.0.4: Also displays docs for not installed modules.

Version 0.0.2: Includes PW core classes as well and strips special #pw- comment tags Ryan uses to generate the official API docs.

I've realized that I've been jumping back and forth between the PW API docs and the source code for site modules far too much. The idea to hold all necessary documentation locally in one place has occurred to me before, but getting PHPDocumentor et al set up and running reliably (and producing readable output) as always been too much of a hassle. Today I was asked how I find the right hooks and their arguments, and that inspired me to finally get my backside down on the chair and whip something up, namely the Module Api Doc Viewer ProcessModuleApiDoc It lets you browse the inline documentation and public (optionally also protected) class/method/property information for all modules, core classes and template files in the ProcessWire instance. The documentation is generated on the fly, so you don't have to remember to update your docs whenever you update a module. The module is quite fresh, so expect some bugs there. Behind the scenes it uses PHP-Parser together with a custom class that extracts the information I needed, and the core TextformatterMarkdownExtra module for rendering the description part in the phpdoc style comments. This is not a replacement / competitor to the API Viewer included in the commercial ProDevTools package. There is quite some information included in the inline documentation that my module can't (and won't) parse, but which makes up parts of the official ProcessWire API docs. This, instead, is a kind of Swiss army knife to view PHPDoc style information and get a quick class or function reference. If you feel daring and want to give it a spin, or if you just want to read a bit more, visit the module's GitHub repository. This is the overview page under "Setup" -> "Module API Docs": And this is what the documentation for an individual class looks like: The core module documentation can of course be found online, but it didn't make sense not to include them. Let me know what you think!

Are we talking SimpleXml here? In that case: <?php foreach ($xml->anbieter->immobilie->anhaenge->anhang as $anhang) { if ($anhang['gruppe'] == 'TITELBILD') { $object->object_header_img = $anhang->daten->pfad; } else { $object->object_images->add($anhang->daten->pfad); } } No reason to loop over the attributes.

After looking into the code, adding support for a parallel uploads limit wasn't too hard, I think. If you're willing to try, I've created a fork of the current PW dev branch and added that functionality. This lets you set a configurable limit for how many uploads happen at once, the rest is queued and processed as soon as others finish.

I'm not so sure about that. AFAIK, PW has its own Ajax upload implementation in InputfieldFile.js and doesn't queue uploads at all.

In addition to what @elabx suggested: have you looked into the browser's developer console to see if there is more information about the problem (console message, HTTP reply)? Is the file actually saved in the file system (/site/assets/files/[PAGEID]/ folder)? Also, it may be worth increasing the value for the max_input_vars setting in php.ini. I remember that I encountered a similar issue to yours because of that setting.

Good question. I doubt that MarkupSimpleNavigation does this, my guess goes more towards the template code it is used in. The "1" likes to appear when you accidentally output the return value of include(), most common when mixing up <?= and <?php (but "echo include('something.php')" has been encountered in the wild too). The "Array" points towards an echo $something where $something is an array. It might even be another <?= vs. <?php issue like this one: <?= $myvar = array(1,2,3); ?> So, to get to the culprit, check your PHP open tags first, then look for superfluous "echo" calls.

Not necessarily in a noticeable way, but I'd expect that it would sooner or later bite you in the backside. If another redirect happens for any reason (https upgrade, change in subdomain, etc) beforehand, Google sees two consecutive redirects when accessing / and immediately penalizes you. Outside of web apps, I try to use redirects only for two reasons: either the site moved to a different domain, or the path to a page changed. That's the way I would do it. And make sure that you also set a canonical header in your home page that points to the Location-1 page so search engines know to treat them as one page instead of duplicated content.

The link above is broken.

Searching for values of page reference fields assigned to images is unfortunately not fully supported (yet?). All custom fields for an image are stored in the database as a single JSON string, so things get a bit tricky there and the regular subfield logic of PW doesn't work. What does work is searching for numeric page ids or full page paths. $pages->find('images.tagpage=1098') should work, as should $pages->find('images.tagpage=/tags/funny/'). $pages->find('images.tagpage.title%=tagtitle') won't work.

Image Magick has a policy.xml file somewhere in /etc where its default limits are configured - usually quite permissive, but different distributions may ship their own limits for maximum image width / height, memory limit, map (disk cache) limit etc. as explained here https://www.imagemagick.org/script/security-policy.php. I have no idea if/how these policies are honored when called from PHP, but it might be worth taking a look.

Are there actual width or height limits (usually given in KP) in policy.xml that your image might hit?

Just a typo, a missing ">" in this line, $item->children-count() vs. $item->children->count(). <?php if($item->children-count()): // if there is a child page, loop through all the child page ?>

Here's a somewhat versatile, albeit not overly beautiful to look at (in the backend) approach using Hanna Code. It's not really wysiwyg in the backend, but it's easier to maintain than hardcoding stuff in the template. A short step-by-step instructions (looks more complicated than it really is): Download and install Textformatter Hanna Code module Download and install Hanna Code Dialog module Go to "Setup" -> "Hanna Code" and create a new Hanna code, let's name it "languagelink", with type "PHP" and the two arguments "targetlink" and "linktext". In the "Code" tab, add the following PHP code: <?php if(! empty($targetpage)) $tgt = $pages->get($sanitizer->pagePathName($targetpage)); else $tgt = $page; $url = $tgt->localUrl($user->language); echo "<a href='{$url}'>{$linktext}</a>"; Go into the configuration of your CKEditor field. On the "Details" tab, add the Hanna Code Textformatter, which will then be applied to the field content each time it is rendered: On the Input tab, go to the CKEditor Toolbar settings and add HannaDropdown on its own line, which will add the menu entry for CKEditor: Now you have everything set up and can start inserting your languagelinks. Edit the page in question. You'll now find the menu entry "Insert Hanna tag". Click that and select "languagelink". Enter the path to the target page and the text for the link there. Your Hanna Code is now in the CKEditor field. Save the page and view it in the frontend. Page viewed in the default language: Page viewed in language "en":

I did a bit of digging in the code, and it seems the example in the blog post is outdated. PW nowadays always increments page names for new pages if a page with the same name and parent already exists (that appears to have changed with release 3.0.127). ?

There's a small but important difference between wire() and $anything->wire(). The first is the wire() function defined in Functions.php and documented here. The other is the Wire::wire() method you linked to. The first one just retrieves values but can't set them. So it's more of an inconsistency between those two than a bug.