Leaderboard

On the issue of We're getting very OT here, but I have handled this is many different way depending on needs, but this module (originally by @apeisa and fixed for PW 3 by @teppo can actually be a great starting point for a frontend user interface: https://github.com/teppokoivula/AdminBar You will want to skin it to match your site etc, but it can look and work really well, eg:

Curious what everyone else thinks. Maybe it won't be a huge deal in most cases, but I can see sites with certain header and footer content being cutoff with this design. Have a read of their developer guidelines - yet another thing to consider in our designs: https://developer.apple.com/ios/human-interface-guidelines/overview/iphone-x/ Honestly I think more square corners for the device itself look better and I think the screen should be completely square - I feel like this is stepping back to old TV rounded corners: Note that I don't like the edge of the Samsumg Galaxy S8 either - I feel like it looks weird and I am sure your hands would end up covering the edge of what you are trying to view. Sorry for rambling, but I am curious what everyone else thinks they should be aiming for both esthetics and functionality?

Sorry, I was more talking about my post rather than what you guys were posting. I completely agree with your goals for 2018. In fact I am currently trying to convince a Drupal shop to go with ProcessWire. They don't want to touch Drupal 8 and I have an PW advocate on their team, but we both agree that PW needs a more modern look (website and admin theme) to help convince their clients. Unfortunately it's often not enough that things work great, they also have to look great and look like they will work great - the whole "judging a book by it's cover thing" - as devs we hopefully don't do that, but clients will!

Sounds off topic but may not be so. As pointed out earlier and above, documentation is an important part of the success. Everyone knows that (probably...) And building front-end logins, forms, admins, dashboards, modules and stuff like that is not documented, except for module and core code comments and hard to scan blog posts, of course. But those are hidden bits of information and kinda time consuming to dig up. Also, basic frontend design tutorials are outdated. I propose to make 2018 the year of the documentation, so to speak. What if we could stop hunting for new features for a while and concentrate on the following in 2018: new processwire.com new UIkit admin theme documentation: updated basic frontend design tutorials and lots of real world form API tutorials for the masses. Just my two cents here

@SamC - depending on your needs/preferences, you might also look at these: http://modules.processwire.com/modules/front-end-edit-lightbox/ http://modules.processwire.com/modules/fredi/ https://processwire.com/blog/posts/front-end-editing-now-in-processwire-3.0-alpha-4/#now-all-fields-can-be-front-end-editable and also, Tracy comes with a "User Bar" which you can skin that links to the backend to edit the current page: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=127824

Now solved!!! The issue turned out to be one page field within a repeater. I'd set 'Template of selectable page(s)' to 'blog-post' and then set 'sort=-blog_date' in the 'Custom Selector to find selectable pages' field thinking the two selectors would combine. Turns out they don't, at least not in this way. All pages, repeaters and other admin sub pages were selectable within this field. The site has hundreds of pages, many with a large number of repeaters in so every time the page admin was loaded / saved it read all of them. Combining the required filters with only the statement 'page-template=blog_post,sort-=blog_date' for this page field did the trick and the admin for this template (and saving pages with this template) now works really quickly. Phew!

One trick is to do this instead... if('pageGeo' == $page->template) If you mistyped that as: if('pageGeo' = $page->template)// syntax error // OR even if(1 = $page->id)// syntax error PHP will throw a Parse Error: syntax error, unexpected '=' , immediately alerting you of your mistake .

CMS critic is one website and not even a very popular one. It has done great stuff promoting PW (and many other systems out there), but it is very small amount of visibility. ProcessWire is steadily pushing forward, but it is true that some systems did get more popular in much faster - especially craft. See this https://trends.google.co.uk/trends/explore?date=all&q=processwire,craft cms (I believe they did get most users from dying Expression Engine community where they were popular plugin authors). I think ProcessWire is "old dog" now for most - it isn't "new and interesting" anymore, so all kind of marketing "gimmicks" should be used. New features should be promoted much more (videos, tutorials, blog posts etc). Ryan is doing most of the development, weekly posts and supporting his paid modules, so this is something where community - all of us - could help. Also I believe that this website, docs, tutorials etc are those parts of this project that can be most easily delegated to community. Another one is having official starter themes (site profiles) and admin theme. We have amazing amount of design and development talent here, I wish we could collaborate more easily. We all know Ryan is busy, so do not wait for green light and guidance - if you feel like you could do something for our community - just build it and share it! More people will pick interest and great things will happen!

Personally I have the impression it's growing at a slow but steady pace. And though slow and steady is much better than fast and sloppy, it's a bit frustrating to see other platforms seeming to get more attention while being notoriously inferior. I like following CMS Critic's Awards. PW has got a bunch of exposure there, but this year it's only nominated for "Best for SMEs" alongside Craft and ModX, both paid platforms. I'm guessing Craft will get that one because it looks polished and very DIY, and PW is too "pro" for that category. Then there's "Best free CMS". PW is not there. You see the usual Joomla and Wordpress there, along with CMS Made Simple. That one just trying out the demo makes me cringe. It's so 2001 that I can't take it seriously. Now I've never used Joomla, but I constantly compare PW with Wordpress and can't comprehend how Wordpress still holds on to such a large chunk of the market. "Best Open Source CMS". CMS Made Simple, ModX, Silverstripe. So I went to see what Silverstripe is all about. Now SS looks to use a somewhat similar approach to PW, and though it looks relatively polished, it doesn't feel as mature to me. So we've got PW in one category this year, and the wrong one. To me that feels like a loss, which will reflect another dip in that Google Trends chart over the next year. The next version will be an important step. Updating the default theme of the CMS is a must. I'm guessing most people now immediately install Reno's theme the second they enter the CMS after installing. So a new version with a new look will attract attention and that will hopefully pull it up a bit more. If we want it to grow faster (an argument can be made whether that would be good or not), it's mostly a matter of getting more people to try it out. After getting the first project running, it's hard not to be hooked. On an end note, I think it's time we start considering a refresh on the website. Just saying.

you should definitely invest some minutes and start writing process modules. it's incredible how fast you can create your very own admin GUIs and you will learn to understand processwire a lot better define "success" i agree with most of all posts above but i also want to say that i like the fact (or at least it seems to be like this) that we do NOT attract a lot of "i am looking for a click click and it's done" users. i like the way people here behave, trying to learn things, trying to understand, trying to find their way around the code... maybe if processwire looked more fancy that would be different. i don't know. and maybe it's not ryans goal to become more popular. the roadmap states it as a goal for 2017 - but i'm not sure how important it is for ryan. personally i would love to hear more personal and strategic infos regarding the project. who is the team behind processwire? is it only ryan? what happens if ryan can not continue to work on it? he said at several occasions that there ARE people that could continue the project but i would love to have a more reliable solution/statement for that. i don't really care if we have 10.000 or 10.000.000 users - but i do care if i have enough certainty to be able to work with some kind of software on the long run. to be honest i have some concerns about the last point sometimes. but i calm myself knowing that even if processwire would not get updated for a long time it would still run safely and without any issues and i would have enough time to learn something else

I also wouldn't mind to see a hold on new features in trade for a new ProcessWire.com and finished AdminTheme. I think there are many people that judge by the first impression and are not willing to dig deeper if this impression isn't state of the art. Maybe we could develop a new style guide for the website and all the other websites evolving around ProcessWire. I am missing a consistency in the design there.

Excellent choices above

@chrizz my question was, if you used <head></head><body></body> tags in your HTML-message. Now I know, you don't. That was the reason why the Signature wasn't attached to the HTML-message-part. https://github.com/horst-n/WireMailSmtp/blob/532dd94752597a4b2b9f3a2c02ef48b21db77f84/WireMailSmtpAdaptor.php#L280-L285 With the modules update to version 0.2.5, the html-signature get added in both cases.

I've just merged the changes of @Macrura.

We should work on a project together then and combine what we've learned so far. Can use git and all that fancy stuff that I still don't understand

Hi there @bernhard. This totally makes sense I didn't think about that I can already use the $user-> methods in this context. Awesome! I got tracy debugger installed, I just have to bring myself to use it more often Thank you a lot for the help, it is very much appreciated.

It is possible to merge the two to your advantage. I have not find a thorough guide/tutorial/example-site for this though. I am missing the experience too so I am slowly learning ProcessWire tiny bits-by-bits every day. At least I'm enjoying it We are in the same boat in this area

Just one more thing. Personally I will not give a damm about the guidelines you linked to. I want to adhere to standards only. If Apple (aka Jony Ive) wants to cut off part of my design then it is his choice. I will tell my clients that it is Apple's fault. They should stick to industry standards but they deviated. I'm strong with the Force in this Either way, it is good to know Apple has gone mad, thanks for the post!

Has there ever been a PW meetup? I know some of the other CMS guys do it. Organise a few days at a hotel with a meeting room. Get to chat with other developers, talk about the roadmap. See some presentations etc etc and examples of work.

hi roland and welcome to the forum, i read your other posts and i also see two options: 1) if you WANT to learn and are not afraid of writing some code you'll always find someone here that is willing to help 2) if you want a quick solution and stay in your (i quote you here and mean it bad in no way) "wordpress click click and boom ready" - world I'm sure you find a developer in the job-board that can help you

Do not forget that WordPress is click-and-play and can be easily pimped by googling around the web and pasting some hooks into functions.php. You can't beat that! WordPress is not even a CMS, by the way it is a blog engine with a nice GUI.

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.

This is a very beta version of the separate functions I use to generate srcset/bgset markups. There's some similar functions floating around in the forum but this one is a bit different because you can set "named image sets" which you can use easily site-wide. It's definitely work-in-progress so use it at your own risk. MarkupSrcSet Generate srcset and bgset markup for lazysizes. Features generate srcset/bgset markup for lazysizes set image sizes in JSON array add required JavaScripts automatically (optional) fallback to smallest image size if JavaScript is not available Usage Image sets JSON (in module settings): { "hero": [ [640, 210], [1080, null], [1920, null] ], "featured-image": [ [360, 240], 1.333, 2.667 ], "gallery-thumb": [ [240, 120], [480, 300], [800, 576] ] } Image methods $image->srcset(): <img <?php echo $page->featured_image->srcset('featured-image'); ?>> $image->bgset(): <div <?php echo $page->images->first()->bgset('hero'); ?>>Lorem ipsum</div> https://github.com/rolandtoth/MarkupSrcSet

Here is what I've made similar to this, using Table and Matrix modules, but the same could be achieved with the built-in Repeater too.

Sorry for the late reply; I have been on holiday for a while. This module acts only on changes to a Page Reference field - this is deliberate for reasons of efficiency. If you already have some Page Reference values in place before you start using the module on those fields then you can get things set up with a one-off API operation: // Get all pages where page_field_a is not empty $pgs = $pages->find("page_field_a.count>0"); // Get derefAsPage property of page_field_b to distinguish multiple/single page fields $deref = $fields->get('page_field_b')->derefAsPage; foreach($pgs as $p) { // For this page, get the pages selected in page_field_a $selected_pages = $p->page_field_a; // Standardise $selected_pages to PageArray in case of "single" field if($selected_pages instanceof Page) $selected_pages = $selected_pages->and(); foreach($selected_pages as $selected_page) { // Add this page to page_field_b on the selected page $selected_page->of(false); if($deref) { $selected_page->page_field_b = $p; } else { $selected_page->page_field_b->add($p); } $selected_page->save(); } } You can do a similar operation for page_field_b -> page_field_a if needed. Once you set up the Page Reference field pair in the module config then the module will take care of all changes from that point onwards.

Adding a 'class' attribute to an element is different to adding other attributes, you add either allowed class names or a '*' wildcard within parenthesis. // Allow *any* class name img(*) // Allow only specific class names img(align_left,align_right) // In your case (assuming any class name) it would be: a(*) Here's the CK Editor docs for Allowed Content rules: https://docs.ckeditor.com/#!/guide/dev_advanced_content_filter https://docs.ckeditor.com/#!/guide/dev_allowed_content_rules

@Zeka, that's a different method. That add() is for adding a new page to a specified parent and assigning it a given template. The add() @celfred is referring to is the WireArray method documented here and as seen here. It adds an item to the end of a WireArray (and its derivatives, e.g. PageArray). @celfred It shouldn't add without a save. There's something funky going on in your code. It's hard to pinpoint where because we can't see the original code. Maybe there's some other save or $real is being overwritten somewhere. I've tested your pseudo function and it works as expected in both PW 2.7 and PW 3.0.71. If I pass $real as false, the $page is not added to the Page Field. Btw, though made up, this variable name will throw an error $new-eq

Thanks for the tips, szabesz! Didn't see this post when you first made it.

Sorry, I mean a web dev outfit.

If the guidelines are anything to go by, the safe area would be the absolute maximum size that Safari would display a site.

just pushed another update! CAUTION: THIS HAS A BREAKING CHANGE since I changed how the settings get modified. the reason why i did this is that some settings can only be set BEFORE initialisation of the table. the customBorders is an example. you now have two events that you can hook into: beforeInit.rht afterInit.rht If you want to modify the settings before initialisation you can do this: // make custom borders $(document).on('beforeInit.rht', '.handsontable', function(e, settings) { $.extend(settings, { customBorders: [{ range: { from: { row: 0, col: 2 }, to: { row: 10, col: 2 } }, left: { width: 4, color: 'red' }}], }); }); after initialisation you can do this (similar to how it was before): $(document).on('afterInit.rht', '.handsontable', function(e, hot) { var colheaders = ['one', 'two', 'three']; hot.updateSettings({ colHeaders: colheaders, minCols: colheaders.length, maxCols: colheaders.length, }); }); now you can also add CSS files to your table by naming it like your field and saving it inside the /fields folder: #wrap_Inputfield_archimport .handsontable td:nth-child(2), #wrap_Inputfield_archimport .handsontable th:nth-child(2) { border-right: 4px solid #6c6c6c; } #importbutton { margin-top: 10px; }

Much better! I was gonna attempt to make a module that did this. Maybe I could adapt the module so skinning it would be easier i.e. a bunch of premade ones with added radio buttons in the module settings to choose skin. Food for thought, might get me into the modules game a bit, see how they work etc. Drupal had a great admin bar, much like the above. If a client is on a page, I see it as absolutely essential they have an edit link visible on that page. No way do I expect them to open a new tab, find the tree, find the page, click edit... bleeeurgh. An admin bar makes a lot of sense to clients, I've seen them use it. Thanks @adrian

@adrian - Thank you for your offer to help.... You know there are days I really like programming, then there are other days! This is one of those others. I moved the site from my local machine to our dev server so I could give you access. Guess what? When I did that the extra fields for language URL showed up!! Thanks again. Looks like we are all good now.

This exactly. Drupal had a module (can't remember the name) but when clients would log in, they would get a bunch of blocks like latest posts with EDIT/DELETE next to each etc. and stuff like that. They didn't see the proper admin at all. I'm quite liking the front end editing, as a user only needs to log in and then they can edit their pages right there on the page they're looking at rather than needing the admin area. I'm starting to learn how to build more 'user-centric' sites now and the big question I always have: 1) Do I provide a custom login form that goes to some kind of dashboard i.e. they never touch the admin area. Caveat being that the dashboard would need to let them upload images, edit content, basically do all the stuff they can do in the admin area anyway. OR 2) Let them use the standard login form (which is easily redirected to if a user doesn't have permission to view a page) and then use the page tree with strict user permissions, i.e. they end up with a 'tree' with about one branch (if editing their profile is all that's allowed). I'm finding it a bit confusing as I've never had the chance to see how experienced people do it. That's always the problem to a beginner. 10mins logged in to a pro site and you'd move forward so much quicker.

Let's do it! There is enough of us interested: https://weekly.pw/polls/ Probably in Finland as you have shown us Just kidding. But somewhere in Europe where most of us can drive or fly to "cheap".

To expand on what @AndZyk said - there are two parts to multi-language support in PW. The language packs you have installed are for translating the admin interface. If you want site editors to be able to enter content in alternate languages, then you need to create those languages under Setup > Languages.

Hello @SoccerGuy3, have you added a second language under "Setup => Languages" or have you just installed the language pack in the default language? You need to create a second language to use multilanguage. Regards, Andreas

You're in good company - we've all done that one

I might do that sometime when I have more time. On another note, I have just fixed the automatic backup of settings on module uninstall feature. Apparently it wasn't working properly Anyway, I think it's really useful so you know you can easily restore settings after an uninstall - very useful for some of the more complex modules out there.

I think a comprehensive doc would help greatly with new users or people on the fence. I know this has been discussed to death, but one place for the api/cheatsheet/tutorials with snippets/starting points would give first time users a confidence boost. I feel like I spend hours (if my project is large) googling and jumping between the references. It can be a bit disheartening at time. With all that being said, it doesn't seem to be "as bad" as when I was first starting out as I now have a better grasp on functions/the flow of PW. I have started moving away from granting access to the backend for in house projects, and instead, building "backends" on top of PW for them to use. I found it easier to give them only what they need to see than to have them getting scared of the page tree. I understand that PW is pretty much open ended and is only limited by your imagination, but maybe (dare I say) a template with the barebones for a dashboard/backend (perhaps with some ajax) built on top of PW could be helpful as well for new users. I know I still struggle with working ajax into projects and making something flashy, and examples always help (like live page listing refreshes etc). Understandably, this couldn't be a one size fits all, but it would be a great jumping off point for the newly initiated and make it more comfortable when granting access to the client or whomever the project is intended (Only intended if that workflow suites the project I know). The backend isn't such a scary place, but to whomever doesn't need all of the tree, could be nice. Well, I will end my ramblings, but thought I would throw my 2 cents out there.

Then your in the wrong place. PW doesn't work that way, PW doesn't have a frontend by default like other cms*, you have to build the frontend yourself. * it does if you use a site profile but those are mostly to showcase some features To understand pages read this https://www.smashingmagazine.com/2016/07/the-aesthetic-of-non-opinionated-content-management-a-beginners-guide-to-processwire/#three-simple-core-concepts https://processwire.com/docs/tutorials/but-what-if-i-dont-know-how-to-code/part-1-pages-templates-fields-files/

I think a theme refresh for the admin would make a big difference. Problem I have is I don't know how I'm gonna convince clients that PW is a better choice than WP. As in, off the top of my head: 1) They know WP, everyone talks about it, their mum told them it's amazing! 2) Themes. 3) When you leave, who's gonna take over their PW site long term? 4) They want extra functionality, you can't do it for whatever reason, who can? 5) I like the simplicity of the hierarchical tree in PW. So far, my clients have been a little confused because of hidden/unpublished pages. They think everything in the tree is on the site to view. In fairness, I may have missed a setting that makes these actually hidden from clients. For example, one page that needed to be in the tree, but also hidden (to stop it being in the main menu) was a settings template. Client needed access to it, but it had to remain hidden. 6) Loads of plugins (whether good or bad, the client knows they're available). And they haven't looked into how they are coded, and why would they? They think they can simply install it and get going (although the truth differs somewhat). 7) Images/docs uploaded per page, not centrally. I've never liked this so much, however there is a paid module for media. If there is a file download on two different pages, this is awkward for the user. They can't just open 'all docs' or something and just sling it in. 8) They think WP is free, as in, downtime after being hacked, decent plugins are paid, you need plugins to do things a proper CMS just has as standard... not so free really. Now I've really liked PW from the get go, but in reality, I can't see how I can avoid learning WP too. Literally all the web design jobs round here list the same requirements, HTML, PHP, CSS, JS/jQuery, Wordpress. I've spent a fair bit of time with PW and this really irks me. --EDIT-- So I just looked up how to make some basic custom fields, post types and custom menus in WP as a refresher. It made me sad. And made me think twice about going down that road.

I wish, I wish... ProcessWire had loooooots of @ryans behind it. As it stands, we all depend on him. As long as he is with us, all is good though...

I really want Processwire to take off and big a bigger player as it's my platform of choice.

Hi, Just do not forget: https://processwire.com/api/ref/wire-array/ Quote: "Nearly all collections of items in ProcessWire are derived from the WireArray type. This includes collections of pages, fields, templates, modules and more." Meaning if your WireArray/PageArray is sorted the way you need, you can just use first() to get the page. + one more tip: It is a bit ambiguous, isn't it? foreach($page->product_repeat as $repeater_item) { or similar (eg. $product) would be easier to follow.

@MrSnoozles Why not put the code in _func.php and use if statements? if($page->name == "page-name" && $input->post->submit) { // code to run on a specific page when form is submited } if($page->template->name == "template-name" && $input->post->submit) { // code to run on a specific template when form is submited } if($page->template->name == "template-name") { // code to run on a specific template }

Strange update: $pdf->save(); shows the images, but $pdf->download(); doesn't. Not sure what's going on here but I can work around that. Thanks, thomas

Just in case someone stumbles across this in the future - forceLogin() is now available (since 2.6.8): https://processwire.com/blog/posts/processwire-2.6.8-brings-new-version-of-reno-admin-theme-and-more/#new-session-gt-forcelogin-user-method-to-login-user-without-a-password

Okay, so I completely missed this the first time I was looking over $image configurations. $image->size($width, $height, $options)Return a new $image with the given dimensions. By default it will get upscaled and center cropped with a quality of 90%. To resize and keep proportions you can 0 for height or width value. As third argument you can pass an array to overwrite the default settings: $defaultOptions = array( 'upscaling' => true, 'cropping' => true, 'quality' => 90 ); If there was a 3rd option for cropping not to be center focused, and instead upward focused? or can I write one to be somewhere? So it would be nice if I could do a check for height, then if over a certain height I could do 'cropping' => upward or something.

Not technically a supported feature at present, but I think you can get the result you want. You'd take a query like this: $pages->find("body*=something"); and convert it to this: $pages->find("body.data{$user->language}*=something"); That should return just the pages that match the current user's language, rather than including the default language.