Adam Kiss

I'm not completely sure, but shouldn't this work? <?php $page->images->add(...); if ($input->post->alt) $page->images->last()->description = $input->post->alt; $page->save();

Soma, as I understand it, Ryan has neutral directory modules with each module, and in each installation, he symlinks modules he want into the installation.

Sorry for hijacking this post a little, but you can add page to user record???

@Diogo: in cases like this, it's safe to go with inline styles - they work everywhere and properly documented, they're also easy to maintain, disregard haters - for simple randomization like this it's okay if you want to do this on bigger scale, I would rather generate 5-10 CSS files (possibly with LESS, SASS, or PHP), and I would randomize which i include (rather than the properties themselves).This, way, you have both randomized CSS and less computing involved/caching available.

It depends what you need to do this for; Give us little example, and we'll tell you

Hi pers0n and welcome to forums, just use PageField type, which works as pointer to single/multiple pages. First create gallery, and then add it to your userpage via the PageField type. Depending on your settings, you can select different methods of input, but I'm gonna let you find this out now.

I quickly went through main.js. I just realized I really have to dive in some frontend coding here, right after I (finally) finish the public design Edit: I am already in bed, but will check current frontend this weekend, after I put together test install to see what can I do with this.

It's been a little while since I've since frontend code of PW admin, but I actually am against dropping support for IE8. IE8 is pretty much decent browser - I supported IE6 until last year actually. Other than that, the real reason why I am against dropping the support is that these mentioned bugs (at least this one with deleting images) can't be really hard to solve; since we use jQuery, most of the Xbrowser differences are already (almost) cleared for us. I might be able to look into this later some time (I have to pull to my PW2.1 version anyway, and also create at least one empty install for testing)

It's cool tip – with some cool PageArray modification aswell. Regarding titles itself; I would never do this, unless it would make total sense for visitor (e.g. some kind of eshop, where I can imagine something like 'Yamaha XZ-200 – Electronic keyboards – keyboards – products) – that looks okay. Otherwise, I am more of fan of 'copywrite for people, not google'.

Hm, parts of that code (I currently don't have "test shit out of it" processwire installation, and I'm lazy to do so ) ran okay for me; Have you tried passing '$template->name' rather than '$template' as Page constructor argument?

This is rather some heavy CSV But to get you started, here some pseudocode I would use for the tree itself (and this is without using the csv importer; just pure php - assuming you can access .CSV via '$record['field_name']' notation. <?php $parentArray = array('1'=>'/'); //typo3 pid -> PW API url translation foreach ($csv as $csvRecord) { $newPage = new Page(); $newPage->template = str_replace('.html', '', $csvRecord['layout']); $newPage->parent = $pages->get($parentArray[$csvRecord['pid']]); $newPage->title = $csvRecord['title']; $newPage->name = $csvRecord['name']; //assuming you have access page's url string; create from title if needed; $parentArray[$csvRecord['uid']] = $newPage->parent->url.$newPage->name; //add new 'parent array' record for next pages //continue with data import $newPage->save(); } also, for layout->template translation, you can either use the notation I used in my example (that is, initially name your templates the same way layouts in typo3 were named and then rename them) or, alternatively, you can create another translation array (the same way you do with parents, that is, create translation array [this time pre-populated], like so): <?php $layoutToTemplate = array( 'layout_3_v_col1.html' => 'page', 'layout_3_v_col2.html' => 'product' ); (names of typo3 layouts are examples only)

1. urlencode() and urldecode() dosent help? 2. cant you change the radnom (i guess) id generation to include only small/big letters and numerals, for instance?

:D I don't know whether this makes image of friendly community at all, but nonetheless, it made my morning

Sounds awesome, but I'd really be much much much more interested in how you'll do the db syncing later, if I can ask?

I can do sk-SK and cz-CZ

I actually hijacked one of the 'post.php' or 'page.php' to have it me-formatted XML (because I used some plugin, which used a lot of integer fields related to its own db structure), which I imported via dead-simple importer (one foreach loop together with simplexml)

Hey guys, thanks. @Nico: I did not move users, only posts and pages (although, posts were e-commerce). I also have tutorial written (almost), I'm just waiting for myself to finish my website... doh

Well, I believe I thought about it too Anyway, having some hidden page title for instance 'repeatables' in the 'admin' tree is the best option IMO – that way, you don't have repeatables and 'real' children mixed up either in tree or in the matrix editor in admin (or both). Same thing Diogo said, only I would hide it in admin, so you don't see it unless you need to; This would be minimal viable product; possibility to select one of existent templates, and have possibility to add/edit/remove them in the 'edit page' of their parent page; In next release, you could add creation on the fly: by adding a column, current 'repeatable' template would be cloned and another field added. Or something like that.

@slkwrm: yes it does, although not on page per se, only in '$page->body' field. Not to make assumptions, but there shouldn't be much more other width='' occurences, if you use HTML5/XHTML1–those are generally only used on images (and I can see valid use on table/tr/td elements).

Hi Stewart and welcome to the forums; It's located in the field settings; find fieldset 'Inputfield settings' for your TinyMCE field. In this fieldset, there should (closed) fieldset 'TinyMCE Advanced configuration'. In that, find 'valid_elements' fieldset (should be last) – there is TinyMCE valid elements string. second in this coma separated list is a tag, just add 'rel' in the array of allowed attributes. Adam

You're welcome I am going to add 'solved' tag to this topic.

Isn't the save call problem? <?php $page->save; //should be $page->save();

I agree that configurable options in PW admin need some more prominent space; I've already come up with few solutions, I just have to finish some other PW-related work and it'll be awesome

Hi there. In recently published/uprdate roadmap, required field are planned for version 2.2 (source: http://processwire.com/about/roadmap/), so this feature should be available by the end of the year in the github build. Right now, I would solve this by the default values + stepping on editors to do their work properly, or possibly, you could create module with outlined function below: Hook to page::save (before) Check whether the template fits, else do nothing [return;] If it fits, check for existence of fields If they are empty, cancel the save and return to page edit To make this easy for editors, you could create small JS snippet, which locks save buttons, if your required fields are empty (with jQuery, this should be like 5 line snippet)

It depends on what images are you talking about. It can be either image field, or images used in tinymce (text) field. In case of image field, the answer is simple - just generate your output without those attributes. As with TinyMce, this will be tiny bit harder-you'll have to run preg_replace on your text field, like so: <?php $content = preg_replace('<<<regexp>>>', '', $body->content_field); instead of <<<regexp>>> will be your image attributes targetting regexp-i'm on iphone so it would kill me to come with it, but i'm sure you'll find something acceptable on google