ryan

Are you sure that you need template caching? Template caching doesn't have to be used, it's just an optimization for situations where it makes sense, and this may not be one of them. But what Antti mentioned with using some JS for your dynamic parts can be a good way to go because even if the entire page is cached, the JS portion still executes when the page is viewed and can always be dynamic. Another option is that you could make a simple module that hooks Page::render and replaces your empty <div id='member_bar'></div> and <div id='comments'></div> with dynamically populated versions. This will work even if your template output is cached. Here's an example of such a module: <?php class PetesModule extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Module for Pete', 'summary' => 'Replace member_bar and comments divs with dynamic populated versions', 'version' => 100, 'autoload' => true, 'singular' => true, ); } public function init() { $this->addHookAfter('Page::render', $this, "pageRender"); } public function pageRender($event) { $page = $event->object; // abort for templates you know you won't be needing if(!in_array($page->template->name, array('template1', 'template2'))) return; $out = $event->return; $bar = "<div id='member_bar'> ...dynamic content... </div>"; $out = str_replace("<div id='member_bar'></div>", $bar, $out); $comments = "<div id='comments'> ...comments here... </div>"; $out = str_replace("<div id='comments'></div>", $comments, $out); $event->return = $out; } }

I've just implemented a few changes/additions to this module: Upgraded to Textile 2.3 Added a separate 'Textile Restricted' version that may be used with untrusted user input (blog comments, etc.) Moved the module to GitHub: https://github.com/ryancramerdesign/TextformatterTextile To upgrade, replace your files in /site/modules/TextformatterTextile/ with the files from the new version.

I'm guessing this one can be solved just by using POST rather than GET?

Keithar, that looks like the output of the Markdown module rather than the Textile module. Can you double check that you are using Textile (only) in that field and not Markdown? I just tried it here with TextformatterTextile and this is the output I got: <ul> <li><em>name</em> <strong>price</strong></li> </ul> Please let me know what you find.

Diegonella has it right. If you need to keep your existing index.php in place, then you'll want to rename ProcessWire's index.php to something like pw.php (or index_old.php like in Diegonella's example). Then edit ProcessWire's .htaccess file. At the bottom you'll see a line where it sends the request to index.php. You'll want to change that to whatever you renamed PW's index.php to be, like pw.php. Also now that I know you need to keep an index.php from your old site, I suggest going with the method Diogo mentioned and replacing your homepage last. As for the <base> tag, I have no idea. I've never used one.

Nico, I guess the question is then, why do you need those Inputfields? I can't figure out why they are necessary there.

Lars, you can do this if you convert your homepage to ProcessWire first. That's because ProcessWire needs /index.php in order to run. If you have an /index.html already in place, you'll probably want to remove it too. But you can leave the rest of your site files in place as ProcessWire won't attempt to capture pages that already have existing files on the server. So it should be fine to go ahead and install ProcessWire, and just leave your existing site files where they are (except for the homepage).

Achabany: Here's an old post that has a ZIP file with high res logos: Unfortunately I don't have a vector-based version, but the ones in that ZIP are quite large if I recall.

Martind, something's not quite right here, as your screenshot shows columns for "body, headline, summary, title". It should say "name, title, language translation files". I suggest uninstalling the LanguageSupport module and then try installing it again. But first check that you don't already have a template in your system called "language" or "languages". The installer should recognize this if you do, but double check just in case. Also, your system may not support extraction of ZIP files, so you'll want to unzip the language pack first and then drag in all the .json files instead.

Good and interesting ideas Oliver. I'm not sure how simple this one would be to implement, but it's something I need to keep thinking about--maybe there is a simple way to do it.

Sinnut posted this several months ago in the pub. Maybe adding this to your .htaccess would help? # ---------------------------------------------------------------------- # Better website experience for IE users # ---------------------------------------------------------------------- # Force the latest IE version, in various cases when it may fall back to IE7 mode # github.com/rails/rails/commit/123eb25#commitcomment-118920 # Use ChromeFrame if it's installed for a better experience for the poor IE folk <IfModule mod_setenvif.c> <IfModule mod_headers.c> BrowserMatch MSIE ie Header set X-UA-Compatible "IE=Edge,chrome=1" env=ie </IfModule> </IfModule> <IfModule mod_headers.c> # Because X-UA-Compatible isn't sent to non-IE (to save header bytes), # We need to inform proxies that content changes based on UA Header append Vary User-Agent # Cache control is set only if mod_headers is enabled, so that's unnecessary to declare </IfModule> Also, I am going to add the meta tag Antti suggested to the default admin theme (just did, and will commit it soon).

I think this is exactly the way we'll implement it. Plus, it'll be so easy to do hopefully I can do it this weekend (I've got to be at a client's location today).

Very nice! I like it! Nice and simple and useful. You are coming up with all kinds of great stuff for ProcessWire, I can barely keep up. Ideas for future versions: It'd be very cool to have config options as to what corner you wanted the links to appear in. The ability to disable the new page and/or logout buttons (for those that just want an 'edit' button)

Thanks for the issue report Achabany--I will correct this like you mentioned. Also, thanks for the work on the French language pack. I agree about setting up a board just for translations. I'm still learning the ropes of IP.Board but hope to have that setup this wekend or early next week.

The existing comments module does keep the user ID already, though it doesn't use it for storing the user name. But you could make an autoload module that changes the 'cite' property of a comment to the user name. This is something that has to be done at runtime since a user's name may have changed since the comment was posted. public function init() { $this->addHookAfter('FieldtypeComments::wakeupValue', $this, 'hookWakeupValue'); } public function hookWakeupValue(HookEvent $event) { $value = $event->return; foreach($value as $comment) { if($comment->user) $comment->cite = $comment->user->name; } } To have the comment displayed instantly, that will be easier to solve, and doesn't require modifying the existing module. Just do your comments processing/output generation before you "echo" any output. When a comment is posted, do a $session->redirect('./'); I'm making a page-based comments module which will have the same sort of flexibility as the rest of ProcessWire, though it'll be a bit before I've got it finished (and some projects have to come first). But this page-based comments module should support nearly anything you could want to do with it, without having to modify its core code.

We will have a solution for this one very soon.

Achabany, I'm getting the same thing as Nikola. Chrome 16. (those Chrome version numbers just keep climbing!). Also noticed an issue that can affect some sites but not others. See the attached screenshot. If you add any items to your admin nav, then they can get overlapped with the user/profile/logout links. Some modules add items to the top nav like this. It might be safer to locate that user/profile/logout line above the search... or if you like it where it is and want to get fancy, you could always locate it above the search when $pages->get($config->adminRootPageID)->numChildren > 4. One other minor thing to note in the screenshot is that there's no padding to the right of the title input (and any other full length 1-line text input). Though that's a minor point that doesn't affect use at all, and I didn't even notice it till after I took the screenshot. Nice to see it's multi-language ready too. Speaking of which, since you worked the topnav.inc into your default.php, you don't need to "translate from the context of default.php", since this is assumed: $title = __($title, dirname(__FILE__) . '/default.php'); // translate from context of default.php The above line isn't hurting anything, but it's also not necessary. You can just do this: $title = __($title); …or this (which is slightly faster, but not as pretty): $title = __($title, __FILE__); Thanks again for your great work with this theme.

Great admin theme Achabany! I only have a minute on the computer so couldn't try it much, but got a quick look and love what you are doing with the PageList. I look forward to using this more tomorrow. Thanks for your nice work!

This is working in 2.2. I just had to do it yesterday. I was going to say "what password are you using", but that's probably not a good idea. Instead, why don't you try with another password. There is a known issue in the queue with passwords that are exclusively non-ascii. If you find it's still not working, give me an example of a fictional password that I can use to reproduce the issue.

Oliver, there might be some bug in the version of MySQL there. But I would suggest exporting the whole database with PhpMyAdmin to an SQL dump, then create a new database, and import the dump. Then switch your site to use the new database (by editing the bottom of /site/config.php). Just in case there's a problem specific to that DB, that would at least put it in a fresh state. Please let me know if you find anything else.

Nice module Nico! I have a few suggestions: 1. The current way you are using $pages->find() to find files is going to mess up the pagination for any pages that have blank file fields. For instance, on the site I tested, I have 30 files, but hundreds of pages with blank file fields. I ended up with 90+ pagination links, where most pages were just blank. So I think that finding files by template is probably not ideal. Instead I'd suggest finding them by field. This will work: $fields = $this->fields->find('type=FieldtypeFile|FieldtypeImage')->getArray(); $pages = $this->pages->find(implode('|', $fields) . ">0, sort=-modified, limit=10"); 2. You have some stray var_dump() functions that are breaking the display in some parts of the module. 3. In your executeDelete(), I don't understand why you have this line: foreach($f->page->getInputfields() as $field) { It doesn't seem necessary? I would get rid of it if you can.

I didn't know about this. Sounds useful and I like the sound of it, but haven't seen it. Yet another thing I need to investigate further. I think we'll just go one step at a time here and start with implementing your improvements. It'll be a few days here before I can make these updates in the core, but I think it'll be a good thing to do. The only plugins PW has into TinyMCE are the pwimage and pwlink plugins (images and links). These are powered by ProcessWire rather than TinyMCE (for the most part). What sort of extensions or improvements would you recommend?

It shouldn't matter if you've renamed the admin page, but thanks for mentioning it. Those are the kind of things that are good to know. Let me know if you find that you can reproduce it. Thanks, Ryan

Here's how: So you basically create the blog site, then run that profile export. Then take the /site-default/ directory from a blank ProcessWire (one where the installer hasn't yet been run) and replace these directories in it with the ones from your blog site: /site/templates/ /site/modules/ /site/install/ Then zip up that entire /site-default/ directory, or put it on GitHub. This is a site profile. Now anyone can replace the /site-default/ directory in a new copy of ProcessWire with yours, and it'll install your blog site. I also often use this technique for migrating client sites from dev to live.

Testing here in 2.2, but I can't duplicate. Can you think of any other factors involved? Has your site been through a profile export/import (like 2.0-2.1 upgrade)? Have any admin-related pages been renamed? Let me know if you can think of anything else that might be different from a stock installation. Tahnks, Ryan