lenoir

Actually… I was. Doh. Can't believe I oversaw that. ? Thanks a lot

It behaves correctly if I leave the field "range" empty… But as soon as I enter some value such as "-30:+20" (as in the example), it starts counting at the current year…

Hi, I've setup a date field with a date picker. I set it with a range of "-10:+10" for the years, but for some obscure reason (to me), instead of showing years from 2009 to 2029, it shows the coming 20 years (2019 - 2039). Am I missing a preference somewhere?

Of course, that's the one I'm using currently. Nice functionalities but limited in terms of design. And again, it feels old… (i know i know, it's not. But still…) ?

I'd like to add my voice to this topic. I was just browsing through the modules under "admin themes", sorted them by date and oh… the latest one is 4 years old… And almost all of them stopped with version 2. As much as I like this CMS, I'm having more and more of a hard time convincing clients to use it, and I think it has a lot to do with the looks. It feels old and somehow odd… i just came across the module "admin theme boss" by @Noel Boss and what a relief! Finally something I can present to my clients without shaking. ? I'm really hoping for improvements in this field, since I'm a true believer in the love at first sight, or at least how important first impressions are.

It's an old post but still a hot topic… I create a lot of websites for clients in german, sometimes in french. I often end up with a mix of languages either in the fields or templates names… Anybody working with multilanguage sites with a good practice suggestion?

Hi, On GitHub it's posted as solved, although I still get that problem with integer fields on Form Builder. Anybody still having that problem?

I had the same issue and this seemed to fix it. What is this function?

You nailed it. It's an old site (one of my first ever with pw), and I wasn't rendering the URLs correctly. It works now. Thanks a lot for your help, wbnjfktr (whatever that means). ?

Yes, I did. "en" and "de". But the names of the languages (under "languages") are "default" and "deutsch". But as far as I know, they don't have to (can't) be the same?

Hi, I've just setup a website to multiple languages, and I have to say, it's very straight forward and quickly done! But still I'm not sure I understand the process correctly. I have the module "Languages Support - Page Names" installed. I can view all pages either in DE or EN, and I'm using this piece of code as a language switcher (from the introduction page): // remember what language is set to $savedLanguage = $user->language; foreach($languages as $language) { // if user is already viewing the page in this language, skip it if($language->id == $savedLanguage->id) continue; // if this page isn't viewable (active) for the language, skip it if(!$page->viewable($language)) continue; // set the user's language, so that the $page->url and any other // fields we access from it will be reflective of the $language $user->language = $language; // output a link to this page in the other language echo "<li><a href='$page->url'>$language->title: $page->title</a></li>"; } // restore the original language setting $user->language = $savedLanguage; It works for the current page, but as soon as i click on any link, the language switches back to default (in my case german). My question is, do I need to update all URLs in the template files? I thought that the language switcher updated the language in the session and kept it this way… Could you give me light? Thanks

Yes, I'm aware of that. That's my issue. That's what I get with sharpening set on SOFT. Are the core rendering engines just not that good?

HI, Has anyone encountered quality issues with the croppable module? I know I'm very picky when it comes to image quality, but I'm getting pretty bad results and I'm wondering what i can do about it. I've tried no sharpening, sharpening soft, quality 90 and 80, but the images still look "pixelated", specially in the diagonals. See screenshot attached. Original left, cropping on the right.

Ok ok ok… You got me curious, I'll try out your module ;-) I was reluctant to use it since I only need the first page of each PDF, but the PDFs I'm dealing with have 1-5 pages, so it's not likely going to take too much storage space. Will it work if placed in a repeater?

A year and a half later, Soma saves my day. Again. And for the very same issue

Hi Richard, I've tried out this module on version 2.6 and it works nicely! I've tried installing it in version 3.0 and had to restore the database from backup: I got error messages and couldn't reach the PDF-field anymore. The information about compatibility is misleading: on the module page it says compatible with version 3.0, but later on it's stated <3.0. Too bad I can't used it now, I liked it a lot! Thanks.

Yep. Just what i was dreading: I installed the module and it's not compatible with version 3.0. Now I can't delete the field that cause the issue, and I can't get rid of the module since it's used by a field… PS: I could restore from backup. I'll inform the compatibility issue in the right forum.

I haven't tested the module yet. True, I missed the compatibility part. It says somewhere below: Requirements: Processwire >=2.5 <3.0 That's what threw me off. I guess the text isn't quite up to date… I'll give it a try now. Thanks for your help.

I could run two fields (PDF & JPEG) in a repeater, that might do the job. It's only a matter of compatibility with the latest PW version.

Thanks Adrian. Yes, I looked into the module "Filetype-pdf", but there are two issues for me. First, it's not supported in the current Processwire version (>3.0). Second, my field has both Jpegs and PDFs, and this module only accepts PDFs into the field. That's why i was looking for a simple code to do the job.

Hi, I can't get this script to work. I'm simply trying to generate the first page of a PDF from a file fieldtype. I keep getting an error message like this: "Error: Exception: Unable to read the file: …". The path to the PDF seems correct to me. foreach($page->datei as $publikation){ if($publikation->ext === "pdf"){ $file = $publikation->url; $im = new Imagick(); $im->setResolution(300, 300); $im->readImage($file . '[0]'); $im->setImageFormat('jpg'); header('Content-Type: image/jpeg'); echo $im; } } Any idea what I'm doing wrong here? Thanks!

Thanks Adrian! I don't know if you've solved Thomas' problem, but you hinted on mine ;-) Stupid mistake…

I tested even without the repeater and I get similar errors. So I think we can leave the repeaters out of it. Permissions are OK. I tried to recreate the issue (can't tell yet exactly when it works and when not). I created 4 cropping-presets. These create the 4 croppings automatically. So far ok. When the user (whichever) creates a custom cropping, the new cropping doesn't overwrite the old one. Or I should rather say, sometimes it does, but most of the times it doesn't. Workaround is to delete the generated croppings in the "variations" window prior to creating a custom one. This works, but it's not a nice solution for the end user. Am I the first one reporting this bug? Thanks.

Hi Horst, I've wrapped a repeater around my image and bullet selection (The user can thus choose which cropping to use). It works when I upload an image for the first time, it creates 4 standard croppings (panorama, portrait, etc.). However, if I make a custom cropping it doesn't save it. I'd actually want the custom cropping to overwrite other files, but that doesn't work either. Is there a known issue between croppable image 3 and repeaters? Should i use ProFields Repeater Matrix (haven't tried it so far). Pagetable is also a possibility, but not as intuitive and fast as a repeater. Thanks for your help! David

I was also thinking about a repeater. Pagetable would also make sense I guess. Thanks Horst! I thought there might be a secret weapon I didn't know of