LostKobrakai

If you're already trying to build menus manually an not automated from the page tree, then you should take a look at kongondo's menu builder module.

document.write('<script src="site/templates/' + scriptUrl + '"></script>');

While I liked the idea of having a new method, which would provide an encrypted id (autogenerated salt like for the user passwords) I don't think there's any necessity to change the underlying id system, especially as this is a default behaviour of mysql. Do you have any usecase examples, where this would be needed?

$alltags = explode("|", $page->thumbnail->tags);

I'm not sure what exactly you mean by frontend developers, but everyone, that does have access to your php files, does essentially have full superuser access over the whole application. E.g. everyone of those can just append ", include=all" to any selector and call it a day. For anyone else it's not about how secure pw's api is, but how much access you as a developer are providing the potential user via your own interfaces, may that be an api or a website or whatever.

If you're using a js loader of sorts there's almost certainly a base-folder setting, which probably needs to site/templates.

Maybe it's the max_post_vars limit of php? 160 * name, sort, desc, delete, tags would mean ~800 of them only for the image field alone.

@Wanze The thing we're currently missing a bit here in central europe: snow. Nice animation diogo. The snow stacking on the logo is a lovely and unexpected feature Merry Christmas and nice holidays to you guys as well.

Crawlers do not have any php versions only servers do (otherwise this would be a gaping security hole). So that's certainly not the problem. But you're missing head and body tags, which while technically optional in html5 are still needed by lots of crawlers.

That's the wrong file. WireArray is just about runtime selection: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Pages.php#L310-L336

get() is just another name for findOne(). findOne() is the actual implementation. If access control is needed one does need to use find() or override the "FindOne" option to false.

I wasn't talking about mithril as framework, but just how it's handling markup generation, which is also based on abstract functions.

Having access control even for single page retrieval is quite simple. You'll need this only if there's user input in the selector anyway, which at least in my case is the exception. $page = $pages->find("…, limit=1")->first();

It's basically that in both admin theme's default.php files: --- /Users/Benni/Projekte/ProcessWire2/www/html/wire/modules/AdminTheme/AdminThemeReno/default.php +++ /Users/Benni/Projekte/ProcessWire2/www/html/wire/modules/AdminTheme/AdminThemeReno/default.php (Unsaved) @@ -129,7 +129,7 @@ <a class="action" href="<?php echo $config->urls->admin; ?>login/logout/"><i class="fa <?php echo $adminTheme->signout;?>"></i> <?php echo $helpers->_('Logout'); ?></a> </span> <?php endif; ?> - ProcessWire <?php echo $config->versionName . ' <!--v' . $config->systemVersion; ?>--> © <?php echo date("Y"); ?> + ProcessWire <?php if($user->isLoggedIn())echo $config->versionName . ' <!--v' . $config->systemVersion . '-->'); ?> © <?php echo date("Y"); ?> </p> <?php

You may like the syntax, that mithril.js is using.

This sounds useful, but I'm not sure about sending all request (assets!) through php-fpm, even if they could be directly served.

I'm just not using my name at all

It's actually more wise to have different fields in that instance, as you can apply any changes, which may be needed in future iterations, separately. Grouping them together just for the sake of having them grouped doesn't do you any favor.

Now that's strange. There should at least also be the guest user (id 40) in that table. Do you have a db backup? You could also try to add the line for your superuser manually.

No it's just a single field, go to the field_language table and look for the id of your superuser (41 by default) and change the data field to the id of the language you had before.

Did you try to change the superusers language via phpmyadmin? At best back to the language you had before.

PW 3 does use namespaces, so either it's an issue with the compiler, so please try using correct case ("PageArray()") or the file is not supposed to be compiled and therefore does need the namespace "ProcessWire/PageArray()".

Do you have LanguageSupportPageNames installed? The error code does state, that it cannot find the db column name1051 for the pages table, which is the column for the pagenames of the language with the id 1051.

Just make sure to keep the right thing in mind: Output formatting needs to be of if you're editing any fieldvalue of a page, especially if you're trying to save it afterwards. There's no correlation to pagearrays per se.