Leaderboard

A proof-of-concept module. ImageToMarkdown Alt+click an image in Page Edit to copy an image markdown string to clipboard. Usage Install the ImageToMarkdown module. Alt+click an image in Page Edit to copy an image markdown string to clipboard. If the "Description" field is populated it is used as the alt text. https://github.com/Toutouwai/ImageToMarkdown

Hello, A friend posted a question about how obtain the markdown code for a image when you are using the markdown editor. Here I created a module just for that. You can download it here. https://github.com/NinjasCL/InputfieldImageMarkdownCodeAdditionalFields cheers.

This little tipp is not especially for PW, its for all usages. There is a little class called php-store-hours which can be used to easily format opening hours. It is also possible to group days with the same hours like in schema.org markup. There are a lot of render functions available to get the markup that you want. Just take a look. Maybe it is something you are looking for. Best regards Jürgen

I am sure there are idiosyncrasies with certain hosting environments, but I have not run across anything outside what the general upgrade instructions dictate. There is also a profile export module with instructions in this thread that I found very helpful.

https://github.com/processwire/processwire#upgrading-processwire I think this is the most complete guide. Upgrading from 2.x to 3.x must be carefully done as you can read. Most of the time, I haven't had troubles with the core, most likely a third party module. I have yet to see ProcessWire break with an update. There's also the upgrade module. which also makes a db backup before upgrading and renames the previous files with a dot at the beginning.

I made a simple proof-of-concept module: ImageToMarkdown

Just skimming this thread quickly but wanted to point to the html5 boilerplate htaccess which has some pretty robust stuff for supressing/forcing www and https. These have always worked for me on a variety of hosts. https://github.com/h5bp/server-configs-apache/blob/master/dist/.htaccess

FacebookEvents ProcessWire module to get Facebook Page Events using the Graph API. Create an app on Facebook developers website You have to create an app to get appId and appSecret. Those keys are required. Go to Facebook Developers and add a new app. Congrats! Now you can copy your Facebook appId and appSecret. Get your Facebook page ID You can either enter your facebook page ID or the facebook page name. If you enter the Facebook page name, this module will get the page ID for you! Call Module $events = $modules->get('FacebookEvents')->getEvents(); Output Events {% for event in events|reverse %} {% if event.start_time|date('U') > date().timestamp %} <div> {% set dts = modules.get('FacebookEvents').getDates(event) %} <a href="https://www.facebook.com/events/{{event.id}}/" title="Facebook">{{dts.dates}}:</a> {{event.name}} <em>{{dts.times}}</em> </div> {% endif %} {% endfor %

Yep, It's super cool that module. You can use both

Thanks for sharing @clsource! Seems to be a popular topic these days. Have you seen this one?

Glad you found the solution, but you are right that it is a little bit confusing. Honestly I have never read the description and always install all languages modules when I am planing to translate a website.

Haha, I made a module also xd. Well the implementation is different but the use case is similar and complementary Good Module Robin

Thank you, you seem to be right! I installed the module and all the others required by it, and the label showed up. However, maybe it is just me who does not understend the description, but it sounds to be the opposite: "Field that stores a page title in multiple languages. Use this only if you want title inputs created for ALL languages on ALL pages. Otherwise create separate languaged-named title fields, i.e. title_fr, title_es, title_fi, etc." So that is why I though installing the module Languages Support is enough in the case of language-alternate fields. I do use AOS, but whenever I have an admin issue, that is the first I turn off temporarily to make sure it is not the culprit.

Sorry, please forget the last post. According to the video this is not necessary. I only used language alternate fields so far in combination with translated pages via PageTitleLanguage. I would recommend you to do the same, but in your case it maybe something else. Are you using AdminOnSteroids? I noticed in your screenshot you have the page pathe displayed under the label.

You have at least to change your PageTitle field into PageTitleLanguage or else you are not able to translate your pages. The PageTitleLanguage is necessary for the title and name translation of your pages.

I mean the labels of the languages under Setup => Languages. Those will be displayed under the field label. I have just tested it quick with PW 3.0.63 and AdminThemeUIkit and its working fine. But the version or AdminTheme should not matter.

Hello @szabesz, have you translated the titles of your two languages in both languages? That is the only reason I could think of. Nevermind, you have at least the title for the default language. So this one should at least be displayed. Regards, Andreas

First solution for the website at ovh (registar and website hoster). Found this again (and that I had bookmarked it already): https://docs.ovh.com/fr/fr/web/hosting/htaccess-reecriture-url-mod-rewrite/ If not wrong, using this RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.domainname.tld/$1 [R=301,L] Then this RewriteCond %{HTTP_HOST} ^domainname.tld$ RewriteRule ^(.*) http://www.domainname.tld/$1 [QSA,L,R=301] I only have a 2 redirect message with PageSpeed Insights - if testing https://domainname.tld If I use this instead RewriteCond %{HTTP_HOST} ^domainname.tld$ RewriteRule ^(.*) https://www.domainname.tld/$1 [QSA,L,R=301] I don't have redirect error messages anymore (4 combinations/variations). I'll (re)check again to see if it was real. And I'll test later if I can easily transform it to use the non-www version. But I'm not sure if I really want the non-www version or not. I'll precise R=301 where there is only R. It's very easy to invert from www to non-www. Apparently no redirect error messages either. So it's ok now for this one website. I would just have to choose between www and non-www. http://www.yes-www.org/ http://www.yes-www.org/why-use-www/ (technical reasons)

You can alway see the headers (and thus your redirects) by using curl -vL http://your.domain/ at the command line (if you have cURL installed). At the same time you can check the server logs (access log) and you will see what site is being accessed.

@szabesz Of course I tried also with this. Too many redirects error message. This doesn't work for me (at least while testing it with one of the websites). For exemple, http://www is not even redirected to http:// I'm not going to spend more time with this now. Later eventually. I'd like a debugger to exist for this. Perhaps using a security/penetration testing framework(?). Thanks everyone.

Great! thank you @tpr, now it works! I hope my case will be useful to you and other developers Have a good day

Im an idiot, turns out I had already figured this out previously somewhere else among the code for the same module! Anyway for anyone wondering I managed to retrieve them with: $fg = wire('fieldgroups')->get('field-group-name');

Hey horst. Really awesome module!! Guess I stumbled upon it once before, but sadly didn't take the time to really check it out. Anyways... just installed it and saw the same warning as ukyo before "Notice: Undefined property: stdClass::$manualSelectionDisabled". Going to settings screen and hit Submit resolved it. I'm on 3.0.62. Keep up the good work!

I just posted a question about moving PW from a resting domain to a production domain, after consideration I figure I would create a new post for a second question I have. I noticed the coming feature of client size image resizing. This will be really helpful, as I have some clients on a Satellite connection. I'm telling you, them trying to upload 15MB images, or them getting them straight on batch resizers (or Photoshop) to resize before upload is a real chore. Needless to say, Ryan has been doing an excellent job addressing this. My question, is that I have several clients on PW 2.x thru 3.x. Is there a really good guide on steps that I need to take to update the core to take advantage of the features of new releases? Are their perils to look out for? Yeah, after developing several sites, I feel a bit silly about asking this one, but, the docs doesn't seem to be clear in a "general" sense of upgrading the core across all versions. Thanks everyone for your time and assistance.

I can certainly vouch for client side image resizing working very well - I was looking for this functionality for an intranet site I'm currently working on and Ryan's implementation is very good indeed. It even works with front end editing, with a bit of experimenting as to which method you use and how much output code you enclose. As far as the upgrade process goes, what the guys have said above pretty much covers it. There aren't any major gotchas other than what has already been mentioned, but you might try backing up one site and running it locally on a dev server just to test the process.

userAuthSalt: " it is forever tied to the passwords as a secondary salt." But if you use the very same database and files normally you should only need to update $config->httpHosts as @Sérgio Jardim pointed it out above.

Have a look at your caches table. Search for name=Module.FacebookEvents. Delete this row. Furthermore you could have a look at your modules table where class=FacebookEvents, column: data.

@rick I'm talking about 2 different websites that have nothing in common. For each website, the 4 variations of the url point to the same (common) content. I normally can't use sites-available/sites-enabled (only on my local computer(s). Ex-Ubuntu and current Linux Mint Mate user). @szabesz I'll use it eventually and see if it works for me. Edit: it doesn't work (at least for the domain I'm currently working on). https://www.domain.tld is redirected to http://domain.tld. @SiNNuT I think I have it bookmarked and perhaps also downloaded it somewhere. Edit 2: now that I want to use the non-www version, I have to find a way to change the code I was using so that it works... So much time wasted for things that should be easier to do. Edit 3: there seems to be a difference, related to shared cookies, between the www and non-www choices. Edit 4: I'll eventually try again later with other domains. It's not worth it now.

If it is a new install, then the user salt (site/config.php) will be different, which affects the passwords.

You don't need to change anything in the database. The only change needed in this case is the httpHosts array: $config->httpHosts = array('testing.com'); in the config.php file.

I'm not an .htaccess guru, but I dug up this one from the forum some time ago (sorry, I dunno where it was posted and by whom): # inserted before the block "# 13. OPTIONAL: Redirect users to the 'www.' version of the site (uncomment to enable)." # ----------------------------------------------------------------------------------------------- # OPTIONAL: Redirect users to the non 'www.' version of the site (uncomment to enable). # For example: http://www.processwire.com/ would be redirected to http://processwire.com/ # ----------------------------------------------------------------------------------------------- RewriteCond %{HTTP_HOST} ^www\. RewriteCond %{HTTPS}s ^on(s)|off RewriteCond http%1://%{HTTP_HOST} ^(https?://)(www\.)?(.+)$ RewriteRule ^ %1%3%{REQUEST_URI} [R=301,L] This is for non www of course, but it works for me on cPanel shared hosting sites. I do not like www, so I never tried the opposite. EDIT: I've found the source:

+1 for anyone who listens to The Shadows! Been listening lately to one of my local bands - Red Moon Joe. They might not sound like it, but they are from my home town in the north of England.

The default minimum length for words in a mySQL fulltext index is 4 letters, and while your hoster might be prepared to reduce that length for you, it would probably be better to change the way your search page works. Assuming you have ftp access, look for /site/templates/search.php. Its contents probably aren't that much different to the basic install search template, based on the way it appears to work and output results. If that is indeed the case, then look for a line like line 24 in the file I linked above. If it is identical, then replace the equivalent line with the following $terms = explode(' ',$q); $selector = ''; foreach($terms as $term){ $selector .= "title|body%=$term, "; } $selector .= "limit=50"; and you should be good to go. (Touch wood.) If it's very similar, you may be able to figure out what to change, but if not, post what code you have and we'll try to help.

Posting in the hope this helps someone out of a hole! Having built 20+ sites on PW in the last couple of years (and loving it...) I came across a really odd situation recently. The client's IT company and I 've been battling for a couple of weeks and today, finally, we have an answer! The site is built and temporarily housed on a shared hosting account we have for development. All tested well here so Access was granted to the client to start adding content. The next day I get a call from the client to say the admin side of the site is logging them out every 30-40 seconds and they have to log back in again each time to continue. I tested again from our office with their login but all worked as expected. Other browsers, PCs etc. were all tried by the client but the problem persisted. So, I get in my car and drive to the client's site. Sure enough, I see the issue on one of their iMacs. So I open up my MBP, connect to their network, log in as them and the problem is there. So, next, I came off of their network and onto my tethered iPhone on 4G. Bingo! The problem goes away. So it's their network that's the issue. Their IT company were called and, with us helping them wherever possible, they worked on it for 2 weeks to find the problem. I captured the port numbers in use by PW admin (60992, 60993, 61000, 61001, 61002, 61003 by the way) and the IT company opened those ports on the router but still, the problem remained :-( And then the breakthrough... They have two VDSL lines into the building that feed their router through a load balancer. It seems that their setup meant that responses to outbound traffic did not necessarily come back in via the same line. Processwire admin does not like this! So, the IT company put in a rule to direct all traffic from the IP of the shared hosting through the same route in and out of the building and BOOM! it all works as expected. Phew! All's well that end's well but it certainly put us through the wringer tracking it down. Actually, I think it's pretty cool that PW does this. A good extra security measure. Several other CMSs (no names...) worked just fine with this scenario but not PW. Anyway, happy client, happy me. Hopefully, this story helps someone else here too.

I agree that you'd be better off with ordinary child pages than PageTable pages if there will be hundreds of them. Remember that you can access a paginated list of child pages from within Page Edit by visiting the Children tab, that you can long-click the "Edit" link to edit the child page in a modal, and that you can add extra fields to appear in the page list besides the title (and that can be further enhanced with AdminOnSteroids). So nearly as good a PageTable field.

I eventually change the whole system: 1. Created a template "private_gallery" that has two fields: "login" and "password" (Text). 2. When accessing the private gallery the system checks if user is logged in via cookie. If it is not logged in it shows the login page. The galleries are created by the site master, so I don't think there's a need for the usual security involved on a common password. And I can secure the images for each gallery. Thanks for your help.

Maybe I am missing something, which is quite possibly the case. So please educate me. There are two protocols, http and https, for a single domain, but including the extraneous www, gives four combinations. As previously mentioned, www can be defined at the Address record level (or CNAME depending on provider) at your hosting provider. This in effect allows users to type or link to www.yourdomain.com and yourdomain.com resulting in the same hosting server doc root destination. So that leaves the two protocols remaining. Are you serving content specific to a non secure site that is not available through the secure site? If there is no specific content unique to one site, then you can use https://yourdomain.com (better google results), and also set the ProcessWire templates to https only (Although that last part is optional). In my non-secure site conf file, I redirect non-secure requests to the secure site by the following: <VirtualHost x.x.x.x:80> ServerName domain.com Redirect permanent / https://domain.com/ </VirtualHost> This is my exact setup, and using the ProcessWire generated htaccess file. Google's page speed reports, "In our test, your server responded in 0.28 seconds." There were no re-direct incidents, and visitors can access my secure site using any of the four combinations. Like I said, if I am missing something, then please let me know. I'm always open to learning something new.

I know this is a pretty old thread, but every time it comes to creating a Repeater through the API, I get LOST. @thetuningspoon's function illuminates a LOT of what happens behind the scenes when a new Repeater is made through the GUI - but I just keep wishing it was as simple as: $f = new FieldtypeRepeater(); $f->set('name', 'repeaterTest'); $f->add($repeaterField1); $f->add($repeaterField2); $f->save(); Because that isn't technically possible without setting the Fieldgroup or Template that will be used by the Repeater first, right? At the end of the day, I think we should improve the docs for Repeaters (https://processwire.com/api/fieldtypes/repeaters/) to include a section on creating a Repeater from scratch through the API so that this process is more easily understood. I am always referencing several Forum posts and parts of the docs in order to get through the spaghetti - having everything in one place would be great. Otherwise it would be awesome to have some functions as a part of the FieldtypeRepeater Class that cut down on the amount of API calls one needs to make in order to create one of these. Just my 2 cents.

Many thanks , Adrian! After adding that namespace and changed all wire("config") to $config , wire("fields") to $fields and wire("templates") to $template in instructions.php , all is OK! Thanks, again!

I recently had to setup front-end system to handle logins, password resets and changing passwords, so here's about how it was done. This should be functional code, but consider it pseudocode as you may need to make minor adjustments here and there. Please let me know if anything that doesn't compile and I'll correct it here. The template approach used here is the one I most often use, which is that the templates may generate output, but not echo it. Instead, they stuff any generated output into a variable ($page->body in this case). Then the main.php template is included at the end, and it handles sending the output. This 'main' template approach is preferable to separate head/foot includes when dealing with login stuff, because we can start sessions and do redirects before any output is actually sent. For a simple example of a main template, see the end of this post. 1. In Admin > Setup > Fields, create a new text field called 'tmp_pass' and add it to the 'user' template. This will enable us to keep track of a temporary, randomly generated password for the user, when they request a password reset. 2a. Create a new template file called reset-pass.php that has the following: /site/templates/reset-pass.php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { $u = $users->get("email=$email"); if($u->id) { // generate a random, temporary password $pass = ''; $chars = 'abcdefghjkmnopqrstuvwxyz23456789'; // add more as you see fit $length = mt_rand(9,12); // password between 9 and 12 characters for($n = 0; $n < $length; $n++) $pass .= $chars[mt_rand(0, strlen($chars)-1)]; $u->of(false); $u->tmp_pass = $pass; // populate a temporary pass to their profile $u->save(); $u->of(true); $message = "Your temporary password on our web site is: $pass\n"; $message .= "Please change it after you login."; mail($u->email, "Password reset", $message, "From: noreply@{$config->httpHost}"); $page->body = "<p>An email has been dispatched to you with further instructions.</p>"; $showForm = false; } else { $page->body = "<p>Sorry, account doesn't exist or doesn't have an email.</p>"; } } if($showForm) $page->body .= " <h2>Reset your password</h2> <form action='./' method='post'> <label>E-Mail <input type='email' name='email'></label> <input type='submit'> </form> "; // include the main HTML/markup template that outputs at least $page->body in an HTML document include('./main.php'); 2b. Create a page called /reset-pass/ that uses the above template. 3a. Create a login.php template. This is identical to other examples you may have seen, but with one major difference: it supports our password reset capability, where the user may login with a temporary password, when present. When successfully logging in with tmp_pass, the real password is changed to tmp_pass. Upon any successful authentication tmp_pass is cleared out for security. /site/templates/login.php if($user->isLoggedin()) $session->redirect('/profile/'); if($input->post->username && $input->post->pass) { $username = $sanitizer->username($input->post->username); $pass = $input->post->pass; $u = $users->get($username); if($u->id && $u->tmp_pass && $u->tmp_pass === $pass) { // user logging in with tmp_pass, so change it to be their real pass $u->of(false); $u->pass = $u->tmp_pass; $u->save(); $u->of(true); } $u = $session->login($username, $pass); if($u) { // user is logged in, get rid of tmp_pass $u->of(false); $u->tmp_pass = ''; $u->save(); // now redirect to the profile edit page $session->redirect('/profile/'); } } // present the login form $headline = $input->post->username ? "Login failed" : "Please login"; $page->body = " <h2>$headline</h2> <form action='./' method='post'> <p> <label>Username <input type='text' name='username'></label> <label>Password <input type='password' name='pass'></label> </p> <input type='submit'> </form> <p><a href='/reset-pass/'>Forgot your password?</a></p> "; include("./main.php"); // main markup template 3b. Create a /login/ page that uses the above template. 4a. Build a profile editing template that at least lets them change their password (but take it further if you want): /site/templates/profile.php // if user isn't logged in, then we pretend this page doesn't exist if(!$user->isLoggedin()) throw new Wire404Exception(); // check if they submitted a password change $pass = $input->post->pass; if($pass) { if(strlen($pass) < 6) { $page->body .= "<p>New password must be 6+ characters</p>"; } else if($pass !== $input->post->pass_confirm) { $page->body .= "<p>Passwords do not match</p>"; } else { $user->of(false); $user->pass = $pass; $user->save(); $user->of(true); $page->body .= "<p>Your password has been changed.</p>"; } } // display a password change form $page->body .= " <h2>Change password</h2> <form action='./' method='post'> <p> <label>New Password <input type='password' name='pass'></label><br> <label>New Password (confirm) <input type='password' name='pass_confirm'></label> </p> <input type='submit'> </form> <p><a href='/logout/'>Logout</a></p> "; include("./main.php"); 4b. Create a page called /profile/ that uses the template above. 5. Just to be complete, make a logout.php template and create a page called /logout/ that uses it. /site/templates/logout.php if($user->isLoggedin()) $session->logout(); $session->redirect('/'); 6. The above templates include main.php at the end. This should just be an HTML document that outputs your site's markup, like a separate head.inc or foot.inc would do, except that it's all in one file and called after the output is generated, and we leave the job of sending the output to main.php. An example of the simplest possible main.php would be: /site/templates/main.php <html> <head> <title><?=$page->title?></title> </head> <body> <?=$page->body?> </body> </html>