Soma

Thanks for the report, I just pushed an update. and should be working now. Problem was I never used dates, and I had page outputformatting turned off for easier image handling. Drawback of this is there's no N/A when there's no image found.

Strange, does it work with the PW core modules download/installer? Yeah the github has some crazy redirects, as they changed urls quite often. But since it works for everyone I wonder why it isn't in your case. Looks like you get the redirect message downloaded and not a redirect. This could have to do with a configuration for file_get_contents. There's a max redirect setting in ModulesManager set to 3. You could try setting this up, but I think it won't make a difference. Anyone?

Hmm I tested again and it also works. But the bold and indentation isn't there as with on templates.

Thanks for the feedback. Yes I get that users like to see what they get, but you get it when viewing/editing the blocks (click on asm list label name) and on front-end when go preview the page (unpublished pages are viewable by editors). I think it would a small price to pay for blocks in a scalable manner, easy to deal with and sort them. And as said front-end editing is something that should be considered a lot since PW makes it so easy and clients usually like it. I have also mixed feelings and am somehow aware of drawbacks and issues to could lead to. Also misuse of this, either by the developer or by the user. At the end it all comes down to what do you need to solve with this? And does this lead to bad websites/Use of it (I think most of times yes!) Currently I see it like this: My module pros - minimal easy setup - scaleability - reuse fields and blocks (would requires some complex config setup but possible) - blocks are pages - can use repeaters ... cons - no direct inline editing (if a concern at all) - don't see a way to search via simple API selectors (would require special workarounds, a lot of work) - not easy to limit and reuse things, a lot of work would need to be put in module (grows complexity) ... Using repeaters with conditionals (if supported by PW at some point) pros - easily create different repeaters with different types - inline editing - able to use in simple search API selectors (repeater.field) - repeaters are pages ... cons - doesn't scale as good - some larger setup required - not able to reuse fields and sets created in a repeater - dependency on repeaters - can't use repeaters (inside repeaters) ... and not to leave out already possible approach Using child pages pros - straight forward adding them, almost no setup - preview and editing easy possible on front-end - no dependency - reuse fields, template, and content - they are pages ... cons - no inline editing, different approach (but clients usually get this easily) - could interfere with other child pages (although this can be solved if you put them in a global branch and append them using page selects) - needs workaround for searches using API (but easier as they're direct childs) ... somehow After all I'm looking also further and question things like: what about future major features PW maybe introduce and support in future? Import-Export, versioning, drafts etc. Ever thought of that? Currently I don't know where all this leads us. As said this current module only shows a proof of concept and it maybe one possible to further develop. But first I want to make sure it would be the way to go. I think to use pages in some or other way is a good way to go as you benefit from all features a page can have with all it's API, without relying on a new proprietary system. So this is maybe more what's behind it and more technical, but I think I would love to hear other developers to look and think about this.

Just my opinion. Base font size currently is 10px/20px (body) and just set using #id's to 1.3em. I don't understand why it is has to be this way, as I'm long time used to working with 100%, font-size: 1em for starting point along with media-queries in em too. Some related reading I just found about this why this seems like a good practice: http://filamentgroup.com/lab/how_we_learned_to_leave_body_font_size_alone/ http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ Defining font-size should not happen on containers but on html set to 100% and body on 1em as default first, and then on text elements. We don't think in pixels anymore. In this case this #content 1.3em is just scaling it up from the 10px/20px which seems ok but there's drawback as you in some cases can't overwrite it easily on inherited elements without using #content in the selector again. I'm also in general not very convinced about how the admin default css is built (but it get's better and better) and think it could be cleaned and improved a lot. There's a lot of redundant, unnecessary (and some not even having an effect at all!) definitions it even goes into performance rendering (even if very minimal). I think it need's a global scope rethink and rewrite/cleanup and I would be willing to help where I can. Sorry I'm not so good at explaining and communicate those things with text and even so more not in my mother language. - Desing wise I think colors are important, (I just think not as many as it has now, I count over 10!)) but good UI design is much about font type, spacings, and how elements are presented. Good UI design doesn't distract and confuse, I can't currently say that this theme does solve anything from the default previous theme. Colors should be used to emphasize certain things and elements not brand it. My opinion. People I know that don't like PW aren't saying colors, but general UI design and style not being modern. And that comes down to how big a font is and how much spacing it has.

I'm currently looking into Field dependencies and Repeaters. I made it work with using dependencies inside repeaters modifiying the showIf data attribute added to fieldsets to inject the repeater page suffix _repeater[PID]. This means we could use repeaters to simulate different kind of blocks using fieldsets inside repeaters along with a select where you can choose the type of fieldset you want to enter. I made a short test and it works great. Example: Repeater: Select Type (page field single select) 1203, 1204 Image-Text (fieldset with text, image field) only show if Select Type = 1203 Video-Block (fieldset with text and video url) only show if Select Type = 1204 Now I can set the fieldset visibility to show only if the select has a certain value, means you can swop the fieldsets. I'm not sure about scaleability, since the repeater has it's limits. But I think if you keep it tight with fieldsets and fields and only use a couple (maybe 5-10 types) this could be used to have blocks you can add and edit inline. What you guys think?

There's a bug: $defaultColorTheme = 'warm'; if($input->get->colors && !$user->isGuest()) $colors = $sanitizer->pageName($input->get->colors); else if($session->adminThemeColors) $colors = $session->adminThemeColors; else if($config->adminThemeColors) $colors = $sanitizer->pageName($config->adminThemeColors); else $colors = $defaultColorTheme; if(is_file(dirname(__FILE__) . "/styles/main-$colors.css")) $session->adminThemeColors = "main-$colors"; else $session->adminThemeColors = "main"; $config->styles->prepend($config->urls->adminTemplates . "styles/$session->adminThemeColors.css?v=5"); echo "/styles/main-$colors.css"; // results in -> /styles/main-main.css who finds what's wrong? It doesn't work with with all I tried untill (sessions, browser) I looked into what it's doing there. At least I think. --- Edit: Also by luck I found that my color picker, selecting swatches won't do anything (changing the color), reason it stops working must be with the new admin theme (for no obvious reason), after half an hour I gave up now. It's working with old theme and my teflon, other themes. Really really misterious. No errors, the click event is registered but data attribute on elements aren't updated.

Hmm I'm adding in site config.php $config->adminThemeColors = "classic"; and it's still on the warm. I'm lost why it's not working.

owzim, thanks having a look and testing. I don't really know, as saving the page doesn't remove or modify the ASM list, just delete blocks that aren't selected anymore. The dropdown isn't actually meant to be displayed anyway. I have no plans to do so. I used the ASM select for now as it provides some simple setup and allows for an edit link to the selected items. I found it has some issues using it that way as I'm bound to what it can do or how it does it. I think the ideal way will be to create a new page field widget (like autocomplete does too) so we have full control over the functionality, and are free to create the list item as it would fit. Also to distinct them from ASM and other page field selects. Actually there's now 3 different modals/lightboxes. ASM select edit feature has jquery ui modal, creating blocks has a fancybox modal, frontend uses Fredi modal. Again this is meant to get it working quickly and I think it comes down to what I said above to use one and the same for all, but not sure yet as PW will soon drop fancybox as it's stoneage (1.2.6) and also won't work with jquery > 1.8. Had an error on a different fresh install. Haven't dug deeper into it, since I got it working on another install. May be some faulty setup. It comes up on page edit when pages have that pwbc_blocks_select assigned: I think I know where that error comes from (page select field custom code) but it doesn't show for me. Can you change the custom php code in pwbc_blocks_select to following and see if it solves it? $parent = $page->blocks_parent; if(!$parent->numChildren()) return; return $parent->children('include=all'); I'm not sure I understand. The prefix is the most simple way for the module to recognize the block templates. It has nothing to do with where the template file is located. The module needs to know them so it can change the template filename on runtime so we it can simply call render on the block pages. BTW by "helping out", I actually meant "coding" not testing But testing is also appreciated and needed. Thanks

Just wanted to mention, I made first little update to show the select dropdown again (was set hidden with JS before) just for now. I made last minute changes and haven't really thought about it, that I just had a case where the block was lost and I couldn't reselect it. Updated readme with some additional infos. That being said, consider current state early alpha and a start to get a feeling if this would work out all well. Still many details that need to be addressed. Thanks

For those interested for now, I created a github repo along with some description how to install and use it: https://github.com/somatonic/BlocksContent Thanks

Coming back to this. As mentioned I'm hard thinking a brewing something since a long time, just haven't been able to pull it off yet. It's often good to wait and sometimes it just makes click, also growing with PW and it's ability can make a big difference. Yes even I am still learning, I got something I think would be a good way to build flexible content blocks, it's just not that far yet to really release it. What Ryan has proposed with iframes sound good in theory but I think would be not a good option at all. It could work but I'm not excited about it because of scalability in the admin, scrolling etc and it would be more of a mad hack with JS IMHO. But the idea with using a page field made sense to me and I was thinking a lot about how to bring the concept I have to the admin, so you can add and edit "blocks" on the page. Until now I only got a really rough proof of concept and was working on front-end only, and not at all complete so you could add blocks etc (I created them manually) After some more testing and coding: So far this is how I got it setup/working: (much like repeaters work) - you create templates for the blocks (partials kinda) - you create a template for the parent page of the blocks in the admin, where you also use family settings to restrict children template to the block templates you create Backend - the module creates a custom page field using the input ASM select multiple, you then add to templates you want to have those blocks - the module sets up a parent page in the admin branch for the page you create with this field - the module hooks into the ASM select to add a "+ Add new block", with a click you open a modal where you have the add page screen and template select. Once create you close the modal and the ASM select will have that new option added. You can sort them as usual - the module enables the editlink modal for the selected blocks (much like selected fields on template context) Front-end - the module uses Fredi and it's own script and markup you can use to render the blocks (simply: echo $blocks->render() - the partial templates are located in a subfolder /blocks where you script the output same as you would with a normal template - the blocks have a little toolbar you can move blocks up and down (saved on the fly via ajax), and a Fredi edit link that lets you open and edit the block in a modal - the idea is that you also could also output the blocks manually As said this is all still rough and slowly taking shape, and many details still need to be taken care of, but just wanted to mention. I think a alpha/beta testing is possible very soon but don't want to make it public until it's more marinated and stable. Also if somebody interested in helping out drop me a message.

Look out for wanze's Batcher module.

modified_users_id=....

I use those naming conventions also in certain places for image or file fields and I have no problems.

I'm not seeing through all this but have you seen this http://processwire.com/talk/topic/1421-twig/ ? Maybe something in there helpful? I'm not sure there's another method like you have now, but then I don't care about template engine anyway On a side note: "Instead of contaminating your template's and chunk's markup with php code, you would have the Twig templating syntax at hand." Should read: "Instead of using powerful ProcessWire template syntax code in your template's and chunk's markup, you would "contaminate" your templates with the Twig templating syntax." Sorry but just had to

Just set the value of the field like: $field->attr("value", "121-22"); or multiple I think: $field->attr("value", array("121-22"));

Only if you take HelperFieldLinks, FormSaveReminder, PageEditSoftLock too @adamspirit I'll make a pullrequest to add support for Fredi.

Then there comes Fredi and you can edit them from the front end. Just to make a little example. If you output those repeater on front-end you simply do: foreach($page->myrepeater as $rep){ echo "<div>"; echo "$page->title: $rep->title<br/>"; echo $user->isLoggedin() ? $fredi->setText("[edit repeater element]")->renderAll($rep) : ""; echo "</div>"; } Make a custom admin page that allows you to edit them. Endless possibilities.

I added a check at that place for and you might want to get the following module file and let me know if it's gone. But as said I don't understand, that when it gets that far there's should be a object. Can you tell what file or image field there is where it throws the notice, maybe I understand little more. But nothing dramatic. ChromePhpLogger.module

Ehrm.. I'm looking into this closer and now reading again your post, it's not an error but a only a notice. Further it's in a strange place where it cycles files/images field and I can't reproduce this and can't think of anything atm. Also it seems I get tricked by my own modules an PW. This actually works with cached pages?? Which means even if the page is cached and I'm not logged in it shows the details. Long time since I wrote the module but I think it's simply that the module loads the infos to output as PW even with cache on needs to know what page it's loading". Funny. I would have thought it wouldn't work with cache. Well then with ProCache it wouldn't work.

Thanks jonathan, I will add a check to exit on cached pages. Haven't tested so far with cache on, and if logged in there's no cache. Also I thought ChromePhpLogger only executes when logged in anyway so I'm a bit stumped. Edit: But remember now that I let it on to test with guest or other users. But with cached pages there's no things to debug/log

Does this happen for all modules or just the one you posted? I also experiences rare cases where the downloaded zip is corrupt and it isn't able to open it (it's where the message comes from. If it happens always, it looks like somethings wrong with your php and I have no idea what could be wrong. Have you tried doing it with a manual or different script to open a zip file?