Leaderboard

@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.

Congratulations on release Ryan! Yesterday I spent some time to browse the API Explorer on demo site and I have to agree that ProcessWire documentation is top notch! Huge improvements over what we used to have and way ahead of most projects.

What's in the new master version 3.0.42, and covering the release of the new ProDevTools modules: ProfilerPro and API Explorer. Plus, a look at some of what we'll be focusing on in 2017! https://processwire.com/blog/posts/processwire-3.0.42-is-out-and-prodevtools-is-released/

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

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.)

ProDev Tools: Sold! Sounds perfect to me.

Hi everyone, Here's a new module that lets you control whether multi-language support is enabled at the page / branch level, rather than only per template. http://modules.processwire.com/modules/restrict-multi-language-branch/ https://github.com/adrianbj/RestrictMultiLanguageBranch This is ideal for a site with repeated branches using the same templates where only some need to be multi-language. I think it is confusing to provide multiple language inputs for fields when they are not required - it just bloats the admin interface for site editors. I am hoping to expand this module to allow selection of which languages are supported per page/branch, but I am waiting on @ryan's response to this request: https://github.com/processwire/processwire-requests/issues/54 - to me this would be even more powerful if you have a situation where certain branches need some languages and other branches need different languages. The module config settings shows a summary of the restrictions you have implemented, eg: This shows that we have started with the home page which disables multi-language on itself and all its children/grandchildren (because "This Page Only" is "False". Next we have the /report-cards/ page multi-language enabled, but no inheritance (because "This Page Only" is "True"). The only branch below this to have multi-language enabled is Guanabara Bay and all it's children etc will also be enabled. All other report card branches will be disabled because they will inherit directly from the config settings default status. The Settings tab for each page gives you three options: Inherit, Enabled, Disabled. The screenshots give you an idea of how the Inherit option works and the information it provides based on the status it is inheriting and from where. My goal for this site was to just enable multi-language support for the Guanabara Bay report card branch of the tree, as well as the home page and the /report-cards/ parent. All other branches have multi-language support disabled which makes content entry much cleaner. Hope you guys find a good use for it and I'll be sure to update with the ability to define which languages are available on which pages/branches if Ryan comes up with a core solution for changing the returned $languages. Please let me know if you have any problems / suggestions.

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

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.

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

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

Hello, Yes maybe this could help you https://github.com/NinjasCL/pw-rest

Module: Auto Smush PDF https://github.com/matjazpotocnik/AutoSmushPDF Compress PDF files automatically on upload, manually by clicking the link for each file and in bulk mode for all PDF files. In Automatic mode PDF files that are uploaded are automatically compressed. In Manual mode "Compress" link will be present. This allows manual compression of the individual PDF file. In Bulk mode all PDF files can be compressed in one click. Will process PDF files sitewide, use with caution! Using https://labstack.com/, free (at the moment) online web service that provides compressing of PDF files. There is no limit in file size and no limit on number of uploaded PDF's. No privacy policy available. EDIT April 30 2017: This module is not working anymore as Labstack removed support for pdf compression.

I've been looking into both React and Vue.js for a while and how front-end frameworks like these could integrate with my current workflow of building websites with ProcessWire. Ultimately I've decided to go with Vue.js after using it for certain sections of a few previous projects and familiarizing myself with the documentation, but I assume the same concepts I'm trying to work out would apply for both. So for my next project, I was thinking of using ProcessWire to simply manage content and serve what would function as the website's API. Essentially I would install ProcessWire into a subdirectory of my site's root folder, say '/api', and all template files would serve JSON only. The site itself would essentially be a webapp served by a simple node.js server, with all routing handled by the vue-router component of Vue.js. This way I could also utilise some sort of server side rendering to avoid initial asynchronous content loading. I would then set up my ProcessWire tree structure so that the API routes match those defined by vue on the front-end, only prefixed with '/api', subsequent pages could then be loaded asynchronously. Has anyone used ProcessWire in a similar way in the past, or used it in another way alongside React or Vue.js? I would eventually like to start using this approach for client projects, my first attempt will be an internal project however.

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.

Here are my code snippets for that <?php echo $all_products->renderPager(array( "nextItemLabel" => __("След."), "previousItemLabel" => __("Пред."), "firstNumberItemClass" => "pagination__item--first-num", "lastNumberItemClass" => "pagination__item--last-num", "previousItemClass" => "pagination__item--prev", "nextItemClass" => "pagination__item--next", "firstItemClass" => "pagination__item--first", "lastItemClass" => "pagination__item--last", "currentItemClass" => "pagination__item--active", "listMarkup" => "<div class='pagination'><ul class='pagination__list'>{out}</ul></div>", "itemMarkup" => "<li class='pagination__item {class}'>{out}</li>", "linkMarkup" => "<a class='pagination__item-link' href='{url}'><span>{out}</span></a>" )); ?> and SASS styles ( mixins from foundation ) $module: 'pagination'; .#{$module} { text-align: center; background: $white; border-radius: $global-radius; padding: rem-calc(5); box-shadow: rem-calc(0 1 4 0) rgba(0, 0, 0, 0.1); &__list { @include pagination-container; display: inline-block; margin-bottom: 0; } &__item { display: inline-block; padding: rem-calc(5) rem-calc(10); &--active { a { text-decoration: underline; } } a { @include button-base(); @include button(false, $brand-darker, darken($brand-darker, 5), $white, solid); border-radius: $global-radius - 2; margin-bottom: 0; padding: rem-calc(3 7); } } }

Finally pushed version 0.3.0 which includes your code snippets @kixe thanks for that and a button to remove the cookie for easier development.. Please tell me if all is clear, especially about the new selector, I added a little note on how to include tree parent using just the selector inputfield.. Let me know how you guys like it. Should I still keep both branches? master for legacy (without namespace) and devns for namespace?

That's odd - I don't see how that can happen. An images field will return an array of images (a 'Pageimages' WireArray) if you have chosen that in the field settings. This approach is okay, but if it were my project I think I'd find that a bit awkward. Hard for editors to make a clear connection between which text field goes with which image. And 10 identical fields seems like something to avoid where possible (maintenance would be a pain for a start). Suggestions... If the text field only needs a normal text input then use the Description field for each image. If the text field needs to be a textarea then try the Image Extra module. If the text field needs to be a CKEditor field then consider creating a Repeater containing an image field limited to 1 image and the CKEditor field. Then you can fix the Repeater to 10 items using Limit Repeater (shameless self-promotion )

If you look at Example #2 : https://processwire.com/api/modules/markup-pager-nav/ you can see how to output pagination links exactly how you want.

Hi everyone, @Christophe was kind enough to notice that I had mis-spelled "Language" throughout the module, including the name of the repo on Github and the class name. I think I have everything updated correctly now, so if anyone has already installed it, you will unfortunately need to install again. Sorry about that!

Module updated! There were some cases where the module has produced an error on boolean. This happens if the field where you have added the Textformatter is on the page but it is still empty. Then the manipulation functions fail. I have corrected this with a simple if condition check to prevent this error.

Hello @szabesz here are my settings for the repeater field: best regards

Very useful! I use it in combination with opening hours. For this reason I have created a repeater with 7 repeats (one for each day). In this case it prevents the customer from deleting or draging a weekday from the repeater list.

I just had a duh! moment and thought I should share as it may be useful to others, especially PW beginners. I know a lot of you will go "yeah well duh...." and yeah, well I feel like a bit of an idiot but anyways.... I had a page outputting a table detailing data from about 200 records (PW pages). For each record it searched for child pages of a certain template, probably averaging 3 child pages per record and added some data from those pages to each row of the table. Simple stuff. The page was averaging about 12 seconds to load. Anyway, today I got frustrated enough to try to work out why it was so slow. Turns out I realised that the child pages I was searching for were all direct children, so I changed my search method from $pages->get(....)->find(.....) to $pages->get(.....)->children(.....) and blow me down the page load has gone from 12 seconds to a tad over 1 second. Turns out each child page had many child pages of their own (thousand of pages in total) and all these were being searched with the find() method. Stupid mistake, but I think right from the beginning of my learning of PW the find() method was ingrained. So hopefully this helps some newbies and others like me. Check out http://cheatsheet.processwire.com/page/built-in-methods-reference/page-find-selector/ and http://cheatsheet.processwire.com/page/built-in-methods-reference/page-children-selector/ for more info on these methods and others.

For security reasons you can't directly access php files under site/templates. You will either need to put it in the root of your site, or create a page in the admin page tree and assign it a template that is linked to the required php file.