LostKobrakai

As if I didn't talk about other modules on the todo list in another thread. But actually it's not an inputfield which is bound to be used with FieldtypePage, as this states in the module declaration. ... extends InputfieldSelectMultiple implements InputfieldHasArrayValue The module does add itself automatically to be usable with pages in the settings of FieldtypePage, so maybe it's only missing it's entry in FieldtypeOptions' settings. I'll test this tomorrow and if it's that way, I'll add the addition/removal to install() and uninstall().

Your right with the "stick a image into a placeholder" types, but actually I meant it more in the kind of predefined grid sizes or something like that. Eg. 1/2 width, 1/4 width and such things. My bad of being not precise enough. I've done this for the client behind this request,too ,but here's an example: Think of an blog post about an event. The user uploads all the photos of the event, but they are a lot of them, so the client wants to have two galleries. E. g. one for the lunch and one for the actual event itself taking place. Each should also be accompanied by the text which reviews them. Maybe it's just an edgecase, but until there's another way I have to get used to hanna codes and/or subpages for galleries if need be. At least it's really interesting to see how others feel about this topic.

I don't know if this does help you, but templates are kinda like your models in ProcessWire. So you'd probably need threads, messages, and users (the last one is alread there). States and participations could be managed independently or as fields of thread/message. You can read more on this here: https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/. I would suggest taking the hierarchy of pages in consideration as well (messages as children of thread). Your template.php files are your views, which render the current data. If you're then still in need of some kind of controller structure, url segments and maybe some autoload modules are your friend.

I would support that decision. It's always kinda difficult to bend preexisting styling to fit another look & feel, especially if it should adopt styling of different themes. Also I don't really like the + blocks in between all the actual blocks of SirTrevor. @Ryan As always a really elaborate answer. I can see your points and I would not suggest to acctually remove RTE's or it capabilities at all. It's just I've rarely seen clients or other potential users, which would be pleased to just have these options for images: align_left, _center, _right. Most of the time they want to be able to insert images freely at some place in the text, but it's nearly never just a standart floated image, mostly it's some kind of predefined imageplaces ("hero", "aside", "something") or even galleries of images. There's already hanna code, but that gives a really bad user experience to let people choose images by either copying filenames or adding tags in the imagefield (these tags could also sport a more modern UI) or even not let them choose which file is displayed in a gallery and which is used otherwise. Also it's so visually unpleasing to have something like [[gallery tag=galleryimage]] while it could easily display the actual images, maybe even with simple drag and drop sorting, if this is inside the RTE or as "extra" block shouldn't really matter. It's easy to build custom imagestyling or galleries in other ways, but placing the actual thing within the RTE always feels cluncy. So after writing this, maybe it does only need more custom plugins like pw_image to do such things. Then I would only be left with the unsexy CKEditor modals.

@diogo This doesn't work. I've got it to at least error on the function which gets the options from the database with this. $fields->get("countries")->type->getOptions($page->fields->countries) But there seems to be something wrong in getOptions as I get this error, which is strange as the Argument is supposed to be coming from a function which does not return anything. Argument 1 passed to SelectableOptionManager::getOptions() must be an instance of Field

I have. But mostly stuff, that's not as complex as I'm not as comfortable with such big featuresets. I've also "ProcessStitch" on my someday todo-list, the module to drag and drop fields to templates. So I don't think I'll do such a thing in a really near future.

As it's stated in the blogpost you linked: take a look here https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/modules/Fieldtype/FieldtypeOptions/FieldtypeOptions.module#L438

Yeah the breadcrumbs are currently all over the place on this site.

It's in "About"'s sidebar as "Developers Using ProcessWire".

I'm with Soma on this one. I don't like using RTE's as well. What I would really like to see is something like craft is doing: I can see, that this is a quite complex thing with processwire's pages methodology and PageTables even provides something slightly similar already, but I see it more as a RTE replacement. You'd use it in places where you used only the RTE before. In my opinion such a field doesn't need to support more complex things besides images or textual elements. It would also just save markup for the frontend, while it would probably need to save the different fields somewhere as well. For me it's mostly about the interface. It just guides the user much more, so I would even think it's easier for them to understand, while in the same time limiting the potential points of error. Edit: I don't fully understand, why there's still a image-icon in the screenshot's RTE.

Prices are it's historical use. Today it's mostly used to "enhance" the typographical look. Also "halbgeviertstrich" or "ndash" is not a hyphen. A hyphen is a "bindestrich" and even shorter. (— vs. – vs. - )

Should be no problem if you're not using the fancy new things. Also the CoreUpgrade module does even work this way, with only hiding old files instead of deleting them.

Ryan did change a lot of things to the image field in the latest dev update, see here: http://processwire.com/blog/posts/new-image-editing-features-2.5.19/. I would suggest posting an issue on github, so Ryan can take a closer look at it with the next updates to it.

I've updated the module to give users the ability add pages with Enter as well. Let me know if there are any problems. Edit: I've also added some more fitting styles for AdminThemeReno.

A link to your module would make it easier for people to use it

I'll vote for Ivan's suggestion. I do think that's the right way to go, as it keeps discussions in one place and not scattered around the web.

I've updated the module, I'll update the Screenshot above, too: Templates now show access rights inherited from parents, which are in the parentTemplates array. Templates show up in the "Free Inherited Access" if they don't define special parentTemplates or at least one of the defined ones does not lead to a template, which defines access on it's own. A checkbox in the settings to enable, that the paths of inherited access' is shown. By default this info is reachable via mouse over on the icon. A small description below the table to make it clear what's going on. I would also like to have some input regarding these features. First I'd welcome any recommendations about the descriptions (mouseover / below the table). Secondly I'd like to know what you'd find more understandable regarding the paths. E. g.: products - Defines Access category - Must be child of products, does not define access product - Must be child of category, does not define access The row for product could display either "products > category", which it does currently, or it could show "products > category > product", which would show the current template's name, too.

As all the posts would be hidden, these could of course not be index by searchengines anymore. The grouppage without posts will still be visible.

If someone has editors, who don't pay attention to linebreaks, that's a little css snippet to at least limit the damage an editor could do to mobile textblocks. Especially for those narrow texts falsely placed breaks can harm the layout of lines. @media (max-width: 26.5em){ br{ display: none; } }

You can assign each template its own icon in its settings.

Dynamically build js/css files per single site neglect the purpose of client site caching, which would result in poor performance especially on first visits. Also this sounds quite complex just to stitch together some images and text. In my experience most of my clients even don't want that much control over the layout as long as they can change the content.

I don't know if this helps, but why not call those fields directly from the page object? For the if statement a single = would be wrong as you'd assign ids and not compare them. == and === are here the same, as id's are always of the same type. foreach($mainnav as $p) { if($page->rootParent->id == $p->id) $current = 'style="background: #fff;"'; else $current = ''; echo "<a href='{$p->url}' $current class='{$p->name}'>" . strToUpper($p->name) . "</a>"; } Edit: Soma was faster

How about a little "progressive enhancement" and using flexbox: http://jsfiddle.net/gwp7u69f/ ?

There's already a github issue about this, but no feedback from Ryan by now. https://github.com/ryancramerdesign/ProcessWire/issues/889

I've checked this swiftly after Peters post, my skype doesn't listen on port 80. The other thing, that could listen there would be osx's internal apache server. But this one can easily be disabled by a single terminal command.