Leaderboard

I hope that you all had a great Christmas holiday (or other holiday that was last week). And likewise hope that you have a Happy New Year this upcoming week. This week we'll take a quick look at last week's new master version launch and then discuss the status of the new ProcesssWire.com website currently in development: https://processwire.com/blog/posts/rebuilding-the-pw-site-5/

ProcessWire is like a breath of fresh air. So powerful yet simple to build with and customise, and web editors love it too. Margaret Chatwin, Web Developer ?

I started in PW a few years back. I love what I’ve been able to develop, although most have been simple marketing websites. I’m a brand developer by trade but I’ve been doing frontend and light database/ php since the late ‘90s. My perception of PW is that it’s a real tool. You can build stuff and not have so much abstraction that revisiting a project requires a ton of time figuring out what code does. I like that because building stuff with staying power serves my clients well. I think PW attracts the kind of person who loves well crafted things; like a good Italian shoe that can be resoaled versus throwing the shoes away because they’re made cheap. I think that PW could really find a wider base if there was a learning framework. There are key people in this community, including Ryan, that could build a curriculum starting from scratch. Courses we pay for that teach us good fundamentals because there are multiple ways to get stuff done but maybe a lot of us could improve our spaghetti code. Then we could delve into more complicated stuff like writing to pages from frontend pages. Some could even involve getting best use of Pro modules. This is an investment because unlike other systems, PW is so fundamentally sound and non-changing that the information would be sound for years. Thanks for listening.

Exciting that the new processwire.com could arrive within the next week! Caught me by surprise too, as I thought it was early days yet for the design and that there would be more evaluation/discussion/iteration of it before it went out live to the world. But I can appreciate also that a "move fast and break things" approach is often the most productive. A couple of observations/opinions of previous screenshots (I didn't comment earlier because I thought it might have been too early for this sort of thing)... I'm not liking the typeface used in the new design. My main gripe is the curved strokes used on characters such as A, V, w, etc. This design detail looks ugly and amateurish to my eye. I know it's a small detail and such things can be a matter of taste but in support of my opinion I'll add that if you look at the work of the top-tier type foundries such as Hoefler or Klim you won't find any typefaces that curve the strokes on these characters. I also think the x-height is excessively large (the height of the lowercase relative to the uppercase). Again it's a subtle thing but I'd argue this sways the balance too far towards "friendly" versus "serious". My preference would be for something more neutral and serious as the main typeface. As an example, Molde is very affordable at the moment and a great workhorse due to the many included weights and widths. Another observation is that the pages that have the entire page background in blue are pretty intense. It's too strong IMO and not so comfortable or inviting for reading. And when it comes to the Showcase the focus should be on the site screenshots - the page design should aim to show them off as best as possible. A strongly saturated background distracts from and can clash with the content in the screenshots. I think the blue background works better in smaller blocks on the page, to highlight a section or provide differentiation between sections on the page. When it comes to large background areas I think white or greys would be better (this could include dark greys or black if we want some blocks to have reversed type). The other thing that I think it would be good to discuss is who the target user of ProcessWire is. I'd love to hear @ryan's view on this, as well as other community members' views. Of course many different types of user could find value in PW, but when it comes to designing and evaluating marketing materials such as processwire.com I think it can be helpful to form a clear picture of a specific target user. We can't have "everyone who wants to make a website" as a target - so who is the user that will find most value in PW, who is that user we want to draw in? I discovered this older topic recently that has some interesting discussion about promoting ProcessWire as an "enterprise CMS". I'm not saying that "enterprise" is what we want to focus on as a primary target market (I don't think it is), but I do think that we need to have more of these kinds of discussions with the aim of clarifying who ProcessWire is targeted to and how best to reach that audience. My view is that the PW's biggest asset is its powerful and well-documented API. And the user who is most able to benefit from that is a user who has a fair amount of development experience. It's probably a user who is a professional developer in one form or another. It's hard to get a sense of the breakdown of types of users currently working with PW - the forum is one of the few ways but it's not a good guide because there could be many experienced developers using PW who don't need help via the forums and are perhaps too busy to make other contributions there. But generally I get the sense that PW is not reaching experienced professional developers as well as it could. Part of reaching and capturing the target audience involves making sure processwire.com communicates to that audience that you've come to the right place. The cues for this can be subtle. I think the visual and written language of processwire.com should be serious, neutral (PW is "unopinionated"), and prepared with the professional developer in mind. The API should be emphasised and we should be careful to avoid any "dumbing down" that might obscure the fact that PW is a powerful and sophisticated tool. I'm not saying that the proposed design or the existing processwire.com are failing in this regard - just that I think these things should be key considerations.

It's not that I don't trust people but... I'd be careful with things like that. First off all most people just take code they get from whoever and place it somewhere without knowing what will happen afterwards. If there are tools and services like Facebook Pixel, HubSpot or similar they want to use, give them the option to enter only the necessary details like Pixel ID or campaign ID and let your system do the rest. Maybe you can ask your users what they want to add to their landingpages and start from there. In my opinion that's much safer and easier for everyone. If it was my service I wouldn't allow them more than that. At the end I'm the one that risks everything.

(taken from https://processwire.com/talk/topic/7494-case-study-the-triumph-of-national-geographic-traveller-india-in-processwire/) More can be seen here: https://www.fixmy.pw/blog/why-we-love-processwire-cms-so-much-especially-after-working-with-crappy-joomla-wordpress-and-drupal-cmss/, starting at "For Developers, it's a welcome dream." ?

@adrian Probably yes, I've changed that, thanks. Yesterday I added a "translatorModal" tweak to Misc that allows editing translations in a modal, hope you find it useful.

This is now available:

read more here: http://ocramius.github.io/blog/fast-php-object-to-array-conversion/

this one from here: https://processwire.com/talk/topic/11355-large-b2b-website-goes-processwire/?tab=comments#comment-105946

I currently use the Cobalt2 Theme by Wes Bos, and I like it thus far. I believe in his themes he uses a paid font for functions etc, so I found something similar to use in my own: It took me a few minutes to get use to the new font, but I like it a lot now. To me the theme is a nice alternative to the dark theme that I use to love so much.

Hi @PWaddict Could you please make the thread readable by putting your long trace of logs into "spoilers"? This one and the another one:

Hello!!! Thanks for your development!!! How much will the module costs? I have a current project with ecommerce and I need to decide if i should wait for the release! Thank you very much in advance! Gerald @mate-themes

Additionally using a modal to edit translations would be also handy ("Edit" button, "Bearbeiten" on the screenshots above). On closing the modal, the file list could be easily reloaded with triggering a reload event on the Inputfield. I'll probably add this to AOS if time allows. Update: added to v2.0.8

Created a request issue for this https://github.com/processwire/processwire-requests/issues/251

@kixe I think the module entry on the ProcessWire module page should also be removed, as it has no use anymore.

Hi, Is your webiste files placed under the `/usr/local/apache/htdocs` folder ? If yes, change the directive `AllowOverride None` to `AllowOverride All` from the Apache config file then restart Apache service: `sudo service apache2 restart` DocumentRoot "/usr/local/apache/htdocs" <Directory "/usr/local/apache/htdocs"> # # Possible values for the Options directive are "None", "All", # or any combination of: # Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews # # Note that "MultiViews" must be named *explicitly* --- "Options All" # doesn't give it to you. # # The Options directive is both complicated and important. Please see # http://httpd.apache.org/docs/2.4/mod/core.html#options # for more information. # Options Indexes FollowSymLinks # # AllowOverride controls what directives may be placed in .htaccess files. # It can be "All", "None", or any combination of the keywords: # AllowOverride FileInfo AuthConfig Limit # # AllowOverride None AllowOverride All # # Controls who can get stuff from this server. # Require all granted </Directory> Edit: make sure you load the `rewrite` apache module : `sudo a2enmod rewrite`

Not sure if you need this anymore and if I understand your issue properly, but this is how you can hook to get your custom translations. I use it for testing purposes in one of my modules, adding here too, perhaps somebody will find it useful. wire()->addHookAfter('LanguageTranslator::getTranslation', function (HookEvent $event) { $args = $event->arguments; // do something here... $event->return = "aa"; });

Even I am working on my Child Care Website Design and learning everything step by step. Was just looking for the best practices to update the home page and this post has helped me a lot. In fact other threads have also been useful for me to create the contact page and landing page. Keep sharing your valuable answers!

Finally ?? Thank you adrian for this awesome tool and your great support in the forum!

This may help others. You're going to get labels for this field's output that you probably won't need (no fault of this module). This CSS .InputfieldMarkupCKEditor .InputfieldHeader { display: none; } will hide them visually, while this JavaScript function (function () { var labels = document.querySelectorAll('.InputfieldMarkupCKEditor .InputfieldHeader'); for (var i=0; i < labels.length; i++) { labels[i].setAttribute('aria-hidden', 'true'); } })(); will hide them from screen readers.

For simple json outputs, you can use WireArray::explode and json_encode() or wireEncodeJSON() methods https://processwire.com/api/ref/wire-array/explode/ $myPages = $pages->find('template=basic-page'); // extract required fields into plain array $data = $myPages->explode(['title', 'created']); echo wireEncodeJSON($data);

the problem is that you have an array, but the items in the array are \ProcessWire\Page objects, so those can't directly map to a json encode. you probably need to cycle through the pages you want and create the array manually. Alternately you could have a look at the GraphQL module, which i think some devs are using to get json data to the frontend.

Unless you are doing some one-time import/export, you usually want to avoid actions that require loading huge amounts of pages in one request. This is a non-sustainable way of building a web site in any platform, because eventually you will run out of memory. If you are making a small web site, then you don't need to worry about it. But if you are making something that will grow big, you need to place limits on API calls that could might lots of pages (as in, use the "limit=n" in your selectors). Going directly to MySQL is certainly a fine way to go if you need to perform some query that can't easily be performed in the API. Though admittedly, I almost never need to do this, but there's no harm in doing it. One other thing I want to mention is the $pages->count() function, which works exactly like $pages->find() but instead returns a count of the matching pages. It does this without actually loading the pages it's counting, so may be applicable here.

Based on netcarvers first script I tried this on my products (550) and grouping them by price field. $pa = $pages->find("template=product,sort=sort"); $groups = array(); foreach($pa as $p) $groups["$p->sc_price"][] = $p->id; echo "<ul>"; foreach($groups as $key => $gr){ $count = count($gr); echo "<li>$key ($count)"; if($count){ echo "<ul>"; foreach($gr as $key => $pid){ $r = $pages->get($pid); echo "<li><a href='$r->url'>$r->title</a></li>"; } echo "</ul>"; } echo "</li>"; } echo "</ul>"; echo "<br/>memory:".memory_get_peak_usage()/1024/1024; This doesn't add much memory in my case, 1MB more and maybe takes +~1sec but haven't looked at execution times. So 2000 pages will maybe be around +2-3MB and 2-3 seconds. I can run this script along with a ton other heavy scripts easily with 16M php memory limit. Further if you use PW's markup cache to only generate the list once every hour you would save some resources. Try it and see what you get. If memory would be a problem you might still consider constructing 1 or 2 sql queries and see if it performs better. This surely would involve some complex sql joins over fields, fieldgroup and page tables and make sure pages are published etc.