ryan

When you do something like this: $p = $pages->get('/some/other/page/'); echo $p->render(); …the $page API var is set to $p for the duration of the render() method. Meaning the original context ($page) is not visible to the system, only /some/other/page/. Once render() finishes, PW sets $page back to the original, if there was one before it. Perhaps we need to maintain an accessible stack of them for the API. But the way you could do it now would be to create an autoload hook, and save the value of $page from a ready() function, i.e. class Test extends WireData implements Module { public static function getModuleInfo(return array('title' => 'test', 'version' => 100, 'autoload' => true)); public function init() { /* needs to be here, but not used */ } public function ready() { $this->setFuel('originalPage', $this->page); } } In the above, you'd be setting a new API variable called $originalPage that would always have the originally loaded page so that you could refer to it when needed.

After successful installation and first login, PW isn't going to report errors on a production site in order to ensure security. When it comes to sessions, PW is delegating session control to PHP's session functions. I believe these will report errors (when PW & PHP will let them), but won't throw fatal errors/exceptions when a session can't be written. If you ever think an error might be occurring, edit your /site/config.php and change $config->debug = true; That will ensure that error messages are displayed. But having all error messages suppressed by default ($config->debug = false) is always recommended for security on any production site. Once your assets dir is writable, you'll also be able to find error messages in /site/assets/errors.txt, regardless of the debug state. Also add your email address to the $config->adminEmail in /site/config.php so that errors are emailed to you as well.

Thomas, thanks for the explanation, I think that I understand now. Diogo beat me to the reply, as I was going to suggest exactly what he said because that's the way I usually handle this need in PW sites. I suggest using asmSelect for your block selection inputfield, as that will enable you to both select the blocks and drag-sort them in the order you want them to appear. Lets say that your page reference field is called 'blocks'. Each item in there refers to a page, and each of those 'block' pages has a template file that renders the block the way you want it output. The template file for your page that shows the blocks can output them like this: foreach($page->blocks as $block) echo $block->render(); So the above would display all of your blocks selected on the page, and in the order the admin dragged them.

Create a new textarea field and don't apply any textformatters to it. Output the contents of that textarea wherever you want to in your template file. Just be aware that you only want trusted users to be able to populate this field, as someone could just as easily populate it with a malicious <script> as with a useful one.

Beautiful site Leroj! Amazing properties here too. I see you are using a multi-tree approach for languages. Are the trees independently maintained, or using Oliver's module, or another method?

Looking good theSeekerr! I could have sworn this must be running in WordPress, as you've managed to do a great job of getting the full blog feel here. Beautiful photos you are featuring there too. Thanks for posting it, keep up the good work.

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?