BitPoet

Looks like I have. Found a classic case of shoot-your-foot in the affected installations where I generously added some JS in a ProcessPageEdit::execute hook, my InputfieldFile change was wholly innocent. What I did find was a race condition between the first few added files, so there was one upload more active than configured in the beginning. I believe I caught that with a setTimeout. I still have to tweak that timeout, run a few more test drives and meditate over reasonable defaults, inline documentation and such, but it's taking shape.

Have you tried this: $regionEvents = $pages->find("template=veranstaltung,selectLocation.parent.parent=$reg,limit=$limit"); If this doesn't work, a subselector might be the tool of choice: $regionEvents = $pages->find("template=veranstaltung,selectLocation=[template=location,has_parent=$reg],limit=$limit");

Yes, it looks like the new PHP version is missing the Ctype extension. Either the package needs to be installed or the entry in php.ini needs to be added/enabled.

I'm not sure he will. Generally, a new feature needs to be used by an estimated 30% of users to be accepted into the core. There are, however, exceptions to the rule - especially where hosting issues are concerned. I'm not happy with my adaptions yet, though, since they work on some installations here but not on others. I'm still on the lookout for the issue there. However, once I work out the kinks, and if the change doesn't have to get more complicated, I think it could have a good chance to be accepted (adding a feature request at processwire-requests and finding others who vote for it would certainly help).

This not really a deciding point, but about awareness that constants (as they are always static) are, just like static properties, subject to early binding. A lot of code (even mine, I have to admit) uses self:: to reference class constants and static properties, which is going to cause headache whenever such a class is extended and a constant or static property is changed. To be inheritance safe, any code that references such a value needs to use static:: instead of self:: (or address the property through the object instance). A short illustration: <?php class A { const one = 'ONE'; const two = 'TWO'; public static $three = 'THREE'; public static $four = 'FOUR'; public $five = 'FIVE'; const six = 'SIX'; function showMe() { echo self::one . PHP_EOL; echo static::two . PHP_EOL; echo self::$three . PHP_EOL; echo static::$four . PHP_EOL; echo $this->five . PHP_EOL; echo $this::six . PHP_EOL; } } class B extends A { const one = 'UNO'; const two = 'DUE'; public static $three = 'TRE'; public static $four = 'QUATTRO'; public $five = 'CINQUE'; const six = 'SEI'; } $b = new B(); $b->showMe(); That in mind, I guess the decision depends on a few questions: Is the code that is using the value executed often? In that case, constants have a small but perhaps noticeable performance advantage. If not, does my IDE of choice favor one over the other between constants and static properties? May the naming be changed at run time for an individual instance of the class? In that case, the actual value bearers have to be instance properties. For the later case, I like to use a mixed approach where my initial values are declared as constants (though a static property would be just as good) since they jump the eye: <?php class TestClass { const CLASS_PREFIX_DEFAULT = 'tpl_'; public function __construct() { $this->class_prefix = static::CLASS_PREFIX_DEFAULT; } //... } I try to avoid static access through $this:: (last line in the showMe() method above) as much as possible for my own sanity, as my head wants to make an immediate connection to instance access once it sees $this, and I'll likely end up with expressions like $this::$staticVariable, which to me looks too much like $class->$memberName, yet behaves differently.

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.