Leaderboard

You assign the fields where they need to be stored. For example: Save every field which should be connected to the user to the user template (for instance: an address field, since every user will have their own address) Go to Setup > Templates ... Filters > Show system templates. When you need to add logic to a role 99% of the time it makes sense to use permissions. For instance create permissions so show specific parts of the layout like a comment box for a specific type of user. I have seen rare edge cases where it would make sense to add other fields to a role. See permissions and user. Role are used to store permissions, but since they are pages you can assign any field which makes sense. See point 2 ProcessProfile is where the superuser defines which fields the user is allowed to change on their profile page (/processwire/profile/). ProcessUser is the process module for the users page (/processwire/access/users/).

Turns out it's not difficult to do this using the core ImageSizer. Here's a function showing the basics - could be turned into a module, enhanced with some error checking, etc. /** * Resize Pageimage using custom name/path * * @param Pageimage $pageimage * @param int $width * @param int $height * @param array $options * * @return string * */ function resizeImage($pageimage, $width = 0, $height = 0, $options = array()) { $filename = $pageimage->filename(); $basename = $pageimage->basename(); $path = rtrim($filename, $basename); $dirname = $width . 'x' . $height; $variation_name = $path . $dirname . '/' . $basename; $variation_url = rtrim($pageimage->url(), $basename) . $dirname . '/' . $basename; $force_new = isset($options['forceNew']) ? $options['forceNew'] : false; if(!file_exists($variation_name) || $force_new) { wire('files')->mkdir($path . $dirname . '/'); copy($filename, $variation_name); $sizer = new ImageSizer($variation_name); $sizer->setOptions($options); $sizer->resize($width, $height); wire('files')->chmod($variation_name); } return $variation_url; } // example $image = $page->images->first(); $src = resizeImage($image, 500, 300); echo "<img src='$src'>";

This one?

I have turned it into a Page method: /* Returns the complete URL of a Page. * * @param int arguments[0] Pass false to exclude the pageNum of the Paginator * @return string */ $wire->addHookMethod('Page::siteCompleteUrl', function($event) { $withPageNum = isset($event->arguments[0]) ? $event->arguments[0] : true; $full_url = page()->url; if (input()->urlSegmentsStr) { $full_url .= input()->urlSegmentsStr; } if ($withPageNum && input()->pageNum > 1) { $full_url .= "/" . config()->pageNumUrlPrefix . input()->pageNum; } $event->return = $full_url; }); Small changes were applied to it: "/" is added in the second "if" to avoid double slashes on the pages of the paginator first argument can be used to exclude the page number of the paginator, defaults to true

Just to let you know: I did a few more tests with and without "Use ACF" and it seems to work just fine! All happened on PW 3.0.62

On the subject: https://blog.toggl.com/how-does-music-affect-work-infographic/

A Page Reference field will work great for your "Homepage Listung" field. It's no problem to set a Page Reference field using data from a CSV import. You don't say how you are importing the CSV data, but let's say you are using the ImportPagesCSV module. The module readme says... Probably the easiest way in your case is to use the title of the page. So a basic outline of what's involved... The template for the pages in your Page Reference field should contain the "Title" field and a "Label" text field. Create the pages for the Page Reference field - one for each option that might occur in your CSV data. For the page Title use the value that appears in the CSV data. For the page Label use the label that belongs to that value. Example... Title: "NE2", Label: "n. Endkundenrelevant" Create the Page Reference field and add it to the template used for the pages you will be importing. Specify the pages you just created as the "Selectable pages". For the "Label field" setting, choose "label". Import your CSV data using the ImportPagesCSV module. Done.

@szabesz, I think this is covered by $input->url() and $input->httpUrl() now, which were introduced since I wrote my post above. There's a blog post about it somewhere but I can't find it at the moment.

We're developing the site for a Swiss architect, and meanwhile we prepared a very simple temporary page: http://gamisch.ch/ It's powered by PW, so I thought I should post anyway

Well I don't see anything wrong.... But it is your default description indeed [MarkupSEO isn't picking up body/description field?]. Personally I'm not using MarkupSEO, I have everything in my _init.php configured and, so far at least, it is working.... It's a pretty old website, still running pw 2.7.1/2..... Haven't tried it on pw 3.x yet, but I guess this has nothing to with pw... I had a strange experience once where FB wasn't picking up any opengraph whatsoever, and I actually had to create a facebook app id for that site, but so far I've encountered it only once.... that was very weird too.... Sorry I can't be more informative....

That is weird! You have a link I can check out....?

If possible, What domain where you sending from and to what domain where you sending to in your test emails? Are these accounts/SMTP Service associated with Your Hosting Provider, Gmail, Microsoft or any other third-party email provider?

It works for me... Did you have opengraph in your header? Check your page here.....

Also there is this:

The class names are defined in the config for the Page Edit Image module (ProcessPageEditImageSelect).

Hi Robin, wow, it worked. I'm so happy . And that's a really easy and elegant solution . Really great. Thank you so much I think, I have to rebuild my structure now...

@szabesz @SamC Thanks to both of you. I did what you were suggesting, but my menu was still not there. Only then I realised 'Styles' did not appear in CK Editor toolbar section. I know I had it in PW 2.* but this is probably default on 3 series. I am still looking for solution on editing 'pwimage' plugin's styles.

@onjegolders ye, that's a far superior way of working with uploaded assets. I still need to take a look at S3 integration with ProcessWire, but that would alleviate a lot of headaches.

Thanks @larrybotha, having spent a fair amount of time with Craft, I think this is one area where having files tied to pages makes things more difficult. With Craft it is possible to have you assets exclusively in say an S3 bucket, so your assets will always stay the same and accessible across environments/users mys3bucket.com/images/featured/featured1.jpg etc If I ever need to create a new site to access those images or a new dev needs to set up, they can just get started straight away.

One thing that stole me some time to find out is when you create pages via the API you need to take care that all languages are active on your own as they are inactive by default One little hook does that trick though:

@onjegolders ye that's a bit of a pain. At Fixate we generally use placeholders until real content is added. Once real content is added, if someone needs the content for anything specific (usually the devs don't need all assets to work on the site) we'll Slack each other the assets. Once a site is on a staging environment it gets easier to manage, as final content is usually added there. We use rsync to sync remote assets to local folders, and sync site files to the remote using Gulp: https://github.com/fixate/generator-fixate-pw/blob/master/app/templates/gulp/tasks/rsync.js I'd be interested to hear how others handle it, but yup - don't commit assets or generated files (*.css, *.js, minified images, etc) to your repo - your repo should contain only dev and working files; a build process should be responsible for generating production files. Clean repos, and clean commit histories

There are some links and also some code for creating repeaters and adding fields to it here: Shouldn't be anything special about doing it from a module. HTH.

Hey @onjegolders - I just tested @mr-fan's version of this script (which makes it a configurable module) and it works fine for me in PW3. The new page are created as direct children of the page where the bulk images are uploaded. The only thing I noticed that seemed a little weird is that if no description for an image was entered, the child page title used the name of the image directly including the file extension. I have created a PR which improves this: https://github.com/mr-fan/AutoImagePages/pull/1 Until that is accepted, please check out my fork: https://github.com/adrianbj/AutoImagePages

Yes, it is. Go to the Input tab on the field settings and add a value to "Columns of Checkboxes". I forgot to say that the options are going to be divided automatically, you cannot control the column order like you mentioned.

So maybe it is me who has not spent too much time on it? I see what you mean now. Yep, I guess the label did change but Page == Page Reference, so the latter is more appropriate.

Hi @Klenkes - I decided to go with #2 - now BCE will only apply the "purify" sanitizer if the field that is being populated/updated has the HTMLPurifier enabled. Could you please test at your end to make sure it works as expected? Thanks!

Hi @HarryPhone, If I understand right, what you are doing looks more complicated than it needs to be. If you just need values/titles in a select inputfield and your site editors don't need to edit these options then you can define the values/titles in an Options field: https://processwire.com/api/modules/select-options-fieldtype/#separate-option-values If your site editors do need to edit or add new options then you can use a Page Reference field. In the template for the pages you would use the Title field for the option title and add a text field for the option value.

Hello @madknight and welcome to the ProcessWire Forums, Have you already seen this? https://processwire.com/docs/tutorials/ especially: Installing a CSS Framework How to structure your template files also, in the newest versions of ProcessWire we have Markup Regions: https://processwire.com/blog/posts/processwire-3.0.62-and-more-on-markup-regions/ and Field Rendering: https://processwire.com/blog/posts/processwire-3.0.7-expands-field-rendering-page-path-history-and-more/ I use the above two to better structure my template files. In my setup Markup Regions is used for various page layouts where I can also dinamically add additional script and css files to a given page when needed (e.g. only the home page needs a slider JS and its CSS, etc...) I use filed rendering to render the "Main Content div" and also some fields when appropriate. I also use include when rendering fields is not possible (there are no such fields...), eg.: include __DIR__ . '/../../partials/article-lead-home.php' But there are various ways to do it. Some use templating engines for example, such us Twig, Latte, etc... You can find modules which support working with them more easily. In ProcessWire first you need to figure out your own way of setting site profiles up. It takes time, but it is worth it because you can build your "frontend theme" – which we call Site Profiles BTW – the way you want. Hope this helps. Also you can seach the forum for more ideas. Just use Google like this or similar.

@sanstraces - depending on your actual needs, this might also be an option:

@PWaddict I'm not really sure why you would bind your translations to the page object. What if you want to use those in a context, where there's no $page variable present? Wouldn't it be better to just create a new WireData object (like $static_translations) and return that.

Yes if you expect the user to translate it by him/herself. But if it's your job, just wrap the string in code and translate it in the language settings page, loading the PHP file there. Although, I've found the use of a single file to handle all strings, like a _translations.php much easier. I just include it within my _init.php. I have one here with 225 phrases and counting.

Hi @Peter Knight 1. You can use MarkupSEO, just change type of needed field to multilanguage text/textarea ( seo_title, seo_description etc.) 2. I think yes. Can't remember if I had some issues. 3. All of my sites are multilingual and I never had a need to use a separate tree for every language. You can switch off multilanguage support on template level (Advanced tab) and there is module that lets you control whether multi-language support is enabled at the page / branch level. 4. Yes. You should read about hreflang. Also, there is "What should happen when this field's value is blank?" option in field settings. Usually, I don't inherit values from default language, because in that way I can get duplicated content ( not good for SEO ). Image and files fields are multilingual through language-alternate values

@ngrmm It's never a good idea to override somehing in the core or in a third-party module because if you update it your changes are overritten again. I updated the module and added an option in module settings to set the limit. @Tacolombardi <?php $events = $modules->get('FacebookEvents')->getEvents(); ?> <ul> <?php foreach ($events as $event): ?> <li> <?=$event['name']?> <img src="<?=$event['cover']['source']?>" alt="<?=$event['name']?>" /> </li> <?php endforeach; ?> </ul>

Or use my migrations module, to kinda get the best of both worlds. The ease of the ProcessWire API with the ability to have migrations run/downgraded as needed.

I'm using almost the same setup, but my "t" function handles context too. The good thing is that _strings.php can be copied to your next projects too. function t($text, $context = 'General', $textdomain = '/site/templates/_strings.php') { return _x($text, $context, $textdomain); } _strings.php: // Search _x('Search site', 'Search'); _x('No matches', 'Search'); // Forms _x('From', 'Forms'); _x('From email', 'Forms'); _x('To', 'Forms'); ...

I use a similar solution to a _strings.php file, and include it from my _init.php file (prependTemplateFile), so that it's available to all templates. But I bundle all the translated values into a new function (which I'll call _t(), but you could name it whatever you want). So you can call upon that _t() function anywhere that you'd call a __() function. For instance, in your /site/templates/_strings.php file... function _t($label) { static $labels = null; if($labels === null) $labels = array( 'Yes' => __('Yes'), 'No' => __('No'), 'Maybe' => __('Maybe'), 'And so on...' => __('And so on...') ); return isset($labels[$label]) ? $labels[$label] : $label; } From there, you can replace any __('label') call with _t('label'). In this manner, you only need to translate your _strings.php file, and all the other template files can use the translated labels. For the cases where you need to translate text that only exists in a particular file, then you'd continue to use the __() function as usual.

You may want to take a look at Philipp Reiner's "First Steps" video that goes through the process of working with a HTML template for use with PW. The main part for the HTML template stuff starts around the 14:44 period. I would suggest you look at the entire video and other PW related video content on the ProcessWire website.

Absolutely! Here is a simple, but functional example for both login and logout templates. You would want to replace the markup with your own markup or includes. Likewise you'd want to change the redirects to redirect to whatever page you want them to go to after completing a login. /site/templates/login.php: <?php if($user->isLoggedin()) { // user is already logged in, so they don't need to be here $session->redirect("/somewhere/"); } // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect("/somewhere/"); } } ?> <html> <head> <title>Login</title> </head> <body> <form action='./' method='post'> <?php if($input->post->user) echo "<h2 class='error'>Login failed</h2>"; ?> <p><label>User <input type='text' name='user' /></label></p> <p><label>Password <input type='password' name='pass' /></label></p> <p><input type='submit' name='submit' value='Login' /></p> </form> </body> </html> /site/templates/logout.php: <?php $session->logout(); ?> <html> <head> <title>Logout</title> </head> <body> <h1>You have logged out</h1> </body> </html>