ryan

Thomas, welcome to the forums and thanks for your feedback. I'm having some trouble with context here as 'widgets' is a generic term that can mean a lot of things. But if I understand correctly, you probably want to locate your widgets pages elsewhere, perhaps under a /widgets/ section in the site. Page references allow you to easily break outside of the parent/child relationship of the tree for the times when you don't want items in the tree. You mentioned a fieldtype too, and I think that's always a good way to go. If you want a good working example to start from, grab the FieldtypeMapMarker, which comes with all the components you'd need and is commented and ready to modify towards your needs. Though I should mention this is a regular Fieldtype rather than a FieldtypeMulti (repeatable elements). I'm also thinking that the FieldtypeRepeater that I'm working on may be helpful in your case. With this fieldtype, you specify a template and then it creates a repeater using the fields in that template. You can then add/delete/sort the items (groups of fields) within the page as much as you want. But this new fieldtype is only a work in progress, so may be another week or two till I've got a release-able beta version to play with. If you can give me some more background on what widgets are in this context, I may have some more ideas too. I'm sure we can find a good solution.

I can see using a browser resize where a max width or height is specified, but am not so sure if it's good to have ProcessWire going and creating multiple new thumbnail files just so they can be selected in the admin. Perhaps a good balance would be to display the ones with thumbnails where the 'admin thumbnails' option is selected with the image field, and just use the same thumbnail.

This is what it currently does. It's all handled by the installer (/install.php on a new installation). The profileImport() function creates these directories: /site/assets/logs/ /site/assets/cache/ /site/assets/sessions/ /site/assets/files/ When the mkdir() function fails, it reports this message in red: "Error creating directory: $dir". The error message(s) would appear on the screen after you've entered your database information and clicked submit. I had an experience with one web host where they had some automated process that came through regularly and changed the permissions of directories, without my knowledge. Of course, such an automated process isn't exactly CMS friendly. Another situation where permissions on those directories could be lost is if you have a site running in one location, and then copy it to another. If you haven't transferred it in a way that retains permissions, you'd have to fix the permissions on those /assets/ directories (and files in them). If you have shell access, you could do something like this: chmod -R og+rw /site/assets Is it possible you've run into something similar, or can you think of any other factors?

Thanks for the update!

Thanks for the tip Robert. I'd read about these tags, but never really understood exactly how they worked. Good to get some insight on this and perhaps I should start using them here.

Import/Export with JSON strings (or web services or both) would be nice to have. It won't be very hard to do. I will try to work this into some future update for 2.3 or before.

Thanks Robert, that's definitely good to hear. I will plan to do that. I'm wondering if this will mess up people that are tracking the repository, making them have to set a new remote, or if Git does some kind of redirect automatically? That's probably not an easy question to answer... I may have to do a test to find out. I just want to avoid inconveniencing people as much as possible. I'd rather just keep the repository name 'P21' than cause any problems for people. But hopefully can find a way to rename it without any side effects.

B ?

Thanks for reporting back on this. Glad to hear you found the source of it. And of course, glad to hear it's their problem rather than ours.

I do still plan to implement that, just haven't gotten to it (wanted to get content_css going first). But I'm thrilled to hear the bramus_cssextras solves the issue with removing classes!

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.