Leaderboard

Since there were no further replies I thought i might share my Ideas concerning "what would be a perfect frontend for the backend" from a technical point of view. Again: I started to code some stuff, took a step back and thought it would be interesting to get some input on my considerations first. This list is not meant to be complete but only a preliminary result of my current thoughts: What could be improved on the current technical setup of the backend? Modularity Not only PHP but CSS as well as Javascript should be modular. To do this "right" there should be some considerations about how things are structured and the way modules inject their assets into the system: Modular Javascript: My proposal is to use a module based javascript loading technique. Until EcmaScript 6 modules will finally have a broad support in the majority of browsers the way to go here would be UMD (or namely require.js). There would be several benefits from using this kind of loading technique: The Global Namespace would be much less polluted, Scripts would only be loaded when they are needed and multiple files can be loaded in parrallel. Furthermore there this technique ist "non blocking". This means: While loading scripts the browser continues rendering the frontend without having to wait for all assets to be completed. The core modules could be combined into a single file to minimize requests and speed up the application even more. Modular CSS: From my point of view an OOCSS Architecture (BEM, SMACSS to name a few) would also give us several benefits. Current modules often have to fight a "!impoprtant war on specifity" with core components due to the fact that there are several pretty specific selectors. This could be eliminated by using a flat, object oriented, reusable set of classes that can be extended. To give an Example of this here is some CSS from the default theme: .PageList .PageListItemOpen > a.PageListPage { color: #000; background-color: #ffffdd; } in BEM Syntax this would be: .pagelist__item--open .pagelist__page { color: #000; background-color: #ffffdd; } To alter this and avoid more descandant selectors you just add another class of .pagelist__page--myfunkyalternation and thus can see by the name it's a changing the page element. Modular "External Frontend Components": I personally like using bower to manage external frontend ressources. It really simplifies the way of downloading and updating them. There are some things to consider when it comes to structuring them, though. Performance Not only the "frontend" part of the Website / App you're about to build should be fast. There is a huge demand for responsive backends not only when it comes to displaying and using them on mobile devices. Most people that left the ModX community (and i'm sure there are others facing the same problem) did this because of it's sloppy and slow backend. While the processwire is stunningly fast now, there are always some things to tweak and optimize On a sidenote: There has been quite a buzz about this in the last couple of months (as mentioned in this thread) which could also help market PW and "ride this wave". Btw: My co-worker just sent me the link to a standalone PHP asset optimisation & manipulation library. This fits in here quite well: http://mun.ee/ Accessibility This is also a huge one. Modern Applications should be as accessible as possible. Consequent usage of WAI-ARIA, meaningfull / semantic Markup and a bunch of related a11y techniques would make the backend more accessible for people with disabilitys. This is also a "Killer Marketing Criteria" as most western governments and their organisations have to put a special focus on choosing software that is accessible for anyone who works with it. Currently there aren't many (Open Source) CMS which match these criterias well. Testing There should be (frontend) tests for all crucial core components. This is also something which can be used for marketing when it comes to CTOs making decisions about whether to use a system or not As stated above this list isn't meant to be complete (i didn't mention grunt which is awsome for simplifying some of the above tasks for example!) and subject to be changed and updated with great Ideas from the community which are missing until now. Having said that: Your Feedback is greatly appreciated!

Felix, thanks for taking the time. Tools, devices and standards are such a moving target that it's easy to fall into analysis paralysis. One of my favorite things about PW is that it doesn't assume you will use a particular frontend solution so I'd say the "perfect frontend for the backend" is one which can be replaced. For being able to work at a wide range of scale and withstand changes in the web environment simplicity often wins out. If we throw enough problem solving tools at a problem don't we create a new problem? Will Bower, for example, be your favorite front-end package manager six months or a year from now? Will it be a pain to change it out? I think Ryan's been smart to leave frontend up to the developer and to strive for admin pages that support anything you can come up with in PW, even if that means less then optimal user friendliness. Yes, I'd love to have slicker admin tools. That would make my work more pleasant and with some tuning and configuring could be great for clients to use. If we're going in that direction perhaps the goal should be to have PW core stick to having a spartan (I mean that in a good way) but robust and scalable admin interface, which supports but does not require the modernized, design-oriented, slick, next-generation, fun to use thing we all seem to want. Contributed modules and themes extend the present PW admin and I think we should retain that option but perhaps what Felix and others are getting at is a third thing. Not the public face of a site and not the nuts-and-bolts technician's access panel, but something with aspects of both. A third thing, which depends heavily on frontend which in PW is an application specific developer decision, not something baked into the framework. That's a strength of PW. The admin pages are an exception but let's not drag too much decor into that toolbox. How about doing this third thing as regular pages hidden and protected by roles and permissions? Sealed with a KeepItSimpleStupid.

@Marty: I do this by using a module. It's a copy from somas PageListShowPageId. the PHP code is public function init() { $this->addHookAfter('ProcessPageListRender::getPageLabel', $this, 'addPageArchivnummerLabel'); } public function addPageArchivnummerLabel($event) { $page = $event->arguments('page'); if('album'==$page->template) { //$event->return = str_pad(count($page->images), 3, '0', STR_PAD_LEFT) . " " . $event->return; $event->return = $event->return . ' <span class="jhpPageListArchivnummer">' . $page->archivnummer . '</span> ' . ' <span class="jhpPageListImageCount">' . count($page->images) . '</span>'; } } and the CSS is .content .PageListItem > a span + span.jhpPageListImageCount:before { content: 'count: ' !important; } .content .PageListItem > a span + span.jhpPageListArchivnummer:before { content: '' !important; } .content .PageListItem > a span + span.jhpPageListImageCount, .content .PageListItem > a span + span.jhpPageListArchivnummer { font-size:0.9em; background-color:#EEE; color: #777; padding: 2px 5px 1px 5px; border: medium none !important; border-radius: 3px 3px 3px 3px; }

Greetings Everyone, ************************************************* ************************************************* EDIT NOTE: This post started as a work-in-progress discussion as I was working out the elements of a successful form. After contributions from participants in this discussion, the code below has been tested and works well. You can use the code as shown below in your ProcessWire templates! Feel free to follow up with additional quesations/comments! ************************************************* ************************************************* I have successfully built front-end forms with ProcessWire to add pages via the API. It works great -- until I had to include image uploads along with the "regular" form fields. Then it temporarily got a bit complicated. In this discussion, I show how to handle front-end submissions in ProcessWire with the goal of allowing us to create pages from custom forms. I then go a step further and show how to use the same form to upload files (images and other files). I'm hoping this discussion can illustrate the whole process. I know a lot of people are interested in using ProcessWire to do front-end submissions, and my goal for this discussion is to benefit others as well as myself! First, here's my original contact form (no file uploads): <form action="/customer-service/contact/contact-success/" method="post"> <p><label for="contactname">Name:</label></p> <p><input type="text" name="contactname"></p> <p><label for="email">E-Mail:</label></p> <p><input type="email" name="email"></p> <p><label for="comments">Comments:</label></p> <p><textarea name="comments" cols="25" rows="6"></textarea></p> <button type="submit">Submit</button></form> And here's the "contact-success" page that picks up the form entry to create ProcessWire pages: <?php // First, confirm that a submission has been made if ($input->post->contactname) { // Save in the ProcessWire page tree; map submission to the template fields $np = new Page(); // create new page object $np->template = $templates->get("contact_submission"); $np->parent = $pages->get("/customer-service/contact-us/contact-submission-listing/"); // Send all form submissions through ProcessWire sanitization $title = $sanitizer->text($input->post->contactname); $name = $sanitizer->text($input->post->contactname); $contactname = $sanitizer->text($input->post->contactname); $email = $sanitizer->email($input->post->email); $comments = $sanitizer->textarea($input->post->comments); // Match up the sanitized inputs we just got with the template fields $np->of(false); $np->title = $contactname; $np->name = $contactname; $np->contactname = $contactname; $np->email = $email; $np->comments = $comments; // Save/create the page $np->save(); } ?> This works great! After submitting the form, we go to the "Success" page, and new submissions show up in the ProcessWire page tree right away. Excellent! Now I need to add a photo field. I altered the above form so it looks like this: <form action="/customer-service/contact/contact-success/" method="post" enctype="multipart/form-data"> <p><label for="contactname">Name:</label></p> <p><input type="text" name="contactname"></p> <p><label for="email">E-Mail:</label></p> <p><input type="email" name="email"></p> <p><label for="comments">Comments:</label></p> <p><textarea name="comments" cols="25" rows="6"></textarea></p> <p>Click the "Select Files" button below to upload your photo.</p> <input type="file" name="contact_photo" /> <button type="submit">Submit</button> </form> And here's the updated "contact-success" page: <?php // First, confirm that a submission has been made if($input->post->contactname) { // Set a temporary upload location where the submitted files are stored during form processing $upload_path = $config->paths->assets . "files/contact_files/"; // New wire upload $contact_photo = new WireUpload('contact_photo'); // References the name of the field in the HTML form that uploads the photo $contact_photo->setMaxFiles(5); $contact_photo->setOverwrite(false); $contact_photo->setDestinationPath($upload_path); $contact_photo->setValidExtensions(array('jpg', 'jpeg', 'png', 'gif')); // execute upload and check for errors $files = $contact_photo->execute(); // Run a count($files) test to make sure there are actually files; if so, proceed; if not, generate getErrors() if(!count($files)) { $contact_photo->error("Sorry, but you need to add a photo!"); return false; } // Do an initial save in the ProcessWire page tree; set the necessary information (template, parent, title, and name) $np = new Page(); // create new page object $np->template = $templates->get("contact_submission"); // set the template that applies to pages created from form submissions $np->parent = $pages->get("/customer-service/contact-us/contact-submission-listing/"); // set the parent for the page being created here // Send all the form's $_POST submissions through ProcessWire's sanitization and/or map to a variable with the same name as the template fields we'll be populating $np->title = $sanitizer->text($input->post->contactname); $np->name = $np->title; $np->contactname = $sanitizer->text($input->post->contactname); $np->email = $sanitizer->email($input->post->email); $np->comments = $sanitizer->textarea($input->post->comments); $np->save(); // Run photo upload foreach($files as $filename) { $pathname = $upload_path . $filename; $np->contact_photo->add($pathname); $np->message("Added file: $filename"); unlink($pathname); } // Save page again $np->save(); ?> <p>Thank you for your contact information.</p> <?php return true; } else { ?> <p> Sorry, your photo upload was not successful...</P> <?php } ?> Replace the field references with your own field names, make sure to change the various paths to match yours, and change the various messages to be what you need for your project. Read the entire discussion to see how we worked through getting to the solution shown above. Thanks, Matthew

As some of you might have noticed recently there has been a large "Frontend Performance Talks Offensive" (not only) by Google Engineers. Here are some high quality (regarding content) Videos which i enjoyed very much and thought you also might be interested in. A Rendering Performance Guide for Developers by Paul Lewis: Performance Tooling by Paul Irish Your browser is talking behind your back by Jake Archibald Gone In 60fps – Making A Site Jank-Free by Addy Osmani http://addyosmani.com/blog/making-a-site-jank-free/ Any suggestions for more interesting performance related stuff are welcome!

Diogo's right of course, there's already front end stuff in the admin but it's fairly conservative. Separation of duties between the core admin and a more frontend focused fancy tool could allow the core admin to be even less dependent on third party tools, the ebb and flow of UI trends, etc. I'm not taking a Luddite stance, I'm just thinking that anything so cutting edge as to be like Felix said, "applying all possible developing and design good practices" will forever be in Beta but we'll always need a stable, solid, easy to support and troubleshoot admin tool. These are two different requirement sets. Felix, it sounds great and I don't have anything against the tools. I brought up the observation about PW leaving frontend out of the framework (which we both like) to support my reasoning which goes something like... Admin pages with state of the art bells and whistles have lots of frontend. Frontend is not baked into PW, for good reason. Therefore this new cutting edge admin thing should not replace the standard PW admin system we depend on. Having it separate would take some feature creep pressure off of Ryan. Standard admin could be as "pure" and failure proof as possible. By separating these two admin interfaces they are each freed from having to meet criteria which pull in opposite directions. (fixed a typo)

$lalias = "the-name-of-the-page-in-english"; $english = wire("languages")->get("english"); $lalias_name = wire("sanitizer")->pageName($lalias); $page->set("status$english",1); $page->set("name$english",$lalias_name); $page->save();

The database is structured to be easily queried by the API and not to be queried directly. So, even if you can do it, I'm pretty convinced that you can do 99% (not only simpler cases) of what you will ever need by using the API.

SteveB, lett's not forget that PW already uses jQuery and jQuery UI on the backend, and now even SASS, so it's already making some —also probably questionable— choices there, and I don't think Felix's choices are necessarily heavier. I completely agree with Felix that a tool for web developers should give the example of excellence in web developing by applying all possible developing and design good practices (let's not fall in the same mistake as Textpattern that used tables on the backend layout until very recently, or is it still like that?).

Hi bracketfire, welcome to PW. You can go "all in" without any concerns, and use the API without even thinking of the database. The API is very efficient when bootstraped, and It's this easy: include("/path/to/processwire/index.php"); $address = wire('pages')->get("/location/")->address;

Actually you need both of these, urlSegments to render those pages on a different level, and the hook is just to conveniently modify the path (esier than manually createing them). I don't see where duplicated content is a problem. EIther use canonical urls, or take care of it with a redirect or some hooks. But if you never have links to those (real locations) you won't have them visible anyway.

I'm interested and always reading and watching everything about front-end performances and related tools. Thanks for posting them (and keep up the good work on the new admin interface...let's code it and make us play with it )

Ok, good starting point, thanks so far! However, I think (also because of duplicate content) this approach is not the best. After a bit of research I found the perfect solution. Using a simple hook does the trick: http://processwire.com/talk/topic/1799-routes-and-rewriting-urls/?p=16708 wire()->addHookAfter('Page::path', null, function(HookEvent $event) { $page = $event->object; if ($page->template == 'account-profile') { $event->return = '/'.$page->name.'/'; } }); Anyway, thanks for the fast support and explanation! Cheers, Yannick

I did not read the article but I guess it states how horribly wysiwyg editors screw up page designs, by code and in a visual way (because clients get too "creative"). That's exactly why this thread was created and there is some interest in it. To give the client a guide, within specific constraints (created by the designer/dev) to layout the page. If this goes well, a wysiwyg is not even necessary anymore. So it actually solves the problem you might see.

I've build the texformatterImageInterceptor, but i've never used it. I just don't like images inserted in WYSIWYG. LIke a lot of people here.

Dear Adrian, and All, I believe it was one of the load balancers. I had two, one for HTTP, and one for HTTPS. Rackspace just told me that the HTTPS load balancer doesn't support cookie based session persistence. When I was logged into the admin, I wasn't using SSL, which is why it worked. After repointing the domain to the server directly, and bypassing the load balancers, the front end app worked. I'm using SSL on the entire app because it's a business app that needs to be secure. So now I have to work with Rackspace to see if I can use a load balancer with SSL and cookie persistence. If I can't... well, there goes the load balancer. It was just an "IP" convenience anyway, since I wasn't load balancing the logged in sessions. Very interesting... one learns more every day, one hopes. Peter

Hey horst - I guess I am a bit confused about how the img tag is being generated. I just looked at Joe's code again and see that he is not replacing existing width and height attributes, but inserting them regardless. What if they are already in the img tag? Tinymce is producing the tag in this format <img src width height />. In CkEditor it actually looks like it is not adding the width and height at all. Not sure if this is a bug in PW's enhancement of the insert image, or a problem in CK itself. Either way, if you are relying on code generated by an RTE, I don't think you can assume that there will be no width/height or the placement of them in the tag. Maybe I am not understanding how the img tag is being generated in the first place

If you use a image with width(150) you also have to call for that variation width and height: $changed_content = str_replace("<img ", "<img width='$image->width(150)->width' height='$image->width(150)->height' ", $changed_content);

Hi yckart, I guess you are using the basic siteprofile that comes with PW per default. Following is the code of the home-template file. It is located under /site/templates/ and is named home.php. I have added a check for the url segment and the code you need to output a user page, whereas the original code of the home-template completly goes into the else-part: <?php /** * Home template * */ // first lets check if we have a urlSegment1 if( ! empty($input->urlSegment1) ) { // we have a url segment and want to get the page for it // we use ->get() for this, because get returns a single page, whereas ->find() returns an array of pages // but as we use the unique name of the users pages, there only can exist one page with that name $userpage = $pages->get("/users/{$input->urlSegment1}/"); // lets check if we have got a valid page // if PW hasn't found a page, it returns a nullPage and that has always a id 0 if($userpage->id == 0) { // we have no valid page, lets throw a 404 exception throw new Wire404Exception(); } else { // we have a valid page, so lets output the complete users page echo $userpage->render(); } } else { // if there is no url segment, output the homepage include("./head.inc"); echo $page->body; include("./foot.inc"); } This template will work if you use links like "/userpagename/" userpagename is the content of the namefield of your user page. If you have a page /users/foo-bar/, you can call it /foo-bar/ and it will be rendered, if you use /fooBaz/ you will be redirected to a 404 page, and if you call / you go to the homepage. But you also can access the user pages with there native urls: /users/foo-bar/. Hope that helps.

Well. Even if no one seems to be interested i'll keep updating this if i stumble upon interesting links. Maybe this will help someone in the future Here we go. How to prioritize visible content: http://www.feedthebot.com/pagespeed/prioritize-visible-content.html

Strangely, i too have developed a great fondness for rsync as "it just bloody works !!" Have downloaded that app you linked to @alanfluff and will have a play. Perhaps its a good baby step towards learning how to use all those rsync options in the man pages? Shall see... Speaking of which, I found this to be a really great and accessible link / reference to all the unix commands on a Mac: http://ss64.com/osx/

I really love rsnapshot: http://www.rsnapshot.org/ It is still command line and uses rsync, but handles all the incremental backup setup for you. Just setup and call from cron!

Spex is official now, I've added this to the modules directory =)

Top graph is posts made per month, bottom is cumulative over the same time period. Nice! It's not gone vertical on the cumulative posts, but that's fine as I'm still many pages of unread posts behind where I'd like to be

I had a click while reading this post http://processwire.com/talk/topic/4642-keeping-a-page-in-a-fixed-position-last-in-the-sorting-order/ and quickly implemented something I was thinking about for some time already. I added a new functionality on the DEV version. Now the module allows to easily create a "settings" kind of page. Putting it simply, you can create a tab in the admin that shows the "edit" page of that same page. See it for yourself https://github.com/ocorreiododiogo/pw-admin-custom-pages/tree/dev edit: for those interested on how it works, don't look on the module file, look on the admin.php file.

Yes, it is possible of course. It would look more or less like this: foreach($pages->find("template=person") as $p){ $timeAgo = date("Y") - $p->year; echo "<p><span>{$timeAgo}</span> YEARS AGO - on {$p->weekday} {$p->day} {$p->month} {$p->year}</p>"; echo "<p>(+) {$p->occupation} {$p->lastname} originally {$p->original} aka {$p->alias}, is born in {$p->city}, {$p->country}.</p>"; } Dealing with dates in your case won't be easy because you can't use unix timestamps (starts in 1970). That's why I chose to have all the details from the date in different fields. There might be better ways to deal with this of course. You can also import the database by exporting the database to csv and importing it to PW. This module is great for that http://modules.processwire.com/modules/import-pages-csv/. You will have to plan carefully and build all the structure in PW before.

For those working with pagination and several urlSegments. This seems to be pretty bulletproof: $currentUrl = $page->url.$input->urlSegmentsStr."/"; $pagination = $results->renderPager(array('baseUrl' => $currentUrl));

Hi kp52 and welcome. Nice to read from you here check this out for more boost. COMING FROM MODX ? Link2: A MODX refugee: questions on features of ProcessWire http://processwire.c...of-processwire/ Link3: Code comparison between modx and processwire. http://processwire.c...ge-2#entry30349 PROCESSWIRE CMS INSIGHTS Link1: Very good case study from RayDale giving good insight in processwire http://processwire.c...a-a-case-study/ Link2: Symphony or Processwire ? Another good insight. http://getsymphony.c...s/thread/79645/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Find more boost in these useful collected posts here: http://processwire.com/talk/topic/4173-grouped-forum-posts-links-articles-tutorials-code-snippets/

If you can wait, I'm currently working on a booking module for ProcessWire Currently it has specific needs for a specific job, so allows bookings on non-consecutive days, but will have consecutive days as an option by the time I'm finished (more useful for accommodation then). One thing I would say is that a restaurant booking system and a room booking system have very different needs. Both have been at the back of my mind when developing this module, but I need to look into the options required for a restaurant booking system when I get further along with this - the links in the first post here are helpful for that. There are some other nice features I don't want to give away just yet, but it might be worth waiting if you can for a few weeks.