ryan

Pete, I think MarkupCache is always a good way to go, but if you are worried about having some process clear it, then I'd suggest just using a short cache time instead. Something like a 5-10 minute markup cache would probably provide a good balance of keeping things cached and up-to-date.

For scripts of this sort, I don't think they usually belong in the site's dynamic content. I would put it directly in the template file, preferably through an include. For instance, on my sites, I keep tracking/ad scripts in a dir like this: /site/templates/includes/google_adsense.inc Then if a template should have the code somewhere, then my main.php or head.inc/foot.inc template might include it like this: <?php include("./includes/google_adsense.inc"); ?> If you want to specifically enable it on some pages and not others, then create a checkbox field, like 'toggle_adsense'. Then have your template(s) check for that: <?php if($page->toggle_adsense) include("./includes/google_adsense.inc"); ?>

Sorry about the typo, and thanks Soma for finding it. I've updated post #9 to just use $items_per_page instead.

The version of Textile used at Textism is from sometime between 2003 and 2006. I don't think they've ever upgraded it, but I could be wrong. This FAQ at the Textpattern site says they are using a very old version (see bottom of page): http://textpattern.com/faq/180/common-textile-questions

I'm not sure that I understand the question--can you provide more detail?

That was my first thought as well, but I turned it on and it only removes formats (like bold, italic, h1, h2, etc.) rather than the things from the styleselect menu (which are classes). Sounds like we are thinking of the same things. I had tried that one too. No luck. The question is how removeformat works in that case. I didn't for me. I'm wondering if Modx has modified it in some way. But this helps to know that they have a solution there apparently. I haven't actually ever had the need for the styleselect myself or with clients, nor do I expect I will. But I know others have, so that's why I've been trying to find a solution... so I can at least tell people how to do it.

This is now implemented in the latest commit. You can now specify a content_css with any TinyMCE's field options. You can also now specify any TinyMCE configuration option using a new freeform field that was added. You just specify any option in key:value format, 1 per line. So if you want to add a theme_advanced_styles or something like that, that's the place to do it. I did experiment with theme_advanced_styles and content_css, and managed to get it all working without issue. However, I found what seems to be major drawback to using theme_advanced_styles: there's no way to remove a style without going directly into the HTML. Not to mention, it keeps stacking styles rather than replacing them (maybe that's desirable sometimes). However, the result was that I managed to create a huge HTML mess without trying to. It could only be fixed by editing the HTML directly. If it was that easy for me to make a mess, I can't see the Styles select as being something I'd ever want to have a client use. I spent awhile trying to find some option to remove an applied style, but it doesn't seem like there is one. Am I missing something here?

I'm not sure that any template file methodology really matters here, at least not without getting complex. But you could certainly achieve the same result as the module just by placing tags (or blank div's, like in the module) into your markup, using MarkupCache, and then replacing the tags/divs with the dynamic versions. But I think using the module is probably more straightforward/easier. Using the module method, you don't have to use MarkupCache, just template caching.

Interesting, I now get exactly the same thing as you with the Textile 2.3 update (same result in both Textile and Textile Restricted). I take it that everything here is correct except for the *cena* not being translated to <strong>cena</strong>. So I just tried this (taking ProcessWire out of the picture): test.php <?php require("classTextile.php"); $textile = new Textile(); echo $textile->TextileThis('* %test% *cena*'); Result: <ul> <li><span>test</span> *cena*</li> </ul> Bug in Textile 2.3?

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.