Leaderboard

Last week we talked about new Fieldset modules for ProcessWire, and I was happy to hear about all the enthusiasm for these. In that post, we primarily looked at the new FieldtypeFieldsetGroup module in detail. This week we'll continue along a similar subject and look at the new FieldtypeFieldsetPage module. Actually we'll do more than look at it, we'll release it – it's now in ProcessWire core version 3.0.74, ready for you to use: https://processwire.com/blog/posts/processwire-3.0.74-adds-new-fieldsetpage-field-type/

@Roych You are only retrieving one BackgroundImages item with getRandom(). To get multiple items for your Wire Array you need to specify how many you want. https://processwire.com/api/ref/wire-array/get-random/ Alternatively to retrieve all BackgroundImages in random order you could try: <?php foreach($pages->get('/settings/')->BackgroundImages->shuffle() as $bck): ?>

I thought it might be worth mentioning - given remarks above - that another three years on this feature is still getting new users This time, it's to fire off my own page-renaming module before the Custom Upload Names module makes updates when the page name changes. This has allowed the modules to work together really easily and, I suspect, saved quite a lot of hard work!

There is slight mistake in what @PWaddict wrote - you still need to access that "first" image in the array I would also advise using more meaningful variable names, eg use $repeater_item rather than $image in the loop, because it's not actually the image that you are getting, but rather the repeater item that has title, body, and image field in it. foreach($page->your_repeater_field as $repeater_item) { echo "<img src='$repeater_item->your_image_field->first->url'>"; } The other option is this if you want to output all images from your image field. foreach($page->your_repeater_field as $repeater_item) { foreach($repeater_item->your_image_field as $image) { echo "<img src='$image->url'>"; } }

Good Day, Can you please provide more information regarding how you setup this ProcessWire instance, to include version numbers (PHP, ProcessWire)?. It would be extremely helpful if you could list any custom code or third party process modules that you may have installed. In addition, if you could be descriptive about what you are actually trying to achieve, others on this Forum would then be able to adequately assist you. Thanks

Sorry forl late response. Exactly what I needed, working great Thank you very much Didn't know about "shuffle" R

Sorry for my mistake. I'm sure with your example op will understand much better how to do it.

I have had random failures on an old shared host that I no longer use. I never got around to debugging, but I wondering if it's a curl issue. I'd be curious if you have better luck disabling curl here: https://github.com/processwire/processwire/blob/57b297fd1d828961b20ef29782012f75957d6886/wire/core/WireHttp.php#L639 Just remove 'curl' from the $allowMethods array. It should resort to fopen and socket consecutively if curl fails completely, but maybe there is some curl setting on that host that is randomly problematic with Github. Not sure, but maybe worth a try.

@tpr's awesome Admin On Steroids (http://modules.processwire.com/modules/admin-on-steroids/)

For a little more info on what I found which will hopefully help others: There were lots of JS errors in the browser developer tools Console tab like this: Uncaught SyntaxError: Unexpected token < which is a good indication that there is an error message, or at least some HTML being returned in the AJAX request which is not expected by the JS script. So then I went to the Network tab of the developer tools and found the script that is uploading images (?id=1&InputfieldFileAjax=1), and checked the response - that is where I found this login form: Also. of course, when I saved the page, it asked me to login again, so that was also a hint. @Roberts R mentioned that he didn't get the console errors - turns out he didn't have "Disable Cache" checked on the Network tab and apparently that made a difference. I always have it checked because Chrome caching drives me crazy but this might be a helpful hint for others.

Docs & Download: rockettpw/seo/markup-sitemap Modules Directory: MarkupSitemap Composer: rockett/sitemap ⚠️ NEW MAINTAINER NEEDED: Sitemap is in need of developer to take over the project. There are a few minor issues with it, but for the most part, most scenarios, it works, and it works well. However, I'm unable to commit to further development, and would appreciate it if someone could take it over. If you're interested, please send me a private message and we can take it from there. MarkupSitemap is essentially an upgrade to MarkupSitemapXML by Pete. It adds multi-language support using the built-in LanguageSupportPageNames. Where multi-language pages are available, they are added to the sitemap by means of an alternate link in that page's <url>. Support for listing images in the sitemap on a page-by-page basis and using a sitemap stylesheet are also added. Example when using the built-in multi-language profile: <url> <loc>http://domain.local/about/</loc> <lastmod>2017-08-27T16:16:32+02:00</lastmod> <xhtml:link rel="alternate" hreflang="en" href="http://domain.local/en/about/"/> <xhtml:link rel="alternate" hreflang="de" href="http://domain.local/de/uber/"/> <xhtml:link rel="alternate" hreflang="fi" href="http://domain.local/fi/tietoja/"/> </url> It also uses a locally maintained fork of a sitemap package by Matthew Davies that assists in automating the process. The doesn't use the same sitemap_ignore field available in MarkupSitemapXML. Rather, it renders sitemap options fields in a Page's Settings tab. One of the fields is for excluding a Page from the sitemap, and another is for excluding its children. You can assign which templates get these config fields in the module's configuration (much like you would with MarkupSEO). Note that the two exclusion options are mutually exclusive at this point as there may be cases where you don't want to show a parent page, but only its children. Whilst unorthodox, I'm leaving the flexibility there. (The home page cannot be excluded from the sitemap, so the applicable exclusion fields won't be available there.) As of December 2017, you can also exclude templates from sitemap access altogether, whilst retaining their settings if previously configured. Sitemap also allows you to include images for each page at the template level, and you can disable image output at the page level. The module allows you to set the priority on a per-page basis (it's optional and will not be included if not set). Lastly, a stylesheet option has also been added. You can use the default one (enabled by default), or set your own. Note that if the module is uninstalled, any saved data on a per-page basis is removed. The same thing happens for a specific page when it is deleted after having been trashed.

You could check existing users with the role anzeigen-anbieter, get the highest customer_number, and add 1 for your new customer. $pages->find('template=user,sort=-id,limit=1,roles=anzeigen-anbieter');

Makes sense, I don't need to overcomplicate things for myself. I went back and created a new image field called "myphoto" and it works. I won't use multiple named image fields unless necessary, but at least now I understand how it works!

Yes you can, but generally there is no need to have more than one unless they are on the same template. You can use template context overrides - click on a field name in the template view (showing all fields) and set the label and other details there and these will only be for that template.

The label is what the user sees when they are editing the page in the admin, so it's very useful. You can rename the field from "images" to "myphoto", but you need to change the name of the field, not the label.

Your images field name is images not myphoto. That's the problem.

Your field name is "images" - it's the label that you've set to "myphoto". Just replace the call to "myphoto" with "images" and you should be fine!

Maybe you're accidentally hiding the image with CSS?

Yeah, those should all work just fine. If they're not, then something must be odd with your settings somewhere. Is this online somewhere I could take a look?

In a website I'm building where I have CroppableImage3 field (Maximum files allowed = 1 and Formatted value = Automatic) inside a repeater here is how I'm displaying the image (thumbnail). <?php foreach($page->team_members_repeater as $team_member) { $photo = $team_member->team_member_photo->getCrop("thumbnail"); ?> <img width="<?= $photo->width ?>" height="<?= $photo->height ?>" src="<?= $photo->url . "?v=" . $photo->mtime ?>" alt="<?= $team_member->team_member_name ?>"> <?php } ?>

Hey there! I'm using the latest Processwire (3.0.62) I think I fixed it. I disabled Link Abstraction, this fixed it for me. Thank you anyway!

Do you have an admin.php in you site/templates folder?

@Macrura Page output formatting? $page->of(false); var_dump($page->color); // string(8) "ff5a01fd" $page->of(true); var_dump($page->color); // string(7) "#5a01fd"

I don't see how this could be tweaked by aos easily, I would wait for the image handling updates that are on the roadmap instead. https://processwire.com/about/roadmap/

@ryanC Here is how you can do that: <?php foreach($page->your_repeater_field as $image) { echo "<img src='$image->your_image_field->url'>"; } ?>

Thanks @adrian for solving this atm. Issue related to : Installing "SessionHandlerDB" module solves it.

I think @tpr could improve it with AOS in about half an hour

Storing user data in a session is a good way, but if the question in collecting as much user data as possible I would save every answer on each step. In that way, I will have answers from not finished quizzes/surveys.

Just updated the module to version 0.1. Almost everything in it has changed so reading the docs is a must The module does less "magic" as before, eg. doesn't add the "lazyload" class and data-sizes automatically. These should be added manually or you can write a wrapper function if you would like to simplify things (please notify me if you think you wrote one that should be part of the module). Also all the module settings are gone except the "Load scripts" checkbox because all other settings became useless after the rewrite. The new syntax looks like this (here with a helper to add a noscript tag for no-js fallback): <?php $img = $page->featured_image; ?> <img data-srcset="<?php echo $img->srcset('200x300,*2,*3'); ?>" class="lazyload" data-sizes="auto" alt="" /> <noscript> <img src="<?php echo $img->srcsetUrls[0]; ?>" /> </noscript> The main change is that you can easily tell what image sizes (sets) you need ("200x300,*2,*3" in the above example). Of course you can use WxH values for each set or use divisors too. What's more you don't have to start with the lowest image size, eg. "1200x900, /2, /4" is perfectly fine.

When I've needed to implement a multi-page process, I've stored the user's responses in the session, using the built-in ProcessWire Session handling code. If anything needs to be permanent at the end of the process, only then would I create the necessary pages.

Storing form/quiz/survey data in PW pages is great idea. I would even use the fields from the template that stores the data as the way to build the form that users will access on the frontend. After each question has been answered, add that answer to the appropriate field on the page and then reload with the next field/question. Obviously you could delete the page when you get to the end of the process, but honestly I would keep them - why not keep the data - you never know when you might find it useful As far as naming pages, I would go with the ID of the new page as the name and title.

Ah, of course. Url segments is something that can't be supported because of how they're created... No easy way to keep track of them.

One of the most obvious uses of this is I can finally make my own bunch of SEO fields and apply them to multiple pages. SEO is a core part of every site I develop and MarkupSEO just isn't getting the development it requires.

Hi @tpr, I will look into this and add a solution that will work properly together with markup-srcset, (and other cases). Thanks for the clarification.

I think it's a different thing what @dreerr is talking about. Consider this scenario: Set a crop setting on an Image field, eg. "work-thumb, 320, 270" Use it with a srcset solution (either with a module or manually) and that will make you a 320x270 image and some variations - let's assume only one, 160x135: image.-work-thumb.jpg image.-work-thumb.160x135.jpg Now edit the image again and crop a different part. The results: image.-work-thumb.jpg <- changes according to the new crop image.-work-thumb.160x135.jpg <- no change! I'm also interested in a solution because CI3 can't be used for srcset purposes atm if I get it right. What I could imagine as a simple fix is that when CI3 saves a new crop it would delete any size variation of it (in this example all images that are named "image.-work-thumb.WIDTHxHEIGHT.jpg"). Then the srcset generators could re-create these size variations again. Perhaps this behavior could be optionally set in the module's settings.

I recently needed a module that automatically fills the title field of a page using fields on that page. I couldn't see one that already existed so I made my own. This is mostly based on ProcessSetupPageName by @kixe which I use along with this module. Keep in mind I am very new to ProcessWire so perhaps somebody else can contribute or make a better one Note: The title is automatically hidden when using this module You can enter any string. To add a fieldname, subfield or property, you surround the fieldname with {}. Dot syntax allowed. Example: Fish: {parent.title} {myfield} https://github.com/nextgensparx/AutoPageTitles

It looks to me like they should both work just fine. Just one thing to mention though. You could simplify the whole thing to: if($wire->users->count("email=$em") === 0) { $validMail = 1; } else { $validMail = 0; } or in my mind, even better: $validEmail = $wire->users->count("email=$em") === 0 ? true : false; Of course you could do the 1 : 0, but I think true : false is more appropriate because then later on you can do: if($validEmail) { Note in both cases I am also using 'users' instead of 'pages' which is more descriptive in this case. Also, using the PW count() method is much more efficient as it doesn't actually grab all the data, it just counts matches. You can even take it one step further if you only need to check if it's a valid email just one time: if($wire->users->count("email=$em") === 0) { //email is valid so do whatever here - maybe this is where you add them like: $u = new User() // etc etc }

Hi valan, I've found a solution. The translations of the labels (not default) are stored in the 'data' field in the 'fields' table, as JSON. Example: {"label1012":"Weight"} where 1012 is the ID of the language. You can try this code: $label = 'label'; if ($user->language->name != 'default') { $label = "label{$user->language}"; } // Output label in correct language echo $user->fields->get('field')->$label;