Leaderboard

Just in case anyone was wondering why I've been silent for the last week, it's because I've been away on vacation, so have a lot of catch up to do here (didn't have internet access while I was gone). Just got back last night, and it seems my hands have to re-learn how to type. When I click on "view new content" I have 9 paginations of unread messages–ouch. This is probably going to take me a week to get through, especially with the Christmas holiday here. But I've been anxious to get back into the swing of things here and looking forward to getting focused on PW 2.4 now. Because I'm behind on the messages here, if there is anything urgent that you know of waiting on me, please reply or PM me and I'll make sure to get those right away. Thanks to all of you for taking good care of the forum while I was gone. Also Merry Christmas / Happy Holidays to everyone.

Hello All, After spending most of my free time this year building a large web application with ProcessWire, I've finally found the time to migrate my magazine site from MODX Evolution to PW. http://significatojournal.com I'm very, very pleased with ProcessWire, and will no longer be using MODX. In a separate post, I'll write up a case study of how I did the migration. But for now, I really thank Ryan and all the extremely supportive gurus in this very fine PW community. Peter Brown

I just committed suic.. ehrm an update to ColorPicker. As of 2.0.0 you can enable output formatting of the field in the details settings. When enabled it will format value directly from AADDEE to "#AADDEE" and "transp" to "transparent".So you can now simply write: echo "background-color: " . $page->color; // outputs // background-color: #AEADEA added converting "0" settings to "000000", just in case This update should be save to update and backward compatible, but as always you should first test on a development server if you have a chance. In case something went wrong just ask here in the forums and I'm sure it will be solved within short time. Thanks

OK, so finished my marathon forum catch-up...14 pages of threads! Here's signs you've been away too long..... 1. You get this message when trying to like a post... 2. Soma has (finally) updated his personal web site! 3. Pete trimmed his "facial" hair (ahem, fur) 4. Arimo is the new Arial, no Arial is the new Arimo, no actually Arial is still...uh, Arial..... 5. Willy C is designing a new top secret Admin theme. ;-) 6. You are no longer sure what this means.. 7. It's Christmas eve and you are starting a lousy thread... 8..........?

The goal is that there would be no difference from our perspective. But the reality is they are two totally different things behind-the-scenes, so there are sometimes minor differences. In time, hopefully there won't even be minor differences. But either way, it's good to know the difference just because database-querying selectors are more expensive to execute in terms of resources. Any function that accepts a selector and returns pages from the $pages or $page API variable is a database-querying selector. Whereas in-memory selectors are primarily used by PageArrays, as they represent a group of pages already loaded in memory and selectors are used to filter through them. $results = $pages->find("selector"); // database-querying $results = $results->find("selector"); // in-memory $children = $page->children; // database-querying $children = $page->children("selector"); // database-querying $children = $children->filter("selector"); // in-memory $children = $page->children->find("selector"); // database AND in-memory (just use children w/selector instead)

Btw, this might be a good place to mention that PW 2.3 dev adds a new Page::getUnknown hook (soon to be committed). That function gets called whenever a field is accessed that didn't resolve to anything. So you could [n the near future] do this (below) and you could call $page->some_radio_button_group on any page (specifically those that didn't already have the field) and have it resolve to what you want to. wire()->addHookAfter('Page::getUnknown', function($event) { $page = $event->object; $name = $event->arguments(0); if($name == 'some_radio_button_group') $event->return = new NullPage(); });

Hi Uniweb. Welcome to ProcessWire and the forums *Bilingual:: Yes, right out of the box. There are various implementations explained here in the forums. Have a look at the docs for starters. http://processwire.com/api/multi-language-support/ *Membership:: there are 5 different types of users: teachers, research workers, administrative staff members, students and anonymous. Yes, again, there's various implementations. This is about users and access. See this thread for pointers and other links. http://processwire.com/talk/topic/3946-membership-module/ *Moodle integration:: teachers should be able to use Moodle from our domain I am not sure exactly what you mean by integration. Moodle is an application in its own right. Did you mean shared users, for instance? Others will be chime in about this am sure. *Blog. Not sure if I can integrate a built-in Blogger blog into Processwire. Or is there a blog feature already in Processwire? Yes, PW already has a blog profile....it is also easy to roll out your own (this depends on your dev skills though) http://processwire.com/talk/tags/forums/blog/ http://modules.processwire.com/modules/blog-profile/ *Forum would be a nice addition although I'm not sure if it's possible with Processwire? There's no native PW forum. There has been talk though about developing one. You will be better of (I think) for now using a solution such as IP Board. Sorry for the quick answers. I hope they get you going... ..others will chime in with better responses...

What a coincidence that this thread turns up now. I've just finished a system for managing users and was wondering how best to share it. It consists of five template files, one stylesheet and a slightly modified InputfieldPassword module (I changed the validation and some text). You setup a page for each template, all of them children of a hidden /access/ page. The various forms are made with InputfieldForm. Each template sets $page->body and then includes a basic-page.php template file, like we see in many of the processwire profiles. /access/login/ /access/profile/ (for changing your password, username or email address) /access/logout/ /access/register/ (for creating a new user account) /access/reset/ (for when you've forgotten your password) Each user acount must have a unique username. An email address is collected for each user but does not need to be unique (it's okay for someone to have more than one account). When setting an email address we verify it by emailing a message to that address. Confirm by clicking a link or pasting a code into a form (an 'email-confirmed' role is added). Requests to reset a forgotten password are verified by emailing a message to the account's email address. Confirm by clicking a link or pasting a code into a form. To close the registration process set the /access/register/ page status to Hidden. For my own purposes, this is a convenient parts kit I can quickly add to a project. Seems like the easiest way to share it is as a profile. I suppose I could bundle up the files and create a module which installs everything for you but doesn't that seem just a bit overdone? Any suggestions? Good points were made above about coding standards, translatable text strings, etc. I'd have to do some work on that. I value the multi-language capabilities in PW but hardly ever need them in my work so if the community insisted on it being standard would that encourage me to get over my aversion to the syntactic baggage it requires or would it discourage me from sharing? For modules the Proof of Concept category works pretty well. It's nice to share unfinished work. Often the author's intent is easier to grasp in these less filled out implementations. Often there will never be a final version because every project is different. Framework add-ons can actually suffer from too much completeness. Do you want to transplant a seedling or a mature plant? Perhaps coding standards for modules could be expressed as a checklist and implemented as tags in the Modules section of this site. Likewise for profiles and any other kind of package we may come up with. Thanks to the many generous and thoughtful coders here.

A good reference would be the HelloWorld.module that comes with PW in /site/modules/. Or here is some great summary write up by the great teppo http://www.flamingruby.com/blog/using-hooks-to-alter-default-behavior-of-processwire/ wire()->addHookProperty("Page::itemCode", null, "itemCodeHook"); When a hook is added in template code we use wire(), as this is the base class of PW that contains the hook methods. addHookProperty() adds a new property to the object specified with "Page", so "Page::itemCode" adds a itemCode to page objects. $page->itemCode would return the code returned by the hook. "null" is usually the context for the hook, but doesn't need one in template code. Last argument is the function name of the callback that is used for this hook.

http://php.net/rmdir should take care of that. And while you are on that page, read through all the "Filesystem Functions" in the left sidebar. Also, if you haven't seen it before, PYDIO is the best php/ajax driven file manager out there and it's free and open source: http://pyd.io/

Yes there's wireCopy() wireCopy($sourcepath, $destinationpath, $recursive=true);

...and 12 pages later here I am.... very, very late to the party....I am liking what I am seeing and loving where this is going. I'll have me one "warm", thank you very much Ryan and all other contributors...

Sorry for not finding this discussion earlier. It sounds like the issue is already resolved, but I'll just add a couple minor points. Multi-language support is something that is installed by modules rather than something that's in the core from the beginning. As a result, the "default" language is the one you would have if you had no multi-language support installed. Likewise, the content of the default language is the content that would remain if you later uninstalled language support. So you need to think of that default language as the foundation or core language of the site. Once you start using multi-language fields, you can't easily swap in another language as the default (at least not without copying/pasting or making a little scripts to move things for you). If you needed the ability to do that, then you'd probably want to consider your 'default' language as unused on the front-end, and delegate all of your languages to non-default languages. I think it would be perfectly fine to consider the "default" language as "no language". When editing a page, you'd still be left with placeholders for the default language, which you'd probably just consider to be notes for the admin. The default language homepage is always represented by the root URL, "/", regardless of what name you've given it in the homepage settings tab. This is to ensure that a user arriving at your homepage doesn't encounter an immediate redirect to /en/ or /de/ or the like. Redirect from homepage is a behavior frowned upon by search engines, and generally considered a bad practice regardless. So ProcessWire is coded to prevent an automatic redirect from occurring on the homepage. That default language name comes into play on the rest of the pages in your site. If you wanted your homepage to be nothing but a language gateway (with no default assumed) then you'd need to delegate your real default language homepage to a separate page, like /en/welcome/ or something like that, which your language switcher can link to.

I agree that it does sound like unnecessary duplication. What's the benefit of creating your own users as pages separate from ProcessWire users? I'm not sure I understand the considerations there yet. But if you want to go that route and create your own pages as users, then there's probably no reason to maintain a 1-to-1 mapping with PW users. Instead, you can probably have a single user that you map all your own user pages to. Or perhaps a few separate PW users that you can map to, each with different levels of permissions... but then this is treating PW users as roles or groups, circumventing a system that's already there. I think the question of what users are may be the wrong question and instead it might be better to look at using the existing users system and what management additions are needed in your case. Perhaps modifying or extending the current ProcessUser module to provide the capabilities you need would be the simplest route.

You look just like your father

Hi All, First of all a big "THANK YOU!" to the community of ProcessWire and its founding father! It has been a great adventure developing this site with ProcessWire, allowing me to focus on getting things done! http://www.goaroundeurope.com On thing that was great, for me and for the site owners is the widget system I created. I used Pagefields for including a multitude of widgets that the site-owners place on pages in the site. They can create their own widget too and reuse them throughout the site. ProcessWire not only helped me during development, but the backend is very user friendly for the site owners. This was one of the major factors I considered when choosing the platform to build this site on. I only have to develop it once (and maintain/extend it ofcourse), but they have to use it day in day out....

Glad to have you back!

I work on multiple devices, ranging from phones (rarely) and tablets (not so rarely) to desktop machines. Having everything properly set up no matter what device I start (and no matter whether I've ever even used it before) is cool. I'm also most productive when I don't have to spend time adapting to new environment every time I start different machine, so having a consistent experience would definitely be a big plus. Personally I've solved most of these by having everything set up server-side, making browser and SSH client (and, though that's apparently going to change pretty soon, Photoshop) only things I really need to start working and be productive. Nevertheless I can see why some people might not like that and would actually prefer some horrible mouse-driven graphical IDE and other similar productivity killers.. From company's point of view, on the other hand, this just makes sense; not only does it make new kind of collaboration possible (like Joss already pointed out) and (theoretically) even make moving people from one project to another a breeze, it can also decrease costs of each new employee. No more high-end Macs, pricey IDEs and self-hosted complicated environments when all you need is couple of cheap thin clients and web-based, monthly billed app. That, and the (sad) fact that when that environment is developed far enough your employees don't really even need to know what's happening behind the scenes (Git, whatsthat?) when everything just magically works. Lower requirements when hiring new people often equal lower salaries.. and each new guy takes shorter time to learn the ropes and start being productive. I could list a dozen or so other benefits, but I think this pretty much summarizes it

Congratulations ! Onjegolders & Diogo Site's looking great, hope the same for the business !

Had a good vacation ? Got your batteries charged now for a while. Ok, meanwhile processwire still going strong, found a new job and upgraded my php skills and oh yes 2 pw forces joined each other in Milktop. Good to have you back Ryan.

Yep - you hum it, I will sing it

I've officially launched this site today: http://www.kidderminster-husum-twinning.co.uk/ For those not familiar with twinned towns/cities - many places (in Europe at least) are twinned with other places in the world and these are two such places which have built links between their cultures, clubs, associations etc. It was a relatively straightforward site. A design I had made many months ago actually lent itself to the Foundation site profile (which I upgraded to Foundation 5 without too much hassle) and most of the content benefits from the default styling in this case, which was a bit of a fluke as I'd not done anything with Foundation when I originally designed this I was in two minds whether to use Foundation as I'd not really touched responsive before, but it works nicely on mobile and I'm glad I did it. There's a bit more going on behind the scenes than meets the eye, and I think that because this looks like a simple site it might well be worth a full case study with a few tutorials of how I personally approach things. As for the tools I used, here's my list of modules: CKEditor Markup Yahoo Weather (a modified version) Page Link Abstractor (I always use this now so links in the body don't break when moving the site to the live server) Thumbnails (I couldn't imagine a site without this!) Languages - all of the core modules for languages, as there are English, German and Danish versions of each page (not all translated before anyone spots that but I shall leave that to the Twinning committee ) I also turned on caching for each of the templates. Due to the weather constantly updating on the sidebar I didn't use ProCache on this occasion - I toyed with making the weather a JS/AJAX/PHP combo but it then loses it's synchronisation with the two images in the slideshow on the homepage and that looked so nice that I can live with what is still a relatively quick site without making design sacrifices for the benefit of a bit more speed. What do you think?

Ipa, catch the Exception and print out the message, for example: try { // Login } catch (WireException $e) { // Print out message of exception echo $e->getMessage(); }

A small PW-based site for a Swiss photographer has just left the door: http://www.nicolasaebi.ch/ Nothing too fancy here. A couple of gallery-pages, using mainly isotope and fancybox. Responsive. Minimal.

And I do the opposite Joss. Almost always use double quotes, except when defining variables with straight strings. ps, I love curly and I love strings.

Problem Solved, updated the gist. To use: $image = $page->image; // image from $page, or any other ProcessWire image // $x & $y are required $x = 200; // width, the size of the box (max width an image can scale in width) $y = 100; // height, the size of the box (max height an image can scale in height) // $compress is optional $compress = 20; // makes heavier smaller then normal images, from (low) 1 to (high) 99 compression // usage 1 $img = $modules->get("ImageFitBoundaries"); $img = $img->load($image, $x, $y, $compress); echo $img->render(); // usage 2 $mod = $modules->get("ImageFitBoundaries"); $info = $mod->load($image, $x, $y, $compress)->info(); // also works: $mod->load($image, $x, $y, $compress)->info $thumb = $image->size($info['width'], $info['height']); echo "<img src='$thumb->url'>"; Thanks Dave, for your insight!

Merci Dragan ! Your solution seems great! Because I don't have a long processwire experience, I did not think about it : how powerful (and simple) it is to add any field in any template we want for any need... I will try it. Thanks a lot.

Bienvenu au forum icietla There are probably many workarounds for that scenario. You could create a checkbox inputfield, and check the value in your head or init.php template. If that checkbox is checked, you could do a redirect to the other language. if($page->redirectLang == 1) { $user->language = "en"; $session->redirect($page->url); } (untested)

There's a little bit of unnecessary code in your original post (and a bit of mixing $page and wire('pages') ) during the first two lines - you could also write it like this if it helps: $tdsphotos = $pages->find("tagsx.title=$page->title, limit=8, sort=-created"); One thing I would like to mention to everyone is that in double quotes you can to this: $page->title but not $page->somepagefield->somethingelse - as soon as you throw in the second -> (I'm not sure of the technical term!) you need to wrap the whole thing in curly braces like this: {$page->somepagefield->somethingelse} or you'll be troubleshooting it for hours like I did a few months back Alternatively you can concatenate as usual to avoid the curly braces requirement, so: $tdsphotos = $pages->find("tagsx.title=" . $page->title . ", limit=8, sort=-created");

Apparently that line is needed only during the install, so there's no problem to remove it. Thanks for the info, and welcome to the forum Edit: This is related http://processwire.com/talk/topic/4807-fixes-for-pw-installation-on-a-shared-server/ And apparently the alternatives to SetEnv are not really an option for this purpose http://stackoverflow.com/questions/18289196/htaccess-environmental-variable-alternative-with-php

Just throwing this in this forum in case anyone is getting 500 errors on GoDaddy with Linux hosting package. As of 12/9/2013, I was getting a 500 error on every page with the default .htaccess. I went through line by line and found that commenting out the HTTP_MOD_REWRITE variable fixed the problem: #SetEnv HTTP_MOD_REWRITE On I don't know the real cause of the problem, but after four+ hours of trying different solutions, this is what worked for me. My full htaccess file now looks like this (stripped out comments for brevity): Options -Indexes Options -Multiviews Options +FollowSymLinks ErrorDocument 404 /index.php <Files favicon.ico> ErrorDocument 404 "The requested file favicon.ico was not found. </Files> <Files robots.txt> ErrorDocument 404 "The requested file robots.txt was not found. </Files> <FilesMatch "\.(inc|info|module|sh|sql)$|^(\..*)$"> Order allow,deny </FilesMatch> <IfModule mod_php5.c> php_flag magic_quotes_gpc off php_flag magic_quotes_sybase off php_flag register_globals off </IfModule> DirectoryIndex index.php index.html index.htm <IfModule mod_rewrite.c> RewriteEngine On AddDefaultCharset UTF-8 #SetEnv HTTP_MOD_REWRITE On RewriteBase /dev/ RewriteRule "(^|/)\." - [F] RewriteCond %{REQUEST_URI} (^|/)\.htaccess$ [NC,OR] RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/assets/(cache|logs|backups|sessions|config|install|tmp)($|/.*$) [OR] RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/install($|/.*$) [OR] RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/assets.*/-.+/.* [OR] RewriteCond %{REQUEST_URI} (^|/)(wire|site|site-[^/]+)/(config|index\.config|config-dev)\.php$ [OR] RewriteCond %{REQUEST_URI} (^|/)(wire|site|site-[^/]+)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ [OR] RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ [OR] RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/assets($|/|/.*\.php)$ [OR] RewriteCond %{REQUEST_URI} (^|/)wire/(core|modules)/.*\.(php|inc|tpl|module)$ [OR] RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/modules/.*\.(php|inc|tpl|module)$ [OR] RewriteCond %{REQUEST_URI} (^|/)(COPYRIGHT|INSTALL|README|htaccess)\.(txt|md)$ [OR] RewriteCond %{REQUEST_URI} (^|/)site-default/ RewriteRule ^.*$ - [F,L] RewriteCond %{REQUEST_URI} "^/~?[-_.a-zA-Z0-9/]*$" RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !(favicon\.ico|robots\.txt) RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] </IfModule>

Basic but great The apigen docs were automatically created by scanning the code for classes and useful comments. They're not more than a nice alternative to reading the code itself.

I think you should probably take a look at the concept behind ProcessWire first, then some of the other docs and the cheatsheet as Macrura suggest - start with the Concept page from here: http://processwire.com/api/ The Cheatsheet then gives you a look at most the possible functionality at your disposal in page templates to access your data and files. As for explaining the line of code you quoted: $skyscrapers = $page->skyscrapers->find("limit=3, sort=random"); From memory, "skyscrapers" is actually a "featured skyscrapers" field, so is just a Page field that links to other pages (probably the most useful fieldtype there is. Here is the exact translation: "For the current page (homepage in this instance), find 3 random pages from the skyscrapers field". The $skyscrapers = bit is just storing the results in a PageArray (it's in the docs linked further up my post here) that can then easily be iterated through to print whatever output you desire. If you're wondering why the demo doesn't seem to pick three random pages, I think page caching must have been accidentally left on here so it's always showing the same 3 in the demo, but that's easy to switch off The syntax is based on jQuery and aims to be human-readable. If you imagine that there are a few database tables and queries behind that code, you can easily see how quick that is to write and all without a line of SQL. You can make all sorts of queries like: $architectsCalledPaul = $pages->find("template=architect, title*=Paul"); // finds all architects (pages with the template "architect" with the name Paul somewhere in the title field // and so on... The idea behind ProcessWire is that once you've learned the basics you can build pretty complicated data structures in the admin quicker than you'd be able to writing database tables from scratch and you have a hugely powerful set of functions at your fingertips to do with that data as you please. Most folks here would agree that it has shaved hours/days/weeks/months off their site build times depending on website scale, but any time saved is good!

@gebeer: Have you tried if "Unpublished" (capital "U") works? Just a guess, but it could be that Edit: my guess was wrong; lowercase would work just fine. The issue is that the code Martijn posted above is from dev branch. If you're running stable (master) branch of ProcessWire, that won't work for you.

By the name, I woud say that this function belongs to a very nice framework called ProcessWire

Ok now I saw that one of the presets was YMj and not Ymd as I claimed. I'll just convert my dates then, it's no big problem. Edit: here's how to convert dates from ddmmyyyy to any other format: http://jacksonjose.wordpress.com/2012/01/10/change-date-format-in-excel-from-ddmmyyyy-to-ddmmyyyy/ =DATE(RIGHT(B2,4),MID(B2,LEN(B2)-6+1,2),LEFT(B2,LEN(B2)-6)) Replace commas with semicolons in Libreoffice (and remember that you have to use function names specific to your language, so in a Finnish LO version DATE becomes PÄIVÄYS etc.).

It's not a bug, it's how list elements work. Now the browser tries to make something of it. list elements need an <ul> or for numbered <ol> echo '<ul>'; foreach($page->children as $child){ echo '<li class="A">'; echo '<ul>'; foreach($child->children as $book){ echo '<li class="B">'; echo '</li>'; } echo '</ul>'; echo '</li>'; } echo '</ul>';

Welcome to the forum Chris! body is a custom field and as any other field it only exists if you create it (well, it comes with the default install, but you can delete it or ignore it). That's why it's not in the documentation like the properties and methods of the $page object.

Actually you should be able to use "children.name=tarjetas", but I tested it out here and it behaves the same as "parent.name=tarjetas", so that is a bug. Looks like this is the first instance I've seen of needing to use something other than children.count. I've now fixed it, but am doing a little more testing locally before committing to dev.

That is caused by Session Login Throttle. With code below you can force Session Login Throttle to delete the entries. And make the account work again. $u = $users->get('admin'); $u->of(false); $u->pass = 'type-in-your-pass'; $u->save(); just throw it somewhere in you template, and call it with a browser visit.

@lundi: http://processwire.com/api/

users are pages. pages already have auto-id increment

How is re-saving a problem? set_time_limit(0);// in a template $books = $pages->find("template=book"); foreach ($books as $book) { $book->of(false); $book->save(array("quiet" => true)); echo "<p>Saved : $book->title</p>" } echo "<p>Done!</p>";

No, it's also more efficient (technically faster) on the front-end. It's possible, but you'd have to go in and add them directly in MySQL using PhpMyAdmin or the like, and update the module's code to recognize your new field. Probably not. While the database could handle millions of rows, the admin side won't be able to handle displaying millions of rows in the same page editor. It would be the same issue as with using a repeater, at least from the admin display aspect. Though this solution could technically serve a lot more rows than a repeater could. It would not be as scalable as using pages, simply because everything around pages is already designed in consideration of scale (limits, pagination, selective loading of fields, etc.). Pages are certainly more resource intensive, but those resources go towards making them scalable.

When the need is there for separate DB configurations and something more than config-dev.php, I've done it like this in my /site/config.php file: switch($_SERVER['SERVER_NAME']) { case 'localhost': // set database settings for localhost break; case 'dev.domain.com': // set database settings for staging server break; default: // set database settings for production server } You should give preference to SERVER_NAME in this case (over HTTP_HOST) just because HTTP_HOST is coming from the client rather than the server (open to tampering). Though it doesn't really matter as long as your last "default" condition assumes the production server.

If you don't need the page to be saved when the button is clicked, then I think the route you are taking is fine. If you did need the page to be saved, then you'd want your button to be a submit button, and a second (save) hook to be called after the ProcessPageEdit::processInput and to silently do its thing (no redirect). Another route you could take is to setup a separate page with a template that does what you want, and then have your button link to that instead. But the way you've done it is already more compartmentalized (less parts to consider) so I wouldn't change it unless it creates issues with other modules hooking into ProcessPageEdit at some point down the road (which is possible). One issue you probably want to fix here though is the potential for XSS: $href = $this->config->urls->admin.'page/edit/?id='.$this->input->get->id.'&e=1'; Taking a variable directly from $_GET or $input->get and putting it in output (unsanitized) is always dangerous. You'd want to do this: $id = (int) $this->input->get->id; $href = $this->config->urls->admin."page/edit/?id=$id&e=1"; or better, yet this: $id = (int) $event->object->getPage()->id; $href = $this->config->urls->admin."page/edit/?id=$id&e=1";

This is a good way to go, and exactly what I do for predefined settings like required image dimensions and such. What you set in _init.php is for runtime use of your site's template files, and probably nothing beyond that. These variables are good for initializing placeholders that you'll be outputting in your _main.php (or whatever your appendTemplateFIle is called). This sounds like overkill to me, though of course use what works best for you. But you have a couple more options to consider: Use session variables, especially when you want the value to still be present and available on not just the current request, but subsequent ones (from the same user) too: // do this $session->set('my_variable', 'my_value'); // then retrieve it from anywhere (and at any later request) like this: $my_value = $session->get('my_variable'); Set an API variable: // do this wire('my_variable', 'my_value'); // then retrieve it from anywhere like this: $my_value = wire('my_variable'); Whichever route you take there, if you've got a lot of related values to set you might want to bundle them all into an array, so that you only need to set 1 session, API or config variable.

<qoute>What's more, on Italian keyboards you don't have the ` sign.<quote> You must hate MODX then

Good one, didn't think of $config->ajax edit: You might want to change it to if(!$config->ajax) throw new Wire404Exception(); // content as it simplifies a bit

This is sort-of built in to ProcessWire already on a basic level. If you make a copy of your config.php file called config-dev.php, then that one will take priority over config.php. Just ignore the -dev version in DeployHQ settings, or add it to .gitignore so it doesn't even get committed - up to you. As long as config-dev.php on your local system has your local settings in, and your config.php is treated as your live version, it should be fine