heldercervantes

Awesome! I've just read it (translated by the browser) and you make solid points. Most of these benefits I've experienced first-hand.

https://camel.com.do http://ccalfandegaporto.com/en/

There's no limit. You don't even choose languages from a list, so you can add Martian if you want to. You can also translate the CMS itself for that truly immersive Martian experience.

This is an awesome subject. I've wondered about this, honestly never needed it and don't expect to anytime soon, but it's probable to come up down the road.

From 2000 to 2015 I had a company that ran its own servers, and I can tell you that either you put yourself in the middle with clients that buy premium service and pay hundreds per month, or its just not worth the hassle. Our tech guy spent his days resetting email passwords and telling clients to check if their wifi was on. If you're taking a 5€ profit, one call is enough to burn it. For me the best deal is to talk to the hosting provider, show them how much business you're bringing them, and use that to negotiate free hosting for yourself.

Damn that hurts. Like Robin says, check your colour profile on the original image. Also, I've been handed JPEGS in CMYK instead of RGB, and 24 bit instead of 16. These are weird, I haven't seen many, but Trump got elected, Brexit won and the far-right is gaining ground in Europe so... You can also try using ImageMagick for your image processing needs instead of the default GD: https://modules.processwire.com/modules/image-sizer-engine-imagick-cli/ By the way... $featured_image->size(854,0)->url is the same as $featured_image->width(854)->url

Until you login, you're an anonymous visitor like every other guy who accesses the site. So if you hide the admin access, how would PW know it was you? Don't worry. Set up a safe password and you'll be fine. If you really want an extra layer of security, change the admin path to something not obvious like dragan suggested. Anything more isn't worth it. The admin path isn't listed anywhere, and is not indexed by search engines (nothing tells them where it is), so the only way to guess it is just that, to guess it. It's extremely unlikely someone would try that unless you're making a site for the government or a huge brand like coca-cola. Also worth mentioning is that if you fail a login 3x, the admin will make you wait 5 seconds before the next attempt. Fail again and it's 10, again and it's 15... Brute-forcing with that protection would take forever. I've mentioned this in various posts in the past about security. I've NEVER heard of a single PW site being hacked.

WOW, just today I was thinking of writing an article about clients protecting themselves from agency death. Out of principle, I do the setup but make my clients buy the hosting themselves, give them all pre-compiled code (SCSS, original JS...) and give him the original files for the layout. If I had 1€ for each time a client came to me with and discovered to be in a dead-end with their current site I'd... well almost be able to have a coffee at Starbucks. Almost.

Awesome!

I've been doing functions from the start, but more recently I've had a couple of instances where I go for a custom module. I can't really speak in terms of performance, haven't made any tests, but the module approach feels better when there's more than one or two functions, to organise everything more neatly. Example: I'm working on an online store built from scratch. In that project the server shoots emails all the time. On register, on purchase, on order status changes, etc. Each email has a template that can be edited in the CMS. It becomes complex having to handle multiple templates and usage scenarios, replacing variables, different results based on context, so turning it into a module made it much more organised. I guess for me it's about volume and reusability. If it's small stuff I don't bother.

What you're attempting seems too specific. It may be possible to hack the module to use a textLanguage field for tags instead of the simple text one, but that's a bad idea. You'll lose the ability to update the module, and may screw up the API. I'd find another way around it, perhaps using a repeater to hold everything together. I can suggest 2 different approaches: 1. Alternative images field for the second language If you have a field called "images", and another called "images_de", while having a second language with the name "de", the API will automatically use "images_de" if that's the user's language. This will automatically filter all your content. Downside: You'll have to upload images twice. Not good if you want all images to appear on both languages, but then again I have come across the need to have images that appear on one language but not the other so... 2. Use a repeater to hold everything together Set up a repeater, have a field for the image, and a textLanguage for the tags. Downside: You'll have to code your own tags logic for whatever you're building in the frontend, and you'll have to upload images one by one. You do make a good point. If the images field with language support gets different fields for description, I'd say the same should happen to tags as well. Maybe you should add this to the wishlist section of the forum.

I've been mostly a designer too. Up until the end of 2015 I was creative director and my coding days were more than 10 years behind me. I wouldn't suggest anything else. It's super flexible and the API is so straightforward that you'll need little more than to learn how to use a foreach loop in PHP to get on with it. You also have a great community willing to help in this forum, something that frankly I haven't seen anywhere else, coding related or not.

Thanks for the correction @Robin S, have to admit I spoke off the top of my head on that one.

Someone more knowledgeable than me may clarify the why, but it seems you need to combine start with limit. This is for pagination purposes, and it makes sense in that context. I guess it "could" assume an infinite limit by default, but as I said someone more knowledgeable may point out a good reason why it shouldn't. So just put a limit of whatever large number you feel comfortable and it should work. This code works for me: $pl = $pages->find('template=basic-page, start=3, limit=3'); Also, you don't need to set `sort=sort`, that's the default behaviour (see correction below). However if these pages you're grabbing are not children of the same page, you'll have a whole new problem to deal with.

Hey Ben. The last site I built used that version of PW and I find no problem whatsoever running on Chrome in Windows 10. Are you and your client logging in with the same user? I forget to add permissions to the client's user all the time.

Ah New Zealand... I want to visit so bad.

Learning new is something that I do as I work on projects. On my down time I usually work on personal projects. Rethinking my personal site, looking for new opportunities... heck, the other day I found myself creating a text editor web-app, as if there weren't enough of those already, just for the fun of it. The idea is to keep challenging myself, so more and better things can come up in the future.

It certainly does. This was my second one. I literally took the resources folder, view-sourced (just made that a verb) the old site, cleaned up the HTML and added fields to fill it in. More could have been made to improve the HTML and there's a lot in the frontend that I'd have done differently, but we wouldn't want this migration to cost as much as a completely new site

Looks like I missed something moving to production. Thanks for the heads up.

I'll need some time for that. Let me see what I can do.

The idea is quite simple: You set up a repeater field with all the fields you'll need for each type of block. Title, body, images, single image... etc. You add another options field (I called it "type") and populate that with the names of the block types you'll need. For each other field (body, images...) you set up its visibility to show only when type is relevant. The result should be a repeater, when you add a block the only field that shows up will be a drop-down for type, and when you choose that, the relevant fields appear. Setting up a field's visibility: Adding a block before choosing type (ignore the other two fields, that's for something else): And after choosing type... From the template, I'm just doing a foreach that goes through the repeater, then use the type field to decide what "sub-template" file to include. That keeps things neat and separated. This can also be done with a RepeaterMatrix ProField, which simplifies this whole process. On a more recent project I'm currently working on I'm using that combined with field templates to achieve more or less the same effect.

@Sérgio Jardim and I are gonna be there and decided a beer is in order. If you're going to be there, let's hang out.

The title says it all, let's hang out

I'm going too. Probably not the whole thing, I'm still looking at the program. I'm following you on twitter so we can contact at the time.

Hello team PW! Here's another one, for the best Congress Centre in the world, in the most beautiful city in the world! http://www.ccalfandegaporto.com/en/ This site was initially developed in 2015 using a proprietary CMS from the previous agency. In late 2016 some changes were requested, new languages and a few tweaks, and I took the oportunity to migrate it in PW. Most of the frontend was kept, save for a smaller improvement here and there. As you'd probably guess, having used the proprietary CMS and jumping to PW, the client was blown away by the new admin area. Note that content translations are a work in progress.