Leaderboard

Little admin helper module: Using this module you can view all template cache settings at once. E.g. cache status, cache time (configurable). Furthermore it adds the functionality to clear the entire template cache or just the template cache for a given template. Note that this may cause a temporary delay for one or more requests while pages are re-cached. GitHub: https://github.com/justb3a/processwire-templatecacheoverview

I'm proud to present you: "The Crafters" Premium cocktails from Belgium! Enjoy! https://www.crafters.be/ (Front-end build with https://semantic-ui.com/)

To change settings for all fields via API you could use: /** * make all fields accessible to view only for all roles except superuser * */ foreach ($fields as $field) { if ($field->hasFlag(8) && $field->name !== 'title') continue; // skip system fields `Field::flagSystem` $field->addFlag(160); // Add flags `Field::flagAccess` = 32 + `Field::flagAccessEditor` = 128 // Applicable only if the `Field::flagAccess` is set to this field's flags. $field->editRoles = array(); // leave empty if you want to give access to superuser only $field->viewRoles = array(1026); // assign field view permission to specific roles (IDs) // save the field $field->save(); }

Another problem, or maybe THE problem is, that you seem to not have GD lib installed. As you can see on https://processwire.com/about/requirements/ this is required. Install it, and I think your problem is gone.

Hi All, I know I've been distant, but work has kept creeping up on me and I simply haven't been able to commit time to continue work on Jumplinks 2. At this stage, it's difficult to tell when I'll be able to continue, but I do hope it will be soon as I'd like to deprecate v1 as v2 is already so much better. Again, truly sorry for the delays...

Hello Guy, I'd be tempted to look at running your script directly from a cron task, rather than using a trigger URL. Is there a particular reason you couldn't take the cron route? Also, with that many products, it might be beneficial to pre-process the data so you only have PW process lines from the CSV file that represent changes from the previous import - ie, products that have been added, removed or updated. I suspect many of your 50000 line file will be the same between runs of your update script, but I could be wrong as your situation may be different and your data might be changing more rapidly than I've previously experienced (for example for very fluid stock levels.)

I used it at least here: https://nogajski.de http://joerg-hempel.com http://bella-italia-aachen.de/

Thanks! Looks like I have the module installed but missing the API key. After clearing cache I don't see the other error now. It's good now. Thank you. -Ray

You can hook into ProcessPageEdit::buildForm and modify its arguments. You can add readonly attribute to all text fields (disabled works too), remove submit buttons and disable uploads. wire()->addHook('ProcessPageEdit::buildForm', function (HookEvent $e) { $editorRoles = ['senior', 'marketing', 'office-management']; foreach ($editorRoles as $role) { if (wire()->user->hasRole($role)) return; } // set all text fields readonly $form = $e->arguments(0); foreach ($form->find("type%=text") as $ta) { $ta->attr('readonly', true); } // remove submit buttons foreach ($form->find("type%=submit") as $button) { $form->remove($button); } // disable uploads foreach ($form->find("name%=image|file") as $uploadable) { $uploadable->noUpload = true; } }); But removing submit buttons leaves dropdown items behind which I think is added with JS, so you may need use JS to remove it. (I'm using AdminThemeUIKit, other themes might be different) [].forEach.call(document.querySelectorAll('.pw-button-dropdown'), dd => dd.parentNode.removeChild(dd)); I'm not sure about other fields, though.

This is a story of desire, stilted romance, triumph, and discovery of a simpler way. TL;DR: ProcessWire has hidden goodies in it, but it makes me wonder what else I'm missing. The other day I was thinking, "Hey, I make a lot of navigation. Lists of links, glossary-style HTML sitemaps with links and descriptions, nested menus, etc. I wonder if I could automate some of the markup and stuff by making a custom function?" So normally, I might build a navigation menu in ProcessWire like this: $menu = $pages->get('/')->children; $out = "<ul class='my-menu-class'>"; foreach($menu as $item) { $out .= "<li class='my-item-class'><a class='my-link-class' href='{$item->url}'>{$item->title}</a></li>"; } $out .= "</ul>"; Within this, there are only a handful of things I might want to handle differently for different menus: The classes, the HTML elements, the pages included, the sort, and the limit, for a few. After some amateur writing and testing, I came up with a new object class that would take some config and return a menu in HTML: $out = ''; require_once('./ClassMenu.php'); $menu_settings = array( 'pages' => $pages->get('/')->children, 'label_class' => 'my-label-class', 'label_tag' => 'dt', 'desc_class' => 'my-description-class', 'desc_tag' => 'dd', 'desc_field' => 'description', 'wrap_class' => 'my-list-class', 'wrap_tag' => 'dl' ); $menuzilla = new Menu($menu_settings); $out .= $menuzilla->render(); The above menu would return something like this: <dl class='my-list-class'> <dt class='my-label-class'><a href='/about/'>About</a></dt> <dd class='my-description-class'>About page description…</dd> <dt class='my-label-class'><a href='/products/'>Products</a></dt> <dd class='my-description-class'>Product page description…</dd> <dt class='my-label-class'><a href='/misc/'>Miscellanium</a></dt> <dd class='my-description-class'>Miscellanium page description…</dd> <!-- etc. --> </dl> It worked great, and it was pretty flexible. As I considered adding more complex functionality, I remembered Soma's tutorial about building forms with ProcessWire, and I wondered if I could learn something about building markup from ProcessWire's render method. That's when I found MarkupPageArray. MarkupPageArray, for those who don't know, adds a render method to page arrays, giving them the ability to generate HTML without further ado, like so: $out = ''; $menu = $pages->get('/')->children; $out .= $menu->render(); But what if you don't like ProcessWire's default markup or classes? You can override that simply: $out = ''; $menu = $pages->get('/')->children; $out .= $menu->render(array( 'listMarkup' => "<dl class='my-list-class'>{out}</dl>", 'itemMarkup' => "<dt class='my-label-class'><a href='{url}'>{title}</a></dt><dd class='my-description-class'>{description}</dd>" )); This renders the same HTML I posted above, using only ProcessWire's own API and no custom functions. It brings a tear to the eye. So my question is this: What other common site components are hidden in the API waiting to be uncovered by the hapless and meek in their thrashing about for wisdom?

hi everybody, i developed an intranet application for a client. now we want to grant access to some more employees that get the "employee" role. employees should be able to see all the data (meaning they have to have edit access to see all the input forms holding data for all the fields) but not EDIT this data. which approach would you go? i see this options change all field access settings to make fields non-editable by this role but visible in page editor (would work, but i want to save me from that work) set field access settings via api (how?) hook Field::editable --> does not work. i guess it is only called when field->useRoles is true. Don't know how to hook correctly here. prevent only the page save for this pages totally different approach? thanks for your help!

@jploch: a question from me to clarify: You have installed ImageAnimatedGif module and it produces correct resized and animated variations with calls to pageimage methods (widt, height, size), but it doesn't produce the same result when you use it with MarkupSrcSet? The ImageAnimatedGif hooks into before pageimage resize, and MarkupSrcSet simply calls pageimage size, so I'm wondering what could be the difference here? What is the result of MarkupSrcSet? Images are scaled down and animated, but with artefacts? Can you provide an example? (a variation from direct call to pageimage and one result from MarkupSrcSet)

Can you share the exact line of the error? Is it around here? https://github.com/ryancramerdesign/skyscrapers2/blob/master/_func.php#L246 It's probably because you dont have FieldtypeMapMarker module installed, which brings us to: You need to install the module from Modules > Install > Add New > (scroll down to Module Class Name) type in FieldtypeMapMarker > Download and Install > (Confirm again)

I meant no coverage since the release of version 3. Meanwhile Mike from @cmscritic answered on my question via the contact form with this: I was always under the assumption, that this website contains only articles from selected authors. It seems that I could write him an article, but I think there are more capable members in this forum to write an article. Also is english not my native language. But first, they should fix their register page which currently cannot be found. Maybe @Jonathan Lahijani can fix this? Regards, Andreas

this is the answer GD was the problem, since it was a fresh install, i hadn't installed it... thank you all for the support !!!

I would probably use 1, or go with 2 if I would need some challenge Option 4 sounds fun, but also with a Js/CSS extra to make the inputs "disabled".

Related? https://github.com/processwire/processwire-issues/issues/250

Are there any javascript errors on upload (check with browser's dev tools)? Any other pages or templates have working image uploads or is this behaviour specific to this page only? Image is smaller that 2M (looks it is)? Any clues in PW log files? Try chmod -R 777 /site/assets/files/1234 to see if there are permissions problems.

(Did you restart PHP service?) Any other pages or templates have working image uploads? When you delete the pagefiles directory (/site/assets/files/213 etc), can PW create and upload the file inside?

First check your php version with php --version, because this directive was removed in PHP 7.0 If you're on PHP 5.x, you must have root access to php.ini to change this setting. On debian based systems (tried on Ubuntu) you can find the location of php.ini using locate php.ini and edit fpm/php.ini (if you're using nginx or some other http server/proxy) or cli/php.ini if you're using cli version (apache)

Okay, after some remote debugging collaboration with @Timea over Teamviewer, it turns out there was a typo where he/she created/renamed the comments field to Comments and tried to render it using $page->comments where he/she should've used $page->Comments instead. After renaming the field back to lowercase comments, error was fixed

$pages->addHookAfter('saveReady', function($event) { $pages = $event->object; $page = $event->arguments(0); //check if on template if($page->template == 'item') { //is the checkbox checked to add children if ($page->add_children == 1) { //get the values in the page field type field foreach ($page->page_assignment as $child) { //if selected pages have childen if ($child->numChildren > 0) { //loop through those children foreach ($child->children as $grandchild) { //set values. $page->page_assignment->add($grandchild); } } } } } I figured it out. Two things to change if anyone is looking to do the same. 1. Use the right hook. saveReady instead of save. 2. Add the page object. $page->page_assignment->add($grandchild);

You should place <?php namespace ProcessWire to very first line of the script (to the opening <?php tag), it should look like this

Welcome to the forums! What sort of "News section" is that? Are you talking about a particular site profile? We surely need more info to help.

After my initial question via the contact form of the CMSCritic site in October 2016 was ignored, I asked @cmscritic again and will ask here too: Why doesn't @cmscritic cover ProcessWire 3 at all? Neither the first release of version 3 nor the latest stable version 3.0.61? For a site that calls itself: ... I find this really sad. I don't want to bash them, I would like just to know an explanation.

Hi, here is a very useful tool that check your images in websites against responsiveness: https://github.com/ausi/respimagelint

hello! I created a new site for my podcast Machines-ethics.net and thought I should create a version for anyone to use. With PW-podcast profile you can create one or more lists of pages with content and create one or more itunes RSS feeds to syndicate your podcast (as well as listening online). There is also a blog section and basic pages for anyother page you need. Check out the example site here: http://pw-podcast.nicegrp.com/ and the github here: https://github.com/benbyford/pw-podcast

ProcessWire is mentioned in the repository Awesome UIkit:

This has now been updated and works on PW3. I've also added download hit tracking so at least you have a small amount of stats on file downloads for your podcast. I've also added some readme text https://github.com/benbyford/pw-podcast

<?php /** * getFieldsetOf * * for ProcessWire * * gets fields inside a fieldset of pages or templates * choose to retrieve values * * @param Template|Page $context the page or template * @param String $fieldsetName name of the fieldset * @param bool|boolean $collectValues want to collect values of the pages fieldset? * @param string $fieldsetCloseIdentifier default: '_END' * @return FieldsArray|WireData returns FieldsArray or if data wanted, WireData */ function getFieldsetOf($context, String $fieldsetName, $collectValues = false, $fieldsetCloseIdentifier = '_END') { if ($collectValues === true && $context instanceof Page) { $collectedItems = new WireData(); } else if($context instanceof Template) { $collectValues = false; $collectedItems = new FieldsArray(); } else { throw new WireException("getPageFieldset: first argument must be of type Page or Template", 1); } if (!$context->fieldgroup->get($fieldsetName . $fieldsetCloseIdentifier)) return NULL; $collecting = false; foreach ($context->fieldgroup as $field) { if ($field->name == $fieldsetName) { $collecting = true; continue; } if ($field->name == $fieldsetName . $fieldsetCloseIdentifier) { break; } if ($collecting) { if ($collectValues) { $collectedItems->set($field->name, $context->get($field->name)); } else { $collectedItems->add($field); } } } return $collectedItems; } Some extension of the above code - works with templates and pages. If thrown at pages you may choose to retrieve the values inside the fieldset as a WireData object. edit: @dragan (below) thanks for the hint! Just removed it.

Hi everyone, very sorry for the delays - as you may know, I've been too busy of late to attend to Jumplinks 2. I'm making time as a go along, and would like to briefly discuss the current work taking place. I may or may not have mentioned that I'd like the new Jumplinks to be powered by FastRoute. This improves processing time by quite a bit (haven't measured, but there is far less preg_* going on) and makes development somewhat easier. By using it, however, the syntax for each jumplink would change; but I believe this to be a good thing. As you well know, Jumplinks currently uses the {name:type} base syntax, where type is optional (this invokes smart wildcards). By moving to FastRoute, the base syntax would change to {name} only, which catches [^/]+ by default. That regex is typically used in an MVC framework context, and so may not be completely suitable for the purposes of this module - as such, I am sure this can be changed by overriding the RouteParser (we can default to what is currently used for the segment any type: [\w_-]+[\w.-_%\=\]+). Then, the concept of smart wildcards would disappear, and you would be able to specify your own expressions instead - this is done in the format {name:<exp>}, where <exp> is the expression you would normally use inside of a regex capture group, such as [a-z0-9]+. However, we could add support for aliasing expressions so that the module behaves the same way as it currently does, by silently converting the aliases to their respective expressions, but also allowing more complex expressions to be used. (Note that I chose FastRoute as its syntax closely matches the current Jumplinks syntax, and allows for greater flexibility.) Before Jumplinks 2 is launched, the current dev branch (which will then be moved to master) will be updated to include a JSON/CSV exporter to the Jumplinks 2 format. As an example, the exporter will automatically convert {page:segment} to {page:[\w_-]+}. However, if we choose to use the wildcard type aliasing (discussed above), then this exporter need only export the data on an as-is basis. Note: Due to Jumplinks 2 development, all new features requested by the community will not be added to v1, but will be implemented in v2 instead. It will, however, be easy to migrate from v1 to v2 in order to use those features. I also plan on making v2 compatible with only ProcessWire 2.8 and 3.0, and Mapping Collections will still be supported. I'm writing about this now so that we can discuss it - I'd appreciate your thoughts on the change, which I think is beneficial to the module going forward. (I hope everyone is doing well - haven't been around often enough to see new modules and some of the new progress on PW3; but getting there slowly.) Update: I forgot to mention that FastRoute also allows for optional segments which allows us to jump from, say, /page.php?parent={parent}[&child={child}] to either, say, /{parent}/{child}/ or /{parent}/, depending on the input. Sure, I don't see a wide variety of use-cases for this feature, but I'm sure it'll come in handy to some.

Visible bg color control is something that over 99% (my estimate) of image fields do not require. It would be poor ui design to have it always visible. That is very edge case scenario you are solving (white transparent images) so it shouldn't cause any overhead to other use cases (or even code) that image fields are used for.

@Zeka Simple and good idea! However, we should not leave the checkerboard option out. Better yet, probably all shade versions should still be checkerboards, a dark one, mid range and a light one. We should still signal that these are transparent images. BTW, this thread should be moved to https://processwire.com/talk/forum/5-wishlist-roadmap/ I suppose.

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.