SiNNuT

TemplateBy adding the fields you desire to a template you basically model the content/data that you want to manage. Template file Associated to a Template, a template file is where most of the view and controller logic takes place. PW is very flexible so you can also make this more MVC-like, look at this for an example: https://github.com/fixate/pw-mvc-boilerplate/tree/develop Page A page is a data object that always follows the rules and data structure of the associated Template (you could say model). In PW pages are tree based (parent-child relationships). This gives powerfull options of organizing and relating content. Routing PW has a default way of routing following the page tree, but by utilizing urlsegments or hooking into the routing mechanism you can define your own if needed. So PW has it's own way of doing things. It may take some getting used to, but in my opinion it is a very nice way to model and manage your data. I believe one should always choose the right tool for a certain job, so there might be projects that are better suited to build from the ground up using a general purpose framework like Laravel or Symfony. But in my experience PW is the right tool for a whole lot of stuff.

Having run a couple of MODX Evolution sites in the past i can confirm that this system was/is pretty snappy on both the manager part and frontend rendering. I'm guessing that this is in part because of the relatively simple nature of the beast. Remember MODX Revolution? With it came more power but also backend performance and frontend rendering times took a dive. There is maybe another thing to consider, which you are probably aware of but maybe not. In Evolution, documents (think PW pages) are set to 'cacheable' by default. This means that all page output is cached. What was nice about the system was that, if needed, you could still call uncached snippets and such from within an otherwise cached document. But most of the times you would call snippets cached, i.e. without the exclamation mark. So in reality, in Evolution, most documents tend to be cached, either wholly or at least in part. So if you compare Evolution <--> PW with regards to total rendertime on the frontend (which is the only thing Google and end-users really care about) you should take caching into consideration for a fair comparison. Use template caching where possible and if not Markup Cache, at least for PHP/API/DB stuff. I see that with some use of Markup Cache you were already able to get within 200 ms of the comparable Evolution site. Maybe with Ryan's optimizations to the bootstrap this will only go down. That's pretty good if you ask me. Another thing to consider is that suboptimal use of the PW API in temlate files or other places and loaded modules can affect performance negatively. So be sure to scrutinize your PW projects for this stuff. In the end i think the power to performance ratio that PW delivers is pretty awesome!

Quote from a friend after the game against Iran: "the Nigerians are better at phishing than playing football" I loll'd

Well, that wasn't too bad of a performance by our guys

#FIFAMaffia Rooting for Oranje but i am not that optimistic about our chances in this Worldcup.

<?php if ($page->check == 1) // 1 is checked, 0 is unchecked echo "some text"; echo $page->sometextfield; ?>

It's sometimes a bit hard to tell where your comprehension ends and the hat-eating starts but i'm glad to see you've got the gists of it. In your last piece of code the sanitizer step seems unnecessary. Seeing as you only ever want to submit allowed values there is no need to sanitize input->post only for checking values.

Then it will (probably) not be recognised as Hanna code and the [hello_world]] will be displayed as-is. So no harm done (it may only look a bit stupid

Let's say you have a frontend form that, among other things, asks visitors to tell which Dutch province they come from. You generate the select options from 12 PW pages (there are 12 provinces). Of course, because these are existing PW pages and you did some solid coding the select options will be clean and because visitors can not type anything themselves you think that the only thing that could be submitted would be one of the 12 provinces. This is where you are wrong. Assumption is the mother of all fuckups. Maybe a clever hacker will be able to manipulate what goes into input->post. So instead of a province a bunch of evil code gets submitted. This is why you have to check that input->post matches one of the trusted values before submitting. In this case, the trusted values being the 12 provinces. So in the case of predefined select options it is not about sanitizing but more about checking/validating post data before processing the request.

I believe it was late 2010 after googling for something along the lines of 'php cms custom fields'.

In your example it's not so much about sanitizing but more about validating (checking) if the user input matches one of your intended options. Kongondo's example does exactly that. Almost the same is this: http://stackoverflow.com/questions/5627747/validating-select-box-with-php Maybe this helps to grasp the idea.

The Apache rewrite module is a requirement for PW, regardless of which setup or wamp package you use. There is a check for this in the PW installation routine, so it should have given you a warning when installing PW. In wampserver you have to enable rewrite and in uniform it's enabled by default. Regarding the vhosts: it's hard to tell why it won't work but i'm thinking it might be that the changes to the windows hosts file are being ignored. This seems to be a pretty common problem. Maybe you can try the stuff listed here: http://serverfault.com/questions/452268/hosts-file-ignored-how-to-troubleshoot And here: http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/hosts-file-ignored-windows-7-64-bit-firefox/dcad50c8-4242-435b-a87b-26ecd2ff7d97

In this case, if you're serious about security, you would probably want to validate if the user input matches one or more of the select options. If user input != select options don't process the request. You can never assume that nobody is able to tamper with stuff, even if the options are seemingly predefined in your code.

Or simply type skyscraper.dev/ in your browser address bar. Notice the slash; this will also make the browser aware of what you are trying to do the first time. Also, did you not manage to get things going with UniServer? Using the controller program that comes with it to create a vhost and edit the hosts file might be less confusing and less error prone for you. When going that route be aware that by default this will create a vhosts directory inside the UniServerZ directory where it expects you to place you project files (i.e. document root).

I do think setting up virtual hosts (in most cases) is a good practice and there really isn't that much to it. However, it seems you have your VirtualHost setup wrong. Localhost will already be defined by wampserver and probably has precedence over your vhost entry, hence localhost shows the wampserver startpage. I'll show and example of a working VirtualHost entry: <VirtualHost *:${AP_PORT}> ServerAdmin webmaster@mysite.dev DocumentRoot ${US_ROOTF}/vhosts/mysite ServerName mysite.dev ServerAlias www.mysite.dev *.mysite.dev ErrorLog logs/mysite.dev-error.log CustomLog logs/mysite.dev-access.log common <Directory "${HOME}\vhosts\mysite"> Options Indexes Includes AllowOverride All Require all granted </Directory> </VirtualHost> In this case my PW files are in a /vhosts/mysite folder, but this can also be a full path like you did, as long as Apache can reach it. No need for a trailing slash in the document root. For vhosts to work you should also edit your Windows hosts file to match the vhost, in this case example adding a line "127.0.0.1 mysite.dev" to it. I can, and need, then approach this project via typing mysite.dev/ (or www.mysite.dev/) in a browser. So i think you have to change servername and serveralias to something that makes sense to you; for example sitedomainname.dev, or anything you fancy. You will also have to add a line to the windows hosts file, like described above. Restart everything and it should work. - dagnabbit, just when i was typing this you read my other post

I've been a long time fan of The Uniform Server. No installation, no registry settings. It just unpacks to a folder and is ready to go. You can setup vhosts from within the controller program, including editing the windows hosts file. You could just put it on a USB stick to always have a wamp environment with you.

A convenient way would be to put the code in a file called _init.php. Create this file in your template directory and edit site/config.php to enable _init.php. The lines in config.php you need to look for are about 'prependTemplateFile', around line 45, read simple instruction. For some more ideas and insights you can, as Macrura mentioned, look at https://processwire.com/talk/topic/3987-cmscritic-development-case-study/

Are you sure your page fields belonging to the layout entries are set to single page (see the details tab of the fields). If so you should be able to directly do: // assuming that you actually want to output the title of the page that holds the single image echo $entry->image_full->title; So if($entry->image_full) echo "<div class='full'>$entry->image_full->title</div>";

Seeing as you already have a PageArray ($entries) i am a bit confused what you try to do with $full = $pages->get($entry->image_full); Couldn't you just delete the $full line and just do $outMain .= $entry->title; I think i don't exactly understand how you have put together the logic behind the image entries (pages with 1 or more images??) and layout entries. What kind of field is image_full?

What's your code for getting $entries?

No, not like yours, that's just really stupid

Didn't think you would run with this code, but with the additions by kongondo(/horst) and if it's suits your needs, it's fine to use this. With regards to crawling: using the method above would do nothing special to hide the content, but if Google were to reach the page they would only be able to see the login page. If you want to also avoid that adding <meta name="robots" content="noindex, nofollow"> to the head of your html usually helps. Come to think of it, if pages can go from private to public and vice versa, by setting/unsetting the password field in the backend you probably want to add some extra logic to your template(s) that support the page_password field.

@horst actually, hisrc has bandwidth checking https://github.com/teleject/hisrc/blob/master/README.md

I always quite like solutions that also do bandwidth checking, and other stuff, like https://github.com/adamdbradley/foresight.js (standalone) or https://github.com/teleject/hisrc (this is a jQuery plugin) If that was to be paired by some PW magic to create image variations that would be cool.

In it's simplest form it could be something like this, where $page->page_password is a textfield you can set for every page that needs the login. <?php if ($_POST['awesome_password'] != $page->page_password) { echo <<<EOT <h1>Login</h1> <form name='form' method='post' action='$page->url'> <input type='password' title='Enter your password' name='awesome_password' /> <br /> <input type='submit' name='Submit' value='Login' /> </form> EOT; } else { echo "<p>This is the protected page. Content goes here.</p>"; } ?>