Leaderboard

I think cleanest solution would be different kind of RTE. Something that all the big newsletter softwares are doing (mad mimi, mailchimp etc). Pity that there ain't any of those open sourced. I also think it could produce straight HTML and be somewhat drop-in replacement for current editors, keeping the metadata inside data-attributes or classes. But I have had less and less need for this kind of stuff, and I believe in future even less. PW and future is more and more about content management for multiple platforms (mobile web & applications, computers, television, consoles...) and there "layout building" is something that each medium does, not the CMS.

GitHub: https://github.com/adrianbj/ProcessMigrator This module has gone through lots of iterations with lots of new functionality each time. It is now a fully fledged content migration tool. *** Please be sure to read the GitHub ReadMe to find out what it can do now as most of the posts in this thread are no longer correct regarding its functionality Once it is release worthy, I'll create a fresh thread with all the details. This modules allows export, sharing, and import of page lists via JSON files. It takes care of replicating all the pages, as well as creating any templates and fields that are needed. I have defined "Page Lists" as page trees (parent and children) that store selector values for a Page fieldtype. An example would be a list of countries that would be used to populate a countries drop-down select field. The fields might include: Country Name, 2-digit code, 3-digit code, number code. I would like to suggest a place where we can post json files to be shared and updated - maybe a dedicated github repository? Start of a repo of lists ready to import is now available: https://github.com/adrianbj/ProcessWirePageLists It might handle migrating other simple pages trees as well, but it should not be considered a tool for migrating general pages as it does not handle associated files, nor does it handle fields which store arrays. Probably lots of other things it doesn't handle either It now handles migrating all (I think) field types, including repeater fields, page fields, all Profields fields, multi-language versions of fields etc. The only omission is the actual uploaded files and images in file/image fields. WARNING: This should be considered an Alpha module - please don't use this on a live site at the moment and be sure to back everything up before testing. Would appreciate any feedback on the concept, the code, and the idea of a shared and community edited resource of these files. Also, would love to hear what page lists would be good to share. Here are a few quick ideas: States (separate files for each country) Measurement units Languages Religions Race Academic subjects (chemistry, biology etc) Publication types (book, journal article, newspaper article, newsletter, thesis etc) Car makes and models Anyone have a better idea for a name, or how to better describe "Page Lists"?

Hi folks This isn't a new concept, but since I use this on several sites and was getting frustrated by having to add the fields and put the CSS in the admin template's CSS file to have it overwritten on updates I thought I'd make it into a module where it should work regardless of which admin template you use and shouldn't be affected by updates since the CSS to hide the fieldset's container styles is now in a separate CSS file completely. Unfortunately I can't find the original topic where this concept was introduced (if anyone can find it, please link to it as I can't take credit for the idea), but essentially what the module does is create a left and right columns that are actually fieldsets, and you simply add the fieldsets to your template and place fields in each of the columns to suit yourself. Enough chit-chat, the screenshot below will explain it better: I think when this was originally discussed it was back before ryan had introduced field widths, but I think this still has a place for where you have differing heights of field (as per the ASMSelect field on the right of the shot) where using field widths would result in a space before the next row of fields. In fact, this works especially well on pages where you have small bits of information to enter and want to leave a larger left column for text editor, image and file fields. The beauty of now having variable width columns per-template now as well is that you can change the fieldsets from their set widths of 70% and 30% respectively to whatever suits your needs on a particular template. Download from the modules directory. Usage Download and install the module above Add admin_column_left and admin_column_right fieldsets to your template and put the fields in the relevant column fieldsets (Optional) change the field width for either column, taking care to leave 1% for a gap between the two columns (default is left column at 70%, right column at 29%) That's it!

Here is our website using ProcessWire, still work in progress: http://www.mokkivertailu.fi/ The site is a search engine for rental cottages in Finland. Cottage owners can register and add their information while users can search and browse the database.

Just pushed a new update that supports multiple videos in multiple fields on a page, so this should now work seamlessly with the VideoEmbed module. Also, you can now select the fields to search and the images field to populate using dropdown selects, rather than manually entering. The list of fields is limited to appropriate field types. Thumbnails in first post have been updated to show new functionality.

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.

Yes! I also think that the admin should be as neutral design wise as you said as possible. A good example of this is Nico Knolls Dark Business, appy, clean and neutral design.

It's a leftover from the old admin theme (I didn't create these files from scratch). You are right, we can drop this left/right padding as there isn't any need for it. Also a leftover from the old admin theme. In 2009/2010 there was still a little bit of lingering IE6/IE7 bad habits–which meant using absolute positioning when floats were more appropriate largely because IE was not consistent with floats. Obviously that's not the case anymore. I think your suggestion to change these to floats makes sense. Though also not sure it really matters much in this case, but I do prefer floats from the responsive side, so that's a good enough reason. Your screenshot is too bold for my taste, but maybe it makes sense for one of the color themes to take a bold approach like this. I understand that very often what looks better depends somewhat on how the platform and hardware/screen render type, so it's good to provide options. I'm not familiar with the outline you are talking about (Chrome OS X), but will try it out and add it if it provides some benefit in Windows or another browser or something. Kind of depends on the screen, it's quite visible here. But I see no harm in increasing the value. It's preferable to do it with padding rather than line-height since it's possible for long titles to wrap, and we want wrapped titles to still look like a single item. But I am not a fan of increasing the padding or line height here, as it just means a lot more scrolling on the sites I work on (which tend to have lots of pages). Again though, I see no problem with providing this as an option in one of the color themes if people find it more attractive. I find it less attractive myself, but it's all subjective. I think a good goal here is to support a broader range of preferences by providing more options, and so this may be one of them. ProcessWire is not a corporation so we don't have corporate colors. But we do have brand colors, and I think we will stick to them for our branding and marketing. But I'm feeling like the application itself should be less branded... would rather have people think of it as a tool like their text editor. It bothers me that a seemingly large group of people have ignored ProcessWire largely because they don't like the way the admin looks. And the colors are one of the first things mentioned. Many of potential audience thinks they look childish: light blues and pink, which are also known as baby boy and baby girl colors. I like the colors myself (a lot), but have heard it enough objections to know it's not an isolated opinion. Those people aren't here to tell us about it in the forums because they were turned off by subjective things before they got to know why it would be a great tool for them. So I wonder if the admin needs to be more neutral and not defined by colors or brand, but by its usefulness as a tool. I want people to focus on the tool and not on the colors, because the colors really have nothing to do with the tool at all. While there has to be default, it should be fairly neutral and easy to change. Ideally it would be selectable from the installer so that it's clear from the beginning that it's a tool to get stuff done more than a brand to buy into. By the same token, I wonder if there shouldn't even be a PW logo in the admin, or if we should make it something the user can easily replace with their client's logo. With regard to color schemes, I'm also hoping some others here that are better at it than me will put some together. I think I've setup some good starting points that I like, but colors are always subjective. I think someone else can do better here, so I've tried to make it as easy as possible by isolating all the components of the color scheme in a separate file that can be changed easily. So if anyone is interested in experimenting with colors, please do and post your results when you've got something that you think looks good. These are standard jQuery ui-menus, which are meant to follow the scale of select boxes (I think that's what they were trying to do anyway). I'm not yet sure if I can make major adjustments to them without affecting other jQuery UI widgets that I don't want to, but I can experiment. However, the plan is that these will descend another level for templates and fields (which can potentially include a lot of nav items) so I think it has to be a careful balance. This is something that I can confirm is very much affected by your screen. I have two screens connected to my computer, and I can barely see the lines on one of them, while the lines are nearly too dark on the other. So what you see now is a compromise between the two in finding the right darkness level for them, based on my own screens. No doubt we'll want to provide higher contrast options here in one or more of the color themes, to account for these variations. But rather than basing it on my screens, it would be good to hear from more people to see where the right balance is for visibility of the box lines. I've tried it both ways. To my eyes it looks whiter, but not cleaner. It's subjective of course. My personal preference is to have a color, a line or something to make navigation part of an interface with visual hierarchy that rather than free floating. But I think it doesn't hurt to experiment here in one of the color options. I actually thought it worked ok that way when testing it in the Modern color theme. I don't think we can legally connect an admin theme with my TypeKit account. Maybe there is another resource we can use for this, but it's got to be something that doesn't require connecting to an outside service. The typeface also has to be one that is fairly generic. Arial is about perfect IMO due to it's anonymity... keeps the focus on the content without the type influencing the personality or suggesting style. The goals in the admin are entirely different from the goals on the marketing/brand site we're on now. Arial doesn't do anything for me (which is partly why I think it's a good fit in this case), but if we can find something that has similar characteristics while looking newer or more professional, I think that would be a desirable thing.

Add this to your template file: $useMain = false; See the note about this in the /site/templates/_init.php file

While either of those solutions may work for this case, Radek's suggestion is the safer and recommended one. Your guest user is the default user when no user is logged in, so it's best to keep the guest language as the default. There is nothing about the default language that says it has to be English. You can make your default language whatever you want it to be. But the purpose of having a default language is exactly for situations like this. Plus it means you can code your templates in a manner that isn't dependent upon one language or another.

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

A small update - I have added support for import options so now you can decide whether you want to import just the fields and templates, or the entire page tree at the import stage, regardless of what is in the exported JSON file. Of course you can't import the page tree if it wasn't exported, but you can import just the fields and templates from a JSON file that contains the entire page tree. I have also added support for importing page trees directly from the repo at: https://github.com/adrianbj/ProcessWirePageLists Just choose the "Shared JSON Packages" option when importing. I haven't tackled the repeater field etc issues yet, hopefully soon. Will also be adding more shared packages soon and would love any contributions See the attached screenshot showing the direct page tree import using Ryan's awesome new admin theme

I don't think there is a simple PW way to do this like $page->my_select->title. This is ugly, but works: foreach(explode("\n",$page->fields->my_select->select_options) as $option) { $valueLabel = explode(':=',$option); $value[$valueLabel[0]] = trim($valueLabel[1]); } echo $value[$page->my_select];

Login screen is localized thrue default language. If you want login screen in other language than en, load your non en localization to default language. Before user is logged on, system did not know about users language setting.

v6 now has optional (default) automatic file renaming. Images will be named with this format: videoID-ImageName.jpg where, the videoID is the ID of video from YouTube or Vimeo and ImageName is the name of the image and matches those names that are in the Youtube Image Names and Vimeo Image Names config fields. I think this standardized format will make it much easier to call the images via the API in templates. Ok, hopefully that is it for a while unless anyone else has any other suggestions

Thanks Martijn, That high res version is great - "maxresdefault". It is the only one that doesn't get letterboxed, which actually makes it useful, unlike the other ones! I also added "hqdefault" and "default" as other default options. I also added checks to make sure an image exists before trying to add it to the images field. Now along with Antti's thumbnail module, Horst's PIM module, or your Image Interceptor module it should be possible to manipulate that high res version however the user wants!

Thought I'd step in and show support for this - love the idea as a whole and Marty's hit upon an interesting use case there right away for easily setting up small sections of repetitive content that is a bit more modular perhaps than a site profile and useful when such things are outside the scope of a module themselves. @Soma - I need to pay more attention to the cheatsheet as I'd not seen getArray() - would've been incredibly useful when I was debugging something the other day and print()'ing a page object... which causes a mess on the screen

Hi Jason, if you're doing it just for a few pages, you don't need any module/plugin; you can do this simply by using templates! Create field 'redirectTo' – customizable, of course Set that field to be 'single page', and select the inputfield you wish Create template 'redirectPage' – again, custom put following code in your template file Create page that links to original page you've made your virtual page Code for your template: <?php /* * Template: redirectPage * * Used to redirect URL adress to other page with 301 HTTP code */ $session->redirect( $page->redirectTo->url ); I actually use this at least once each site.