LostKobrakai

Is there a way to limit module access in the backend by page-id? Without the needed permission the whole module isn't accessible, while, with the permission given, each instance of the module is viewable. I would need the user to only be able to access few instances of those existing ones.

wireRenderFile does not inherit variables by default, that's not possible in php. But you can pass variables manually. // basic-page.php $js = "something"; $content = wireRenderFile("views/page", array("jsToFile" => $js)); include("./_main.php"); // views/page echo $jsToFile;

I suggested this already earlier in the thread, but if you're only using Reno and many custom modules the space can really be beneficial. As you said you're always free to limit it by yourself.

https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users

It would be nice if the "user-picture" functionality would support alternate user templates.

Is the field set up to unarchive zips? Maybe the unzipping is causing a timeout.

Did you follow the whole tutorial? More explicitly, did you change your hosts file? The apache conf doesn't even get called if you do not forward requests to your own apache? To be sure just follow through the whole tutorial and everything should work.

upload_max_filesize oder memory_limit?

It's dependent on what you did add to your hosts file. The example in the tutorial adds "127.0.0.1 processwire", which means: If someone asks for "processwire" serve 127.0.0.1. So your "domain" for the browser would be "processwire". You could also use any "domain" here, so "dev.localhost", "project.dev". "dev.project.com" would all work.

How about you're hitting the max_execution_time of php?

I'm talking about this error I'm getting under your provided link: "Warning: session_name(): session.name cannot be a numeric or empty '' in /sites/rhosonics.nl/www/index2.php on line 176" We're talking about database charsets, so there isn't a "same charset". If uft-8 is available there shouldn't be any errors. I'm not sure, but processwire should only try to set the encoding at the installation process if the database is not already existing. Did you use this or did you import the database otherwise? Seems like there are more queries using the configured charset.

The files do go into the htdocs folder. It's your root folder you've on servers. How to access them depends on your configuration.

Which version of ProcessWire are we talking about? Also make sure that at least in wire/config.php there's a sessionName variable existing, which should be default, but somehow your site is throwing an error about this. About the sql error: Are the mysql instances the same? If not are the same charsets supported and the same versions installed? The error quite clearly states that something with the encoding doesn't work, so did you check that you used the same charset on the clients host as on the local installation.

Sorry my bad. If your php server instance isn't even looking for a .htaccess file it cannot throw any errors, therefore my links wasn't to useful. "It works" is a replacement if apache doesn't find any viewable files under the provided path. Put your processwire files there and it should show these.

Seems like a .htaccess issue. I'm not sure your php command will start a server instance that can evaluate htaccess rules. You'd need a running apache server or something equivalent. To test your .htaccess file read here: http://processwire.com/docs/tutorials/troubleshooting-guide/

It seems Juergen is not talking about the "actual" template of a page, but the template of an edited page. There's a function on ProcessPageEdit to get the page you're editing (ProcessPageEdit::getPage). You really need to understand the fundamental difference between the frontend and the backend. The frontend is rendering the pages themself, while the backend actually consists mostly of pages with linked process modules (the ones you see in the page-tree as children of "Admin"). So the page being rendered in the backend is always the process, not a potential page being edited. If a process is showing a specific page you would need to ask the module to tell you which page it is. ProcessWire won't know. It's kinda like if you would use urlSegments on the frontend. The $page objects is always the same, but depending on the segment you're rendering a different UI. ProcessPageEdit does work the same. The $page object is the process, but it's rendering the form depending on the passed page ID.

Also keep in mind, that even the page-editing page in the backend isn't "$page->template == 'pricelist'". It's a hidden page of the admin template with the process PageEdit and it just shows the specific page values / edit form. Not all of them. Users for example aren't, but you can only access the process pages.

If you need different tags per language then language alternate fields are the way to go. That's not a problem.

Maybe it's already possible. I'm just not sure if the variable will be available to the hook. wire()->addHookAfter("InputfieldPage::processInputAddPages", function($event){ $inputfield = $event->object; $addedPages = $inputfield->pagesAdded; // Change what you need to });

The problem lies mostly in the interface. It's just not possible to reliably set up multi-language pages by using this textarea. The implementation may be flawed, but really the whole process of adding pages is not great. If you really want those tags to be translated you still need to open the tag's page and add translations. At this point you could've also added the whole thing manually. Not activating the default language makes sense, as the core cannot be certain, that users want untranslated content to show up. As the function creating the pages is already hookable Ryan should just return the new pages and everyone could hook after the creation and add their own logic.

I'm not using comments, but I would look here: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Fieldtype/FieldtypeComments/CommentNotifications.php But it seems they are already using wireMail, so they should be sent by the smtp module.

Oh, didn't read that closely. That not possible right now. I'd suggest posting this over at GitHub. The addition of the pages could easily be made extendable.

Nope I meant "wrap" as "line-wrap". On narrow fields sometimes the icon is still in the first line, while the text is already wrapped to the next one.

True, but depending on the use-case this doesn't have to be an issue. // _init.php // do not overwrite sys variables $templates, $template $filelessTemplates = new TemplatesArray(); foreach($templates as $templ){ if(!is_file($templ->filename)) $filelessTemplates->add($templ); } // elsewhere $pages->count("…, template!=$filelessTemplates");

There may be nothing to do about this. The database cannot know that your page is not viewable because of the missing template file. Therefore you need to check viewability at runtime, no matter how you'd do that. About your performance concern. You could cache the viewability of pages in an global field and check again only after a certain timeframe.