Leaderboard

Hey guys. http://supertiny.agency/ For those of you that have already seen my website, this won't look much different. Under the hood however, I've made a few SEO oriented updates that involved a not so simple overhaul. New stuff includes a new services page, some tweaks here and there, but more importantly the navigation was remade to allow deep linking and proper page by page SEO. The previous site was a single page and worked more like a presentation than a website. Navigating links happened without page loads in order to have nice animated transitions. But search engines don't like that so I had to do something about it. The basic approach is quite simple. For each template file, I have a condition that includes a different file according to the type of request: <?php if($config->ajax) { include('./_about--ajax.php'); } else { include('./_about--direct.php'); } ?> Ajax returns just the chunk of content, whereas direct returns a complete page with the SEO stuff. Then I have a bunch of jQuery that basically looks for internal links and overrides them to be loaded via ajax instead of a regular page load. Engines can crawl, and users get nice transitions. The JS pushes a history state, sends a link update to Analytics and transitions into the new page. More and more ProcessWire looks to me like the jQuery of the CMS world.

I've just pushed a new version of the Create Users Batcher which adds proper CSV parsing (so you can have commas, quotes, spaces etc in other user fields) - thanks to @Rudy for noting this deficiency. I have also added the option to use JSON instead of CSV in case that is easier for your needs. Creation now also supports image fields so you can use a URL to an image to have that added to the user's page.

We have all been waiting for this for a long time so I could not resist: https://github.com/processwire/processwire-requests/issues/114 Fingers crossed

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 should know that this site brings my late 2011 Macbook Pro to its knees. I really love the story you are telling and it's definitely a great way to show clients how working with you would be a great experience, but I would also be worried that if your site crashes a potential clients machine, it might not give the best impression. Also, a 4MB payload for your homepage is pretty steep for someone on a slow connection. SpeedTest shows my download at 163 Mbps and it still takes 9-10 seconds to load your homepage. Please don't take offense at this, because I really do like the message and the way the story is presented, although I could do without the sound effects

hi @rafaoski maybe https://laragon.org/ is interesting for you as a replacement for xampp. i use it on win10 for about a year and it's great

Agreed. I'm still convinced that PW should be PHP 5.6+ as everything before that it unsupported (all support for previous versions ended over a year ago). At the very earliest, I think the limit should be 5.5. Edit: I actually think Teppo should run a weekly.pw poll on this...

My apologies - yes, I see that those vendor libs are also PHP 5.4+ (https://github.com/lesaff/ProcessWire-Sassify/blob/edbbc4dad1a2a38e64a084638cf69aa9c663abe4/vendor/leafo/scssphp/scss.inc.php#L3) I might really be time for PW to dump support for 5.3. Just looking around, Drupal stopped supporting it 3 years ago!

The suggested costs from that website is probably for another earth and definitely not the one we are living in!

That site was shown by someone in the past here in the forum, and most of us agreeded that those estimations were way too high for the current market, wherever you live. Good luck if a client of yours can afford those quotations, you will be my hero

Are you building a multi-language website? When saving multi-language fields, PW appends language id to fields. 1012 is the language id for a language installed in PW. You can use $pages->get(1012)->title to see which. To set description for an image you should first set field to accept descriptions. Go to Fields > image_field > Input > Number of rows for description field. Then enter a description for your image When you save the page, you should be able to get image description using $image->description(). From the core documentation: // $image = $page->image_field->first /** * Get or set the file’s description (with multi-language support). * * When not in a multi-language environment, you can still use this method but we recommend using the simpler method of just * getting/seting the `Pagefile::$description` property directly instead. * * ~~~~~ * // Get a Pagefile to work with * $pagefile = $page->files->first(); * * // Setting description * $pagefile->description('en', 'Setting English description'); * $pagefile->description('de', 'Setting German description'); * * // Getting description for current language (whatever it happens to be) * echo $pagefile->description(); * * // Getting description for language "de" * echo $pagefile->description('de'); * ~~~~~ * * #pw-group-common * #pw-group-manipulation * * @param null|bool|Language|array * - To GET in current user language: Omit arguments or specify null. * - To GET in another language: Specify a Language name, id or object. * - To GET in all languages as a JSON string: Specify boolean true (if LanguageSupport not installed, regular string returned). * - To GET in all languages as an array indexed by language name: Specify boolean true for both arguments. * - To SET for a language: Specify a language name, id or object, plus the $value as the 2nd argument. * - To SET in all languages as a JSON string: Specify boolean true, plus the JSON string $value as the 2nd argument (internal use only). * - To SET in all languages as an array: Specify the array here, indexed by language ID or name, and omit 2nd argument. * @param null|string $value Specify only when you are setting (single language) rather than getting a value. * @return string * */ public function description($language = null, $value = null) { /* ... */ }

@Mike Rockett It's declared in `SimpleContactFormConfig.php:19`. It was declared as string (oops, my fault ) but should be of type array. I've fixed it.

Unless you changed it, Blog does not have an image field called 'images'. If you didn't change it, then the field is called 'blog_images'. FYI, all fields in Blog are prefixed blog_. The following should get you going... <img src=\"{$child->blog_images->first->size(200,200)->url}\">

Yes, that means you're on PHP < 5.4. Highly recommended to upgrade to 5.6 at the very least.

Turns out I was using a selector that didn't work... I basically used the same one I use for regular search. In the end my selector just needed to define the parent, that was all. It all works nicely now. I've added a little LazyCron task too: I save the JSON in certain intervals to a (hidden) PW page/field, and only query this JSON data with JS. It really speeds things up. Otherwise (with browser cache cleared) I had to wait a few seconds till the suggestions were loaded. Thanks again for your help, suggestions + patience @AndZyk

FieldtypeColor is on github Fieldtype stores a 32bit integer value reflecting a RGBA value. Input 5 types of Inputfields provided Html5 Inputfield of type='color' (if supported by browser) Inputfield type='text' expecting a 24bit hexcode string (RGB). Input format: '#4496dd'. The background color of the input field shows selected color Inputfield of type='text' expecting 32bit hexcode strings (RGB + alpha channel) Input format: '#fa4496dd' Inputfield with Spectrum Color Picker (Options modifiable) Inputfield type='text' with custom JavaScript and/or CSS (since version 1.0.3) Output Define output format under 'Details' tab in field settings. Select from the following 9 options string 6-digit hex color. Example: '#4496dd' string 8-digit hex color (limited browser support). Example: '#fa4496dd' string CSS color value RGB. Example: 'rgb(68, 100, 221)' string CSS color value RGB. Example: 'rgba(68, 100, 221, 0.98)' string CSS color value RGB. Example: 'hsl(227, 69.2%, 56.7%)' string CSS color value RGB. Example: 'hsla(227, 69.2%, 56.7%, 0.98)' string 32bit raw hex value. Example: 'fa4496dd'(unformatted output value) int 32bit. Example: '4198799069' (storage value) array() array( [0] => 0-255, // opacity [1],['r'] => 0-255, [2],['g'] => 0-255, [3],['b'] => 0-255, ['rx'] => 00-ff, ['gx'] => 00-ff, ['bx'] => 00-ff, ['ox'] => 00-ff, // opacity ['o'] => 0-1 // opacity ) The Fieldtype includes Spectrum Color Picker by Brian Grinstead SCREENSHOTS Input type=text with changing background and font color (for better contrast) Input type=color (in Firefox) Javascript based input (Spectrum Color Picker) Settings Output Settings Input

Thanks for jumping in so quickly! I figured it out in the meantime: all the products are hidden currently because I use Page Protector's "Protect Hidden Pages" to makes sure nothing is leaking on a live site while in development No result set, no fields and no records either. At least I would expect the Fields to show up. Of course empty file is expected in this case. Is it possible to send a message for dummies like me in such a case? Anyway, it would be great to be able to include=all because I will be needing to export/import no matter what the page status flags are. Is it possible?

Hey @szabesz - I just did a check of everything here and I can't reproduce any of these issues (although #3 is probably a Reno specific thing which I'll check in a minute). Could you perhaps help me debug - firstly the missing child page template fields - those are collected here: https://github.com/adrianbj/BatchChildEditor/blob/fe93376a2846df53eba4b102bc5d5ba89f52e09f/BatchChildEditor.module#L938-L943 It would be great if you could add: bd($allFields); at line #944 and check the names of each of the contained fields in the array or let me know if this is empty for some reason. Once we figure this out, we'll get onto why the CSV might be empty.

Thanks @adrian, I haven't came across these issues, good to know. The AddNewChildFirst submodule works pretty neat, thanks for your contributions in this topic - I only collected all the goodies from there

Nice concept, thanks for sharing! One issue though: the X on a Folio page does not seem to work. There is no "back" either:

The module uses ProcessWire's own form API; you just need to set the required fields to be required in the admin.

@gmclelland Basically, what I did is installing this module: https://processwire.com/api/modules/lazy-cron/ Then I added this one line at the very bottom of my "search-input" template (the only place I need to ever access that index JSON): wire()->addHook('LazyCron::everyHour', null, 'cronAutocompleteJSONCache'); In file _cron.php, that I include_once("./_cron.php"); in my search-input template, I have this: <?php namespace ProcessWire; function cronAutocompleteJSONCache(HookEvent $e) { $selector = "parent=1041, has_parent!=2"; $matches = wire('pages')->find($selector); foreach ($matches as $match) { $result = array( "title" => htmlspecialchars_decode($match->title), "year" => $match->year, "project_desc_short" => htmlspecialchars_decode($match->project_desc_short) ); $results[] = $result; } $cacheHolderPage = wire('pages')->get(10029); $cacheHolderPage->setOutputFormatting(false); $cacheHolderPage->autocomplete_json = json_encode($results); $cacheHolderPage->last_update = date('d.m.Y h:i:s'); $cacheHolderPage->save(); } Of course, I could have also saved the JSON on the file-system, and check the timestamp, and decide on every request if the static JSON is older or newer than the PW-content, and load/generate one or the other, but for my needs, this seemed like the easiest and most straightforward solution. PS the field last_update I have only added for myself to see if it really works. I made it a "read-only" field in the settings. (not editable)

If I understand the needs correctly, I think this is a perfect use case for WtireCache (https://processwire.com/blog/posts/processwire-core-updates-2.5.28/#wirecache-upgrades). I use this to store the results of a complex set of selector queries that serve JSON to an AngularJS app.

There are other files that use the new array syntax, so those would need to be changed too. Considering that changes would need to be made to vendor libs as well, the best bet would be to get onto a newer version of PHP.

Here's WireArray::first method public function first() { return reset($this->data); } Documentation for reset() function says Returns: the value of the first array element, or false if the array is empty. Error: Call to a member function size() on a non-object i.e. boolean false happens because $child->images is empty for a certain child. A simple JS should help you pinpoint the faulty page. foreach ($pages->find("template=blog-post, limit=12, sort=-blog_date") as $child) { if (!is_object($child->images->first)) { $content .= "<script>alert('something wrong with $child->name')</script>"; } $content .= // ... }

I love you more than my dog.

Glad to hear it works now. If your site doesn't frequently change, there is an cache option available in the Typeahead plugin: But use whatever works best for you.

More improvements to the Captain Hook panel which I think now makes it the definitive source for browsing and understanding what each hook does. You have always been able to click the line number to open the file to the line of the method in your code editor (if you have things set up correctly), but this new version adds the following two new features: 1) Inline documentation for each hook - click method (last column) to expand/collapse the docs: 2) Direct link to PW API reference (from the Class::method link in the first column), eg clicking on "Pages::saved" will take you directly to this page:

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.

I boosted it with +1s and one more Pro: "PRO Fast without caching, small footprint (less than 2000 files) for a full featured CMS/CMF. You can optionally use Composer but you are not forced to. Upgrading can be done via the admin and it is a very easy process. Security is exceptional, no hacking incidents have been reported so far." You guys might want to go there to agree

A couple of new tutorials: https://webdesign.tutsplus.com/tutorials/processwire-admin-theme-strategies--cms-29244 https://digitalardor.com/articles/basic-setup-for-content-blocks-in-processwire/ and a Slant list showing PW as the best PHP CMS with currently no down votes https://www.slant.co/topics/5409/~php-cms

Hello @dragan, happy to hear that you find this tutorial useful. At the time of writing this tutorial I didn't knew how easy you can output your own JSON without a module. Currently I don't need the Pages2JSON module anymore, but instead output the JSON inside my search template like this: <?php if ($config->ajax) { $selector = [ "title|and|more|fields%=" => "", "template!=" => ["templates", "to", "exclude"], "has_parent!=" => 2 ]; $matches = $pages->find($selector); $results = array(); foreach ($matches as $match) { $result = array( "title" => htmlspecialchars_decode($match->title), "url" => $match->url ); $results[] = $result; } header("Content-Type: application/json"); echo json_encode($results); return $this->halt(); } else { // Your regular template This way you build your own array with all necessary keys and then encode them as JSON. Regards, Andreas

There are a couple of things that can shine out above all else. One of these things is cost-reduction. I've often said to my clients that using ProcessWire over WordPress is farmore cost efficient due to its simple flexibility. Naturally, this depends on the client and their needs, but, at the end of the day, putting together a site with PW is easier and far more straight-forward, and this needs to be communicated to the client. Unfortunately, I don't use WordPress at all, and so I don't have any statistics for you. What you really need to do is take all the known considerations and put them into context. Present it as a document, and you can win the client over. I'm surprised the WP=CMS mentality still exists...

Hi, I do not think there are solid statistics to showcase but we have good blog posts you might use to pick the info you can use to persuade clients: https://processwire.com/blog/posts/building-canongate/ https://processwire.com/blog/posts/cms-critic-powered-by-processwire-again-case-study/ https://processwire.com/blog/posts/new-2.8-version-current-projects-and-pw-usage/ https://processwire.com/blog/posts/roadmap-2017/ etc... Also, you can find good case studies here: https://processwire.com/talk/forum/9-showcase/ https://processwire.com/talk/forum/16-case-studies/ https://weekly.pw/ (site of the week) Hope this helps.

Yay, update: https://github.com/blynx/MarkupProcesswirePhotoswipe Now has some simple 'themes', cooler ones later ... <?php $pwpswp = $modules->get('MarkupProcesswirePhotoswipe'); echo $pwpswp->renderGallery($page->nicePictures, ['theme' => 'h-scroller']); // available themes: plain, flex, h-scroller 0.7 - 2017/07/11, themes fixed: Size option correctly adopts height value added: Theme functionality added: Simple themes 'plain' (previous default), 'flex', 'h-scroller' other: Updated readme other: No notice on undefined photoswipe options other: Refactoring

Updated to Version 1.0.3 with one more Inputfield Option which allows to use any custom JavaScript.

I have some pages that are used only as partials, to be rendered as part of other pages using $page->render() I have them inside a /widgets/ branch in my page tree. The problem is that they are viewable from the front-end: if someone visits mydomain.com/widgets/my-widget/ they see the partial HTML. Is there a way I can keep my widgets accessible to editors in the back-end and capable of being rendered in other pages but without them being directly viewable?

Thanks for the ideas. @mr-fan: I think this might be the sort of thing you're hinting at - at the top of the widget templates... <?php if( empty($options['pageStack']) ) throw new Wire404Exception(); ?> Good info in this post from Jonathan Lahijani here and some info on pageStack from Ryan here. I like this solution. @LostKobrakai: Sounds like this would work, but it seems to me there are downsides to using wireRenderFile() over $page->render(). I have a lot of different widget templates and widgets are selected by editors via a page field, so using $page->render() keeps the rendering code really simple and maintenance-free. foreach($page->widgets as $widget) { echo $widget->render(); } But if I use wireRenderFile() I need a whole chain of logic to check the template of each widget and render it with the correct file for that type of widget. Besides avoiding partial pages being directly viewable, are there other benefits of wireRenderFile() that make it preferable to $page->render()?

I catch the login throttle messages and pass them to a session variable which is displayed on the login page: // login user try { $u = $session->login($username, $pass); } catch(Exception $e) { $session->logout(); // without this line the user will be logged in although the exception is thrown $session->login_error = $e->getMessage(); $session->redirect($pages->get('/login/')->url); } Strange thing is that without the $session->logout(), my login page will show the error message that is thrown by the login throttle but still login the user. Is this intended behaviour?

OK it seems to work now. I have done the following (from a already installed ProcessWire): - Export database - Modified the lines in the exported file that have ENGINE=MyISAM DEFAULT CHARSET=utf8; to be ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; - Imported file in to the database - Created a MySQL config file (in my case /etc/my.cfg) and added the following lines [client] default-character-set = utf8mb4 [mysql] default-character-set = utf8mb4 [mysqld] character-set-client-handshake = FALSE character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci - Restarted MySQL - Modified the following ProcessWire files: /wire/config.php line 47: $config->dbCharset = 'utf8mb4'; /wire/core/Database.php line 72: else if($config->dbSetNamesUTF8) $this->query("SET NAMES 'utf8mb4'"); /wire/core/Fieldtype.php line 421: 'xtra' => 'ENGINE=MyISAM DEFAULT CHARSET=utf8mb4', /wire/core/WireDatabasePDO.php line 82: PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'utf8mb4'", This seems to be working, i didnt get the MySQL PDO error anymore about the \xF0\x9F\x92\x93\xF0\x9F character Altough i'm not so happy to have modified the files in the wire folder, since these are core files and will be overwritten as soon as i update the wire folder by replacing the files inside. Would be nice to be able to set this value somewhere in a config file. Update: a recent update in the PW DEV branche includes the ability to set the charset in the configuration file. The issue is discussed here: https://github.com/ryancramerdesign/ProcessWire/issues/452

Ipa, catch the Exception and print out the message, for example: try { // Login } catch (WireException $e) { // Print out message of exception echo $e->getMessage(); }