ryan

The two should run alongside each other just fine. For instance, this forum (SMF) is running alongside ProcessWire, and I just modified the default SMF theme to match the rest of the site. But "integration" can mean many things, so I wanted to find out more specifically what you mean in this case?

I would except that it's not mine to open source (it was paid work for a client). In addition, it was done in PW1, which is quite different. However, it would actually be easier to do in PW2. If it helps, the fieldtype was based on what was done in FieldtypeFile. But give me a little time, and we'll come up with something much better specific to this need.

ProcessWire upgrades are easy because everything unique to your site is contained under the /site/ directory. That directory is not part of the ProcessWire source, so you just replace everything else, and leave your /site/ directory as it is. Following are instructions on how to do this. If you find an UPGRADE.txt file in the new version of ProcessWire, you should give those instructions authority over these. However, these instructions outline how the majority of ProcessWire upgrades are performed. Please note: these instructions do not apply to a 2.0 -> 2.1 upgrade. For instructions on how to perform that upgrade, please see this thread: http://processwire.com/talk/index.php/topic,583.0.html Upgrading ProcessWire from the ZIP file 1. Download the latest version of ProcessWire from the downloads page at GitHub and click the "Download ZIP" button: https://github.com/ryancramerdesign/ProcessWire/archives/master 2. Extract the ZIP file somewhere temporary (I usually extract on my desktop). 3. Replace the following files from your existing installation with the new versions found in the ZIP you extracted. If you want to be able to revert back to the old version, backup any files you replace first. Replace: /wire/ with the new version Replace: /index.php with the new version Replace: /.htaccess with the new version (rename htaccess.txt from the ZIP to .htaccess) Your site is now upgraded. Test that everything works as it should. Upgrading ProcessWire using Git & GitHub: If you originally installed from the source at GitHub, you can upgrade to the latest version of ProcessWire easily by using git pull. cd /your/processwire/installation/ git pull All files related to your specific site are contained in the /site/ dir, which is not part of the source files on GitHub, so it should remain untouched through the git pull (though it doesn't hurt to back it up). Your site is now upgraded, but you'll want to finalize it by doing a little housekeeping. You will find that git pull added some files that weren't there before. Here's what you should do with them: Delete: /install.php Delete: /site-default/ Rename: /htaccess.txt => .htaccess The above steps are optional if you are upgrading a non-production/development server. Since I git pull regularly, I just leave these files in place so that I don't have to delete them every upgrade. In addition, the .htaccess file rarely changes through upgrades. While optional on a local development server (that isn't accessible from outside), on a production server, you absolutely need to perform these steps. Your site is now upgraded. Test that everything works as it should.

Another option is to build a custom fieldtype for the data you need it to hold. With the project I'm working on now, they needed a multi-column pricing table with any number of rows. So the easiest solution was to just build a custom Fieldtype module for the client. But it sounds like this matrix-type configurable module might solve, or at-least reduce, the need for that type of custom module.

Sounds like a good way to put together the slideshow, and it looks good too!

Adam is right that you can do that part now if you want. But that's an undocumented thing, and I haven't actually tried it (just built it with that intention). If you do it, and find that it doesn't work for any reason, let me know and I'll rush an update to fix it.

Awesome screencast! This looks incredibly useful, so cool to see. I'm limited on time for the moment, so just wanted to quickly follow up with the starter module. When I made this, I wasn't thinking about the admin side of it, where you edited ProcessPageEdit.module. I need to take a closer look tomorrow and update the starter module code to hook into that too. But here is something to get started. It's actually very short, but I loaded it with comments that I thought would help, so it looks a lot longer than it actually is. Place this in: /site/modules/AdminBar/AdminBar.module <?php class AdminBar extends WireData implements Module { /** * This is where you define some basic info about your module. * * See /wire/core/Module.php for definitions of all these. * */ public static function getModuleInfo() { return array( 'title' => 'Admin Bar', 'summary' => '[summary of your module], by apeisa', 'href' => 'http://processwire.com/talk/index.php/topic,56.0.html', 'version' => 100, 'permanent' => false, 'autoload' => true, 'singular' => true, ); } /** * Initialize the module and setup hooks * * The init method of a module is called right after ProcessWire is bootstrapped, when all * API vars are ready. Whereas the __construct() is called DURING bootstrap, so the init() * method is a better place to attach hooks to API vars. * * In this method, we'll use an 'after' hook since we want to modify the output of the * rendered page template. * * Note also that the 'Class::method' syntax means it hooks into ALL Page instances. * The syntax for hooking to a single instance would be: * $page->addHookAfter('render', $this, 'pageRender'); * * Also note that there isn't actually a Page::render method, it was instead added by * another module (wire/modules/PageRender.module). Not that it matters here, but just * wanted to mention in case you look in the Page class and don't see a render method. * */ public function init() { $this->addHookAfter('Page::render', $this, "pageRender"); } /** * Hook called when a page is rendered * * The method name used here does not matter, it just has to be consistent with the name you provided * when creating the hook. * * This method is given an $event object of type HookEvent. To see what's in that, see this file: * /wire/core/HookEvent.php (it's very short and simple) * */ public function pageRender($event) { // $event->object always has the object instance that resulted in this call $page = $event->object; // if the page isn't editable, or if it's using the admin template, abort. if(!$page->editable() || $page->template == 'admin') return; // find the location of this module for linking css and js files $url = $this->config->urls->AdminBar . "AdminBar"; // the css and js links we're going to add $out = "\n\t<link rel='stylesheet' type='text/css' href='$url.css' />" . "\n\t<script type='text/javascript' src='$url.js'></script>" . "\n</head>"; // modify the value returned by $page->render() to include our css and js files $event->return = str_ireplace('</head>', $out, $event->return); } } Also you will want to create: /site/modules/AdminBar/AdminBar.css /site/modules/AdminBar/AdminBar.js Thanks for what you are doing here, nice work and great screencast! I will work on expanding this starter example.

I think I may not totally follow what you are doing here, but if I understand correctly, these two things may help: 1. Assuming that slideshow_ref is a page reference field, it should actually be a Page object. The reason it appears to be returning the ID is because that's the typecast string value of a Page object. However, it's actually a Page object Just like $slide is. So there is no need for you to run a separate $pages->get(), because you've already got it. You can just do $slide->slideshow_ref->url. 2. While not applicable in this case, I wanted to explain why Pages may be typecast as strings that return the ID. The reason for this is so that you can use them in selectors. So lets say that you wanted to find all pages that referenced the current page in their slideshow_ref field: $pages->find("slideshow_ref=$page"); Or all other pages (except the current) using the slideshow template that had the same slideshow_ref as the current page: $pages->find("template=slideshow, slideshow_ref={$page->slideshow_ref}, id!=$page"); I don't know if these are useful, but just wanted to use them as examples.

I'll be happy to get you started with a "blank" module that you can build it on top of. What I recommend is that we hook into the Page::render method, grab it's output, and insert your js and css markup file links right before a page's closing </head> tag. That way, when someone installs the module, it'll just start working without them having to do anything on their own. Of course there will be those that want to control the placement of those things, so I'll show you how to make that configurable. The PHP code that is in your .inc will become the module code. Let me know if this sounds like a good plan to you, and I'll follow up with posts showing you how. There are definitely merits to inline editing, depending on the site. I view the needs of page viewing and page editing as fundamentally different, and prefer to have an interface that is designed for one or the other (though the 'overlay', like in Drupal, and in your example, is a nice compromise). But there are many cases where it is really handy to be able to edit inline, if the site design supports it. As an example, I like to make moderated comment approval inline, so that I can just click "approve" or "spam" while viewing the comments (though Akismet mostly does that for me now). There are plenty of other cases, and I'm betting that Aloha Editor will provide some good opportunities. I think you'll find ProcessWire works well when you want something to be editable inline. On the front end, you would just need to make sure that the page is editable before including the inline editors, i.e. if($page->editable()) { ... }. Then you'll need for your template, include or module to look for when they've clicked 'save', i.e. <?php if($input->post->submit_save && $page->editable()) { // turn off runtime formatters (like entities, markdown, date formats, etc). $page->setOutputFormatting(false); // go through all the submitted fields and set those that are applicable foreach($input->post as $field => $value) { if($page->fields->has($field)) $page->set($field, $value); } // if the above resulted in a change, then save the page if($page->isChanged()) $page->save(); // turn output formatting back on so it's in the proper state for viewing $page->setOutputFormatting(true); } Note that if the "save" button is just attached to individual fields, and you'll only be saving one field at a time (possibly ajax driven), then you may want to just save the field rather than the whole page, i.e. $page->save('field name');

Looks like I forgot to update this before, but wanted to mention that this module is now included in the current ProcessWire distribution (and has been for a little while).

This will be possible. Actually, the plan is to change users to be derived from pages and the "user" template will be a system admin template that you can add/modify fields to like any other. Likewise, you'll be able to get/find/manipulate users using the pages functions. The existing $users and $user objects will be mapped to the pages/page API variables. This is the reason why the users, roles and permissions system is barebones in ProcessWire right now ... I wanted to put most of the time into pages, since other systems will be derived from it.

You are right the system would definitely support it pretty easily. The challenge would just be in making it configurable with any fields, and supporting a matrix display... most fieldtypes assume they aren't width limited. In addition, making the individual components of the fieldtype searchable/selectable with the API. But these things are already partially worked out.

This looks awesome, thanks for your work with this! Are you interested in bundling either of these as a module for other people to use? Let me know and I can add a modules section to the download page, as well as assist with any help you need making it a module or adding hooks, etc. I agree re: drupal7 modal, it was a great improvement. The modal var in PW2 is specific to things like the image editing popup and link selector popup (currently used with TinyMCE Fieldtype). It basically just turns off the branding (as you saw). Not sure that's what we would want in this case (?), but perhaps something similar with more minimal branding? Thanks, Ryan

Hi Mike, Good idea. There are definitely plans to do that. Right now you should be able to add fields as you see fit to any $user object, and it should save them in the 'data' field in the users table. (granted I haven't tested this, but it was the intention, though I may need to double check that part is actually working). But you don't see fields for them on the back end (yet). So you can set them with the API but not the admin interface. The plan is to make the users fields configurable like a template, where you can add whatever fields you want. We're not there yet, but just wanted to mention that's the goal. Thanks, Ryan

These are some cool features no doubt, something to think about. I can see how we could get these kind of results by building Fieldtype modules, like a Fieldtype module that contains one or more other fields (like it was mentioned a Fieldset). Developing this Fieldtype would be a rather big project in it's own right, but certainly within the bounds of what ProcessWire would support, so I think this is definitely a worthwhile addition to the roadmap.

You are right about that, there should not be an either option, not sure what I was thinking.

Adam: I'm going to make the trailing slash configurable on a per-template basis. It'll be "on", "off" or "either", with the default being "on".

I agree with what Adam has recommended here. In my sites, I usually create a /config/ page that is hidden, and then place all my selectable pages under there, like /config/countries/, /config/states/, etc. Note that you don't want your actual 'country' pages to be hidden, just the main '/config/' (or /countries/ if you are using that). The advantage of keeping these as pages is that it's easy to add/edit them, and it's easy to setup a template that could list everything in a particular country, for example. Viewing /countries/france/ can produce a list of all pages that have it selected... a huge benefit. If your sites have highly relational structures like this (with indexable URLs) your search engine performance will benefit greatly, and it's just really useful to have for may reasons, taking almost no work on your part.

It sounds useful! I'm looking forward to seeing what you come up with. Note that there are still more API variables I have to cover in the docs: $users $config $roles & Role $permissions & an individual Permission $fieldgroups & an individual Fieldgroup $templates & an individual Template PageArray I've held off on $roles, $fieldgroups and $templates because I want to tie fieldgroups and templates together like they are on the admin CP (currently they are separate on the back end). For roles, I'm planning to make them assigned to templates rather than pages (as the default option), so waiting to finish that before finishing that part of the documentation.

ProcessWire will support .html extensions. You just have to make them your page names, i.e. "about.html" rather than "about", or look for them in urlSegments. I've actually done this before, though for specific pages (like /sitemap.xml), not on a site-wide basis. But I don't see any problem with it conceptually. There is one implementation problem in that PW2 enforces slashes at the end of the URL. However, I think I should be able to make that part optional as part of each template's advanced configuration. Actually, I'd meant to make that optional even before this question came up. So let me work on that part, and I think this will be an easy addition. As for the value of keywords, I think you guys were talking about two different things. I think Sevarf2 is talking about meta keywords. Meta keywords have never been used by Google, and they were thrown out of most other major search engines about a decade ago. But meta keywords are still valuable if you are running your own spider, perhaps something indexing across multiple platforms on a very large site. But excluding that, there's not much point in using the meta keywords tag. I think it's better to leave them out-- A spammy meta keywords tag can still hurt you, even though a meta keywords tag can't help you. I think Adam was referring to keyword density, like the fact that key words/phrases have to be present on a page (or links to it) in order for it to be matched by Google. And the strength of those keywords can relate to where they are placed in the markup (i.e. <title>, anchor text and headline's carry more weight, for starters). And then there are some formulas about density, but they are a matter fine tuning as well. Roughly 80% of SEO is what happens on other sites, not yours (i.e. who's linking to you), so I usually tell people to just focus on making the site highly accessible with high quality semantic markup and content, and focus on making it something that people would want to link to, and leave it at that. My experience is that the best results come from logical URL structures that are highly readable and contain keywords. I don't think that Google actually ranks based on keywords in your path, but they certainly highlight them in the SERPS, which is worth it right there. I would be surprised if there was any benefit to using ".html" in your URLs on a new site (as opposed to an old site). At one time, I think there was a benefit, just like there was a benefit to using subdomains over paths. Such benefits don't last because they just exploit a temporary vulnerability in Google's algorithm. Ending with ".html" is kind of a legacy thing, present on sites that have been around a long time. Benefits from ".html" might be a side effect of the age of sites where they are used, when in fact it's the age that drives the result. Where I think the real benefit would lie is if you are trying to maintain old URLs that end with ".html". If you've had a page at /page.html for a really long time and it's well indexed in Google, it's to your benefit not to change it. While technically Google should transfer page rank to your new page (via a 301 redirect), it doesn't always work and/or throws you in the sandbox for a little while. Other times, it works as planned, but it's a risk on a high traffic page. So if you are trying to maintain legacy URLs that end with ".html" there is most certainly an SEO benefit to keeping them at ".html". But on a new site, I think I would avoid using ".html" in your URLs. I don't see any real world evidence that ".html" influences performance, and I don't view dust crawling as being applicable for the type of pages we are talking about. But lets just assume that there was some benefit. Using .html in URLs that aren't actually composed of static files that end with ".html", with the intention of swaying Google, would likely cross the line on their webmaster guidelines (short term benefits lead to long term pain). I would avoid .html in your URLs unless it's literally a static page where the file extension drives the mime type. Otherwise, it's trying to deceive Google a little bit, and that's never a good long term strategy. All of this is speculation of course, I don't know anyone working at Google, but I do enjoy the subject! If you know something more about this, please keep the conversation going.

777 can be a security risk on a shared hosting environment, especially if they aren't jailing accounts from one another. 755 would certainly be preferable if it worked. Many hosts will run Apache as your user account, in which case 755 will be just fine. If you are in a shared hosting environment that isn't particularly secure, you may want to just limit write access to your account and whatever account apache runs on. That won't necessarily keep out PHP running on other people's accounts, but it's better than global rwx. However, nearly all the shared hosting accounts of worked with lately have been pretty well jailed from each other, making these considerations not as much of an issue. But the number of hosts I work with are also fairly limited, so this may not be a universal statement.

These are good questions, and perhaps a video would be a good way to demonstrate some of them. But the goal is not to give you a different way of thinking. Instead, the goal is to work with your existing way of thinking and development style. The goal is to get out of your way and support you rather than tell you what to do. Each template is a PHP file and you use it in the same manner that you would use any other PHP file. The only difference between a template (PHP) file and a regular PHP file is that ProcessWire provides you with some API variables giving you access to the data specific to the page being viewed. There are other things it gives you, but just understanding that point is the main thing you need to know. Whether you use the API variables is entirely up to you. It's certainly feasible that your templates could be nothing but HTML (though maybe not that useful, except for something like your 404 page template). Adam did a good job of demonstrating a template as a PHP file, because you can see that 90% of what is in his template is his own PHP code that isn't necessarily specific to ProcessWire. In fact, I don't recognize some of the classes he's referencing because they are his own. He uses the API functions vars/functions where appropriate to pull in the data he needs, and then uses his own PHP code (and it looks like some of his own libraries) to output it in the manner he wants. Your own templates need not be this advanced, nor do you need to know as much PHP as Adam does to make effective use of templates. In fact, I think you can even make very effective use of templates without knowing much PHP at all. But for people that know PHP and have a way of doing things, ProcessWire is not going to get in their way. Because templates are PHP files, what a given template looks like and how you work with it is a bit of an open ended question. There is no right answer to that question, as so much of it comes down to your development style. ProcessWire is really designed to work within your existing development approach rather than trying to dictate your approach. For instance, some will use templates as just HTML files with occasional API variables to output a value for a given page. <html> ... <div id='bodycopy'> <?=$page->body?> </div> ... </html> Using templates in this manner, you don't need to know PHP, and you might not even know you are using it at all. While the other end of the spectrum is to use template files as MVC controllers, or controllers for another PHP application, and then grab their output, i.e. <?php $out = new TemplateFile("./includes/my_markup.html"); $out->set('headline', $page->get("headline|title")); $out->set('body', $page->body); $out->set('sidebar', $page->sidebar); $out->set('navigation', $pages->find("parent=/")); echo $out->render(); Note: The TempateFile is a class included with ProcessWire that you can use if you want to... it's what ProcessWire uses to render it's templates too. A more common approach is for your template to include a header (of HTML and/or PHP), output a content area, and then include the footer (of HTML and/or PHP): <?php include("./head.inc"); ?> <div id='bodycopy'> <?=$page->body?> </div> <div id='sidebar'> <?=$page->sidebar?> </div> <?php include("./foot.inc"); ?> Another approach is to populate placeholder variables and then include another file to output them: <?php $headline = $page->title; $bodycopy = $page->body; $sidebar = $page->sidebar; // render a ready-to-output subnav <ul> list $subnav = $page->children()->render(); // get photo from current page if available, otherwise get it from homepage if($page->photo) $photo = $page->photo; else $photo = $pages->get("/")->photo; // make the photo 300x200 $photo = $photo->size(300, 200); // main.inc is just HTML and outputs the vars we populated above in the right places include("./main.inc"); But these are just a few examples of many possibilities. What I woud recommend is getting familiar with the templates that are included with the basic site profile. Then post questions about any parts that don't make sense, and we'll be happy to help. When you are feeling comfortable with the basic site profile, send me an email asking for the skyscrapers profile, and I will email this to you. This example goes a little further than what's in the basic site profile, but I think it's good to understand the basic profile first. Also, if you want, tell us what other CMS platforms you've used and I can explain what's similar and different in how you use templates in ProcessWire. Thanks, Ryan

There is actually an API variable called $user. It provides all of what you've mentioned. I will do my best to add documentation for it on the site today. Thanks, Ryan

Also don't worry because I totally understand the need for a date-based publish/unpublish, and that's why it's on the roadmap. My intention was just to show a way that you could do it today if you wanted to. Also, I'm always looking for opportunities to post examples.

I agree with Adam.