Leaderboard

Playing around with the UIKit theme this morning and tweaking it. It's called UIKit Classic and it's a nod to the Classic theme. For me the Classic theme always sticks in my mind as being most definitively Processwire-ey because It was my fist intro to PW I thought the colours were quite unique and like the mix of blue, pink and green. They're very distinctive and I'd hate for PW to look like just another WP install. In a crowded CMS marketplace I think it's good to differentiate visually. The two screengrabs are just the same screen. A before and an after. I put this together using the Chrome the web inspect tool so there's no fancy mixins or LESS etc. Actually there's not even any CSS now that I've refreshed the page. I do think there needs to be a detailed comprehensive through tutorial for people wishing to make their own themes. Probably 85% here don't need it and understand the directory structure and how it's all compiled but equally I think there's another 15% here with the design skills but not the tech chops to get this done. If we want designers to design themes then we need the process with screengrabs, list of software (I have CodeKit, Dreamweaver, Sublime etc). Anywho - just my 2€ worth The before shot below...

You can renew any time. The auto-generated renewal invoices expire on their own after awhile (I think 90 days or thereabouts). So if you find you can't renew when you want to, just send me an email or PM and I can refresh it so that it'll work.

Another option which avoids the need to parse and modify the links on every frontend page load (as a textformatter does), you could just do it once when a page is saved. The example below (add to /site/ready.php) uses Simple HTML DOM as the parser: // Change 'body' to whatever your CKEditor field is named $wire->addHookAfter('Pages::saveReady', function(HookEvent $event) { $page = $event->arguments(0); // Return if body field absent or unchanged if(!$page->body || !$page->isChanged('body')) return; // Load Simple HTML DOM from site root require_once $this->config->paths->root . 'simple_html_dom.php'; // Create DOM from body field $html = str_get_html($page->body); // Get all the links $links = $html->find('a'); foreach($links as $link) { $href = $link->href; // For any link that is not relative and does not start with the site httpRoot... if(strpos($href, '/') !== 0 && strpos($href, $this->urls->httpRoot) !== 0) { // Set rel and target attributes $link->rel = 'nofollow'; $link->target = '_blank'; } } // Set the results to the body field $page->body = $html->save(); });

I have no idea why this isn't in the core, but if you are cloning, be sure to use this module: http://modules.processwire.com/modules/process-page-clone-adapt-urls/

The dashboard module definitely works well and saves a lot of headaches for me as far as interacting with clients. For some reason most of my clients have an incredibly hard time using computers. I have to make everything as simple as possible; The dashboard was the only way to accomplish this, e.g. allow users to interact with a complex website, with a lot of data, moving parts, etc, and make it where they can log in and within 1 click either be editing a new content item, viewing a list of content items, recent formbuilder entries etc. The module is dependent on several types of fields, like FieldtypeColor (for the color of the widget header bar), FontIconPicker, for the icon to use for shortcuts, and Selector field for setting up the custom mini-listers. The module requires about 13 fields and 2 templates, as well as 3 page tree branches to hold the widget types, shortcuts, and widgets themselves; it hasn't been easy to port the dashboard from site to site, but i have gradually been able to automate some of the process of creating fields and templates (using some methods in the module that read the json export of fields and templates), or have used the built in export/import of fields and templates, as well as the new pages import/export. This screenshot is a simple example from a testing instance of PW.

Ok, the order of items in the Dumps panel is now "normal", not reverse. The latest version also: 1) hides the PW Info panel if you click on one of the navigation icon links and also hides the Dumps Recorder panel if it's empty. 2) makes $input->get, $input->post, and $input->whitelist available to the Console Panel, so if you do: d($input->get->variable) you'll get the value of that get variable for the currently loaded page. These $input vars are already available in the Debug Mode Panel, but now you can use them programmatically in any code you might be trying to test in the Console Panel which I think can be very handy at times. Note that $input->urlSegments, $input->pageNum, & $input->cookie also work, but they always have.

Looks like @ryan has just put together a "Reno" colored version of the UiKit theme: https://github.com/ryancramerdesign/AdminThemeUikit/commit/25b6ac173b868a47ab90430e1d30efd8701f7ca0 Although I must admit that I would also like the version that @Peter Knight has shown above.

Delete past browsing and site data. The browser might have been caching redirects and you are being redirected to the same (incorrect) url even after the problem was fixed somewhere along the line. for Firefox: https://superuser.com/questions/467999/clear-301-redirect-cache-in-firefox for Chrome: https://superuser.com/questions/1166181/how-to-clear-cached-redirects-in-chrome

Lets discuss the new admin theme, there has been very little talk about it, a few questions about its status and some simple designs by a few users. Have you played with it? Do you like it? Do you dislike it? Of course I'm not talking about its design, but the way its structured, how it works and the features it offers so far. ------------------------------ I'm working on a purple color scheme for it and it turned out quite well (imo), but one thing I dislike is the use of iframes. I haven't used iframes before so it might be just me, but I'm struggling with them when it comes to javascript. When iframes are used all scripts are loaded in every frame, which can lead to unexpected results. Javascript is an easy way to add, remove, move etc. elements in the admin, but the iframes complicate things. What are your thoughts? Is it just me? Here's a screenshot of the purple theme:

Im still trying to see if I can duplicate your issue on my end, but I do see that an issue was created in June regarding the same thing: https://github.com/processwire/processwire-issues/issues/287 However, it does not seem like Ryan could duplicate it either. Ill keep testing, though hopefully someone else will have an actual answer for you.

I also would recommend to develop locally. I would go crazy if I had to wait a few seconds after every change. My deploying workflow is currently: Track all files inside site/templates with Git and push/pull them on the remote server via SSH. Sync all files inside site/modules and site/assets/files via Sublime SFTP or Transmit. Sync the database with Sequel Pro. But maybe some time I will try something fancy like a automated shell script.

OK, I tried out the code from @Robin S and it works perfectly! It's an incredibly powerful and elegant solution, especially since it works on page save instead of front-end load. Besides trying out a standard link, I also tested it out with actual affiliate links and banners, which are a lot more complex-looking than a standard link, and it worked perfectly. For anyone in the same situation as me who wants to use Robin's solution, you should remember to first un-set the nofollow and _blank link attributes in ProcessPageEditLink (i.e. don't have those in the two boxes in the pic I showed in the original post up top). Then, just do what Robin said. It all just works! I'll mark this as solved. Thanks again Robin S!

it should always be a pagearray when you get the unformatted value: // change this $items = $page->{$f->name}; // to this $items = $page->getUnformatted($f->name); then you don't need the additional "else" statement

I dont think it works like that. Being a repeater, FieldtypeFieldsetPage saves its content into pages under /admin/repeaters, and you cannot move them around like basic data types, as matching data is done using page names of the repeater items and its parent. You'll have to clone/move the repeater items to a new location and change their names accordingly. I haven't used the action from @adrian's module as per @bernhard 's recommendation, but it sounds promising.

Nice, glad you like it! I will consider this and probably change that - thanks for the feedback!

Put/replace <?php namespace ProcessWire; at the first line of the template.

If a client is dead-set on WordPress, it's worth communicating to them that every developer has their own go-to approach with the system, to the point where I would say it's not even "WordPress" anymore. So even if another developer were to take over it, it's still foreign territory to an extent, followed up with continuously saying "why the hell did the previous developer do things in X way instead of Y?" and a lack of productivity. Just check out all the starter themes, mega themes (ugh... ... ... ugh), and different approaches to custom fields. It's pretty terrible. For me, ProcessWire + UIkit solves like 95% of my challenges, and solves them WELL.

Awesome! I can see this being really powerful, and a nice alternative to working with hooks. What do you think about adding an option for using a file to define these settings? For anything but the briefest snippets I much prefer working in my IDE (version control, etc). It could be a checkbox to activate the file-based option, or just check if "field-overrides.ini" exists in /site/modules/AdminOnSteroids/.

I might be wrong, but my understanding is that the ACF/Purifier settings for a CKEditor field only affect content that goes through the CKEditor inputfield and is then saved to the database. A textformatter on the other hand never saves its changes to the database and it isn't involved with the inputfield - it just makes changes on-the-fly as the content is output to the front-end. Another thought: if you have multiple textformatters applied, check to see if the order they are applied makes a difference.

I've worked on the "CKEditor customizations" feature and finally decided not to restrict on CKEditor field only. It was refactored to a new submodule called "FieldOverrides". This way it is possible to set a bunch of field properties to override the defaults, in user, field or page contexts. Basically this is an extended version of the built-in field template overrides feature but for almost all field properties. Some examples of what is possible: As you can see the syntax has changed a lot and there are some new keys too. Syntax higlight works with InputfieldAceExtended and CodeMirror too, and in both cases the field auto-grows. CodeMirror uses files from the existing CKE plugins directory so the module's overall filesize hasn't grow much. @szabesz I don't have ListerPro so it's hard to check things. You say that If you turn ListerTweaks off it's still active?

If you or anyone else wants to make this happen, let me know. Possibly wait until I know Ryan's plans. I don't want to duplicate work or have several almost identical themes. ? I can supply raw css. Just need someone who knows Git, Less and has time to collaborate etc.

True. I always have to install a new copy and e.g. try out a new module first to see what is happening. Usually for a webshop. True also but making changes only is not so much work. Besides the local database would always be different and syncing might overwrite something online.

Yeah :(, it cant perform migration over SSH.

Once I took a look at it, I cannot recall why I was not impressed Never mind I was just curious, anyway. My bash script is half baked but it does the trick already. When finished it will be a lot more powerful. I already have one for WP now I just have to finish this one for PW...

Sorry if I may disappoint you, but by syncing with Sequel Pro I just meant: Export the local database and import it on the remote server. Nothing intelligent and of course it doesn't work on live sites where users made changes in the meantime. In that case I think the core import/export module would be the best option, but I haven't used it really yet.

Hmm, turns out MySQL offers a similar tool for migration https://dev.mysql.com/downloads/workbench/

This one. I do not have an extreme number to take care of. By working on local MAMP Pro clones I do not have to worry about breaking anything. Isn't it too risky to work on the production site without testing in advance?

If you're using PHPStorm, there's a sync feature that lets you diff between remote & local and sync differences automatically (other Jetbrains IDEs should have it too) https://confluence.jetbrains.com/display/PhpStorm/Sync+changes+and+automatic+upload+to+a+deployment+server+in+PhpStorm

@Peter Knight Personally I prefer CodeKit, but I would recommend you to use npm to compile the files of UIkit used inside the AdminThemeUIkit as described in the README. This is the recommended way to compile UIkit. As @fbg13 mentioned I also added my stylings in the pw.less. It is really easy to override the variables of UIkit to make it look unique.

I use a dead simple workflow: I use my own bash script to clone the database from production to local (and/or vice versa) via ssh. It takes only a few seconds. I just have to make sure all database related changes are performed on the production server. For testing purposes I occasionally make changes to the local database of course but I never sync any database data. Files are synced with this great and fast tool: https://www.scootersoftware.com/download.php When set up properly, all differences of all files are detected somewhere between 20-60 seconds, depending on the server and its location on the globe. This tool is incredibly powerful. By regularly examining the differences I have also learnt a lot about under the hood file changes made by the system. It is also very handy when upgrading and debugging.

That's awesome. Thank you very much!

medkit - ok thanks, wasn't sure which one! Yes, the module does do some of the field and template installation, however so many things have to be assumed, because around 5 of the fields are page reference, so there needs to be populated items in the tree to even setup those fields correctly; i know it can be done, but would take some interaction or module config settings; right now the module config does need you to specify the root of the widgets themselves; but the other fields, like the shortcut select needs a branch holding all of the shortcut definitions; also each widget has view access settings for user, role and permissions, and for some reason those fields are not being fully setup correctly through the api; i will try and get the current version up on github soon and see if anyone else can work on it; i was also considering how to not use any PW fields or templates and make the whole thing be configurable from the module settings.

That would score worse in terms of SEO, though. Having a homepage that immediately redirects is frowned upon. You cannot supress with urlSegments if the page already exists. From @ryan: https://processwire.com/docs/tutorials/how-to-use-url-segments/page2

I have a site in production with this Vue boilerplate. Indeed, I had problems with SEO and google took a long time to index all pages, I used https://prerender.io/ for indexing nested routes otherwise google wouldn't have been able to do so. It really depends on the type of app you're building, but if you can install node in the server you could use nuxt.js and in this way every route will be easily indexed. However you'll have to either build your REST API with node or connect to it with PW. If it is not managed by a client you can just use nuxt.js as is.

@Macrura please do it ! We are lazy and curious at the same time It is something based on ? :

There are probably many different ways to do this, but perhaps the easiest might be to make use of this module (or modify it to your exact needs): http://modules.processwire.com/modules/textformatter-mark-external-links/ This won't actually save the rel="nofollow" to the link in the database, but will instead add it to all external links when the link is rendered on the frontend.

It should be noted though that if you have the core notifications module installed you'll probably see the same thing, which is why I have this line in Tracy to prevent it being loaded by notifcations polling.

@justb3a, it's working now with the update to 1.0.5, huge thanks for your time and patience!

@Peter Knight you can take the theme module (wire/modules/AdminTheme/AdminThemeDefault) put it in site/modules and modify it to your needs.

I was expecting to find a method to hook before admin theme in the hopes that I could modify $config->styles, but unfortunately there's none. Here's how AdminThemeDefault uses it: // /wire/core/modules/AdminTheme/AdminThemeDefault/default.php $config->styles->prepend($config->urls->root . "wire/templates-admin/styles/AdminTheme.css?v=$version"); $config->styles->prepend($config->urls->adminTemplates . "styles/" . ($adminTheme->colors ? "main-$adminTheme->colors" : "main-classic") . ".css?v=$version"); $config->styles->append($config->urls->root . "wire/templates-admin/styles/font-awesome/css/font-awesome.min.css?v=$version"); $ext = $config->debug ? "js" : "min.js"; $config->scripts->append($config->urls->root . "wire/templates-admin/scripts/inputfields.$ext?v=$version"); $config->scripts->append($config->urls->root . "wire/templates-admin/scripts/main.$ext?v=$version"); $config->scripts->append($config->urls->adminTemplates . "scripts/main.$ext?v=$version"); ... <head> ... <script type="text/javascript"><?php echo $helpers->renderJSConfig(); ?></script> <?php foreach($config->styles as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; ?> <?php foreach($config->scripts as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> <?php echo $extras['head']; ?> </head> Here's how AdminThemeReno uses it: // /wire/core/modules/AdminTheme/AdminThemeReno/default.php // Styles $config->styles->prepend($colorFile . "?v=" . $version); $config->styles->prepend($config->urls->root . "wire/templates-admin/styles/AdminTheme.css?v=$version"); $config->styles->append($config->urls->root . "wire/templates-admin/styles/font-awesome/css/font-awesome.min.css?v=$version"); // Scripts $config->scripts->append($config->urls->root . "wire/templates-admin/scripts/inputfields.$ext?v=$version"); $config->scripts->append($config->urls->root . "wire/templates-admin/scripts/main.$ext?v=$version"); $config->scripts->append($config->urls->adminTemplates . "scripts/main.$ext?v=$version"); ... <head> ... <script type="text/javascript"><?php echo $helpers->renderJSConfig(); ?></script> <?php foreach($config->styles as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; ?> <?php foreach($config->scripts as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> <?php echo $extras['head']; ?> </head> There arent any method calls anywhere. BUT, with my SUPER hacky way, you can intercept the styles as they're added to $config->styles. <?php namespace ProcessWire; // /site/templates/admin.php class MyFileArray extends FilenameArray { private function intercept($filename) { if (strpos($filename, '/templates-admin')) return true; elseif (strpos($filename, '/AdminTheme')) return true; } public function append($filename) { if (!$this->intercept($filename)) { parent::append($filename); } } public function prepend($filename) { if (!$this->intercept($filename)) { parent::append($filename); } } } /** @var Config $config */ $config->styles = new MyFileArray(); require($config->paths->adminTemplates . 'controller.php');

I spent awhile trying to create something like this via a sign in form which then created a profile etc... but I'd put money on it the module does a better job than I could have done! Can't wait to give it a spin

Probably because the module is outdated by 2 years. Last commit was at Sep 7, 2015

Use Page Reference & Repeater fields. Seriously. They're immensely powerful if you know how to utilize them. There's a blog post that explains how you might use Page Reference fields for toggling states and attributes, but you can also use them for ordering things, as it saves the order of the pages you referenced too. What you should do: Create 3 dummy templates, "home-block", "container", and "block-type". You can use tags in Advanced tab and put "-home" to hide them away. Create the following pages /processwire (your admin root page) +---tools/ (template: container) (hide this page) +-home-blocks/ (template: container) | + hero (template: home-block) | + what-we-do | + our-work | + testimonials | ... other blocks | +-block-types/ (template: container) + full-width (template: block-type) + half ... other types Create a Page reference field, set its inputfield to select, limit to single item and only pages with "home-block" template under /tools/home-blocks Create another page field, this time set its inputfield to Checkboxes and limit it to "block-types" under /home/block-types Create a repeater homeLayout and add these two page fields to it Add the repeater field to home template. Add any block you want using the repeater in any order and add any property you want to any container. Using this blog post as your guide, loop over the repeater items and find which block has been selected, render your block (you can put your block codes under templates/block and render them individually with $files->render()) with the options in the order your client/you selected

I wasn't sure about replying because you are giving wordpress a lot of attention here. But reading your a) and b) I have my 5 cts worth it: That's what I thought also years ago until I learned otherwise. Bumping into a client who wants it done in wordpress: trying to convince a client doesn't work. I spent no longer than 5 minutes opening the door to processwire, then I leave my card and move on. There are unlimited small offices and businesses out there who still don't have a website. Not true. Have a look at the api of processwire. Any experienced coder will pick up the api of processwire in no time. Processwire is decoupled so nothing to learn on the front. Just pick any framework or code your own css. And that is exactly what I tell my clients: If I am not around anymore all you have to do is to find an experienced coder and your website will go on. Heck, I bet an experienced coder will pick up the api of processwire faster than wordpress.

Just for the record, in AOS you can easily add a WP-like page edit layout by adding enabling Add aos_column_break field to create admin columns tweak under Misc (and adding the aos_column_break field to your templates). The gutter between the columns is draggable.

$yesterdayEvening = strtotime('yesterday 21:00'); $todayEvening = strtotime('today 21:00'); $latest = $pages("<your selector>, created>=$yesterdayEvening, created<=$todayEvening"); http://php.net/manual/en/datetime.formats.relative.php

Why do you assume it isn't capable of different languages? The source code contains pretty much translatable strings like that: _('You have logged out') – the underscore indicates that it is translatable. What's missing now is the translation itself – feel free to chime in! Here is all you need

Hi @kongondo, I've been getting to know this module and it's really impressive the features you've worked in and all the settings that can be customised. Just wondering about the behaviour of the MM inputfield though - currently it reloads the whole of Page Edit with each addition to the field, which is not so good if the user has made some edits to other fields but not yet saved the page. They are faced with the option of accepting the reload which would lose the other field edits, or cancelling the reload in which case their media selection is not added. Maybe you could look at how the PageTable inputfield reloads itself via AJAX when a change is made, and do something similar with the MM inputfield?

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

You'll never see onboard instructions on a Formel1 car.