Leaderboard

What you are describing is already what PW is for the most part. Though maybe there's additional helpers that could be added to support the front-end developer as you mentioned, I'm not sure. But what simpler context for a REST API could you have than what PW already provides? My experience has been that this kind of module is counterproductive – I deleted the web services module I'd built awhile back because I thought it costed people time rather than saving it. Maybe what's needed is a guide showing you how to implement a simple REST API on your own, without any module, since PW already makes it easy. But I appreciate your comments and will certainly look further into both options. That's basically a theme – what WordPress, Drupal, etc. are for. I'm not against the idea as something for us to collaborate on as a community, but from the core standpoint, it's the opposite of what the core aims to provide. Great ideas regarding the "community" profile, and I think it makes a great community thing, just not a core thing. I don't want to blur the line between PW and platforms like WP, Drupal, etc. Though I do think it's good to show that PW can do these things too. But if we had community efforts like this (and more diversity of profiles separate from it) the core really wouldn't need anything other than a blank profile. Though until that time, I do still think it's good for the core to demonstrate the diversity of output possibilities at the simplest level. These are still on the roadmap and have been for awhile. What gets implemented depends on resources, but front-end image resizing seems like it's got good potential for the near future, while front-end $pages API may take longer (but I still hope to accomplish that for 2017). Chances are I won't be the one developing the front-end image resizing stuff, as the ideas were brought in by another person, and I know little about it. But it is also one of the features that gets me very excited, so hopefully we can get some momentum going on this soon.

the sad thing is i do not expect to get an answer here as i put some time im my last post and did not get an answer either... anyway, from the roadmap 2016: what about the client side image resizing? that would be REALLY helpful in many of my projects... i'm still voting for a rock-solid image handling field. like cropping in predefined ratios and so on. that's an often discussed topic and i don't think that horst's awesome cropping module is the best solution... in my opinion it still feels like a workaround and not like processwire awesomeness... but of course many many thanks for all the great work that lets me have so much fun in my everyday work

@bernhard Client-side image resizing seems to be scheduled for spring 2017: http://processwire.com/about/roadmap/#main

I can see the REST topic being split into its own thread, but on that subject here are some of my own observations/notes based on some recent projects. URLs: Generally, lots of them are needed. This either means lots of pages/templates to keep track of, or implement routing logic in a template and call other classes/functions/modules as required. Content Type, Input Method and errors: Detecting and responding correctly to content type headers has to be done manually - or just ignored, and respond with your chosen format. This is generally OK, but uncaught exceptions or errors will just show HTML instead. Sometimes it's necessary to implement DELETE and PUT HTTP methods as well. Input data: PW doesn't allow deeply-nested arrays/objects (WireInputData@cleanArray) which has proven problematic. Slightly related to the above point - but sometimes data is sent as regular encoded form data, and other times it is JSON or XML in the raw PHP input body. Returning objects: sending page data means creating arrays and specifying exactly should be sent. For text/number fields it's not too bad, but is much more involved when images and Page fields are used. My solutions for this range from implementing toArray() methods/hooks, right up to third party library http://fractal.thephpleague.com/.

I made a few changes in my fork of the module. I added support for DateTimePicker, Recurring Events and DataTables. Here is it: https://github.com/blackberrymamba/FieldtypeEvents

Hi all, the renowned German magazine for computer tech, c't, in its most recent issue #25/2016 is presenting several "WorldPress alternatives", and ProcessWire is among them. (My translation.)

@SamC check you image field settings on "Details" tab. If you want to upload only one image to this field you should choose third option "Single item" , after this change your code should work. Or try $firstItem->mainImage->first()->size(768, 256, 'center');

@Neo Have you seen this? You might utilize it on the frontend with something like: http://www.hongkiat.com/blog/useful-calendar-date-picker-scripts-for-web-developers/ Do not forget that you might want to let your users partially access the admin, so that they can do both... But this is just an idea.

Hi @SamC You can use find("")->first(); $entries = $pages->find("template=news-entry, limit=6, sort=-sort"); $firstItem = $entries->first(); $otherItems = $entries->not("$firstItem");

For everyone using/copying Juergens last mentioned code; there is a little typo in: public function rendepagetable($event){ The 'r' is missing in renderpagetable.

Hello ProcessWire community, Here is my proposal: “ready-to-go profiles” Why more than one? Why not put all the effort into a sort of “standard” way of implementing the frontend. Something that is a versatile and officially supported way of building a site profile. Of course, it should not be forced upon anyone, so that the “blank profile” is always there for those interested. I’m not proposing to change the current philosophy, rather I suggest that we add an additional layer on top of it. There could be only two site profiles that comes with the system: blank and “community”. This so called “community” profile should be: Updatable by site owners in an automated fashion just like modules with the ProcessWireUpgrade module. Hookable, so that part(ial)s of it can be removed and added, meaning it can be changed to one’s needs in a way that is supported by the core. Well documented so that others can easily use it, contribute to it, and can implement custom “widgets” and/or partials that can be used by anyone. These so called ‘Widgets” (template partials / blocks / whatever we call them) would need to implement a standard interface so that the Widgets can be wired into the system no matter what sort of Templates and Fields are used by the backend. With a little bit of code (writing the proper selectors, etc..) the widgets could be wired up to the system, in an officially supported and documented way. This profile would come with standard blogging and portfolio-site like tools already implemented, ready to be used and extended. Any of the implemented features should be easily disabled, as opposed to all the “junk” that comes with WordPress for example (where implementing hooks are required to remove things like RSS, oEmbed, emoji, etc...) If there are features like these, site owners should be able to turn them on/off, nothing should be forced upon them. This site profile should also support something similar to the Css Zen Garden philosophy, so that not only widgets/blocks can be added/removed, but the profile can be “skinned”. These skins could be interchangeable. It would be multilanguage with features suggested by Adrian. To summarize: by working on only one but a versatile and updatable site profile, the whole ProcessWire community could add their bits to it, finally there could be a standard to which one can optionally adhere to. The backend could utilize the very same/similar methodology, so that the community site profile and the admin share the same grounds. It was already mentioned that the backend might introduce UIkit, so this site profile should be built upon it too. For example, imagine being able to utilize the ProcessWire form API on the frontend, fully supported by the site profile’s css framework! Those who use this “community” profile (or any other UIkit based profile they implement) could optionally share UIkit with the system too. I am one of those who would mainly stick to such a profile but it is easy to see how this would help beginners and professionals, and the ProcessWire project too. Cheers

@ryan I have a suggestion regarding the Roadmap. Why not providing a REST API as a pro module or in the core? Headless CMS are on the rise and there's a huge market of Front End developers (Angular, React, VueJS) that would love this. Caching and JWT auth integration would also be appreciated. At the moment setting up a REST API requires a little bit of set up, which may be trivial for a PHP developer but a little difficult for a Front End developer. For example looping all fields, by default won't show image fields or repeater fields, you have to add specific code to get them properly.

Or you might want to do it by using Google. Ryan's blog post might help you get started: https://processwire.com/blog/posts/composer-google-calendars-and-processwire/#the-google-client-api-module To tell the truth, I've never used Google Calendars myself, so I do not know how well it could fit your needs, but some of my friends rely on these Calendars and use them to manage reservations.

What adrian wrote + simply "/site/templates/admin.css" works too (it's loaded by AOS if exists).

Oh *facepalm*, I completely forgot about this! Thanks Adrian for reminding me. Its now working... Thank you TPR.

@tpr is referring this option in the AOS config settings which lets you load additional CSS rules to the PW admin.

Thanks for the reply Ryan! Well, it certainly points in that direction, however I was trying to explain something different which should fit ProcessWire better (in my opinion, of course...). Although this sort of “standardized community profile” could be ready to be used out of the box, most of it would be customizable by developers and “brave enough site owners” only (who dare tinker with code), meaning it should mainly provide code level interfaces (for blocks), hooks (to add and remove blocks), etc... I called them widgets, but let’s call them blocks (or whatever) if it is misleading. By providing a solid starting point for non-developers, more beginners or simple bloggers could choose ProcessWire which would boost the user base, but that in turn should attract more developers too.

With CSS for example: .PageListItem:not(.PageListItemOpen) span.PageListNumChildren.detail:not(:empty):after { content: " (click show children)"; } It's only an extra visual sign that there are subpages, rather than just showing the number of children. Of course you can tweak it to your likings, eg. make it more visible adding a background color etc. You can use AOS's Admin CSS feature to add the rules above to the admin.

events fieldtype would be a good starting point... But you could also go on this simple with pages, a custom admin page and a frontendform -rootpage events/bookings --reservation1 (data from the vititor - or a usersystem conected with a pagefield + data of the reservation) --reservation2 ... a reservation is created with a simple frontendform with two datefields (from - to) and a maybe a check if a existing reservation is affected... build a simple admin page where all not approved reservations are listed and a hook on save to the visitors that are approved by the admin. So you only have to build the frontendreservationform and the backendpage for the admin to approve and with pages you are futureproof for more features. If you have predefiened timeslots you could calculate the dates in the frontend calendar that a visitor see, and validate them on submit. Or if you have a difficult set of events and dateranges i would get back to the events fieldtype for the administration side and let the admin setup every bookable event/time slot with this fieldtype (with the fork even reccuring events...) and the use this entries for generating the calendar where visitors choose from (even with a integer field added to the eventtabel you can set the maximum participants for every single event.... You see there are as always many ways to go to provide a simple admin interface for your customer and all freedom of the frontend for the visitors, too...;) regards mr-fan

Thanx @Alfred I have corrected this.

Hi @SamC - are you talking about a plain textarea field, rather than a text field? See my Github issue here: https://github.com/processwire/processwire-issues/issues/96 If there is something else I am missing, please feel free to comment on that issue.

Making small steps with programming in ProcessWire. But thanks to guys like you (and Processwire itself of course) all the small steps take me further than I ever thought possible. Thanks again and have a nice weekend.

For the title field you need: ProcessPageEdit::buildForm And remember (as I mentioned above) - no need for a module - just use my version in your site/init.php file.

This works for me: $pages->addHookAfter("ProcessPageEdit::buildFormContent", function($event) { if($event->object->getPage()->id !== 1016) return; $wrapper = $event->return; if(!$wrapper->has('body')) return; $wrapper->body->collapsed = Inputfield::collapsedHidden; }); I have included a check for the ID of the page being edited. So in this case it will only hide the "body" field on a page with ID 1016. Hopefully you can modify that for your needs. BTW, I just put that code in my site/init.php file - no need for a module for something so simple.

Hi @godmok. Some time ago I had almost the same questions as you and I came to this solution: $input->whitelist('q', $q); $qs = explode(" ", $q); foreach($qs as $key => $q){ $qs[$key] = $sanitizer->selectorValue($q); } $selector = "template=product, product_cache%=". implode("|", $qs) .""; $matches = $pages->find($selector) And it looks like it covers

I just took advantage of my design skills

WOW, that is a very compelling way of reporting a bug

@adrian thanks, I will check it. Here is a feature for the Misc submodule: change page title field case:

Ok, I think I get it now. I knocked up the following code which I'll post here in case anyone else finds it useful. It seems to work ok public function ___uninstall() { $fields = wire('fields'); // Array of fields to delete $fs = array( 'test', 'test2', ); foreach ($fs as $f) { // Get each field from the array above $f = $fields->get($f); // Get the fieldgroups for each field $fgs = $f->getFieldgroups(); // Loop through each fieldgroup foreach ($fgs as $fg) { // Remove the field from each fieldgroup it's linked to $fg->remove($f); $fg->save(); } // Now delete the field $fields->delete($f); } }

Hi Florian Yes I know that that the english Language is already present in the core. I tried setting the frontend language with the guest language as you suggested. hmm. I can do this only once for all sites as there is only one guest account. If I have now a multidomain site where some sites need to have german as default, others french and again others english as default this won't work. Ok I would need to use the multidatabase approach but than I could not share content so easily like with the one database approach. Isn't there a way to overwrite the default settings so that you actually could define in your _init.php what should be the default language. The main problem with all those languages is to create a good fallback solution and usually they fallback to default. If that is empty hmm than it is an empty fallback. Better woudl be able to define the default language per page recursively. Also to define the order of language tabs so that the first tab always represents the main fallback language. ---- 1. Yes I can set that element. Take as example the minimal site profile which is multilingual. English, German, Finnish When you click home the URL is http://domain.tld/ like it should be but when you click on About already the /en/ element gets inserted I take out the /en/ from Settings and the URLs look correct without language specified. German and fiinish at the language segment already on the home page like it shoudl be if they are not a default language. 2. now I want to change that the default language is actually German - shown without segment and that the English Language is showing /en/ instead. 2.1. I change the guest user to be German and than do Version 1: I insert again the /en/ element in settings and I delete the /de/ element http://domain.tld/en/about/ shows English but when I now change the language to Geman it stays English - everything gets directed to http://domain.tld/en/about/ it is simply not possible to leave the German language path empty as after save the one from default language gets inserted here bu default which is /en/ Version 2: I move the German content to the default Language and the English Content to the actually German Tab in the backend but call it /en/ in the path segment and leave the Default without an element. This works but now I have the problem in the backend as it shows here the wrong namings and still the translatable files are at the wrong place, which means default still shows o translatable files while the former German but now renamed English and /en/ pathsegment Tb shows all files translated into German. -> It is cosmetic but it is unnecessarily confusing. We have three Langauge tabs in Backend Languages - in that profile original it is English - German - Finnish ( 1-2-3 ) (numbers show the Tab position) A Default is titled now 1-Deutsch 2-German 3-Saksan (before 1-English) B German is titled now 1-Englissh 2-English 3-Englanti (before 1-German) When I now go to user Settings I need to choose English to get a German backend and I have to choose German to get my backend in English. I assume that also all terms of the frontend have NOT changed i.e. if you have a translation to German - Anmeldung and English - Registration. Only if I now would switch those German Translatin Files to be the default translation than the frontend would work also with German terms from translation files. But when I switch than I will losse the English translation like written already and it was suggested to insert than again the English translation but there isn't one available separately. --- What would be the better - the logical way: You define the default language in a page and than it works recursevly down the branch until you change it again perhaps inside a branch. Probably it would even be possible to define and sort the languages in that top page and than theTabs show up in that order. Now you would be able to define even several different languages as default in a multidomain site (one Database). The frontend would get called in the defined language in the root-page of a branch/site while the backend would be called by the user defined language. --- It is not logical to click actually on Deutsch to get your English translation in the backend and to click on English to get your Backend translated to German. Like I said it might be only cosmetic and if you know it you could do but I think it is not at all only cosmetic as also terms from the frontend could be translated and than a German website woudl show English (default) Terms to - which is not good. Thanks for your input and ideas!