Not sure what to do next.

I still have another few weeks before everything is done done but I'm getting closer to having no outside projects to work on.  I'm not sure what I want to focus on next.

I think I put the final touches on the Grease Rag website yesterday and today, so hopefully that one will be going live here in the next few days.  There were a few things that came up during training that I didn't have working that I fixed, the biggest one was figuring out how to do draft pages.  There really isn't a concept of this in concrete 5, a page is either a page or it isn't a page, there's no maybe about it.  I guess composer pages are a different kind of page but they are still pages I think, I haven't looked at that part of the code too much.  But I didn't have a way to specify draft or non draft.  I also apparently wasn't looking at the flag in the Wordpress import script so a lot of pages that should have just been drafts were showing up in the feed of the site which also wasn't good.

I took a look at how they do it in Pro Blog since that's basically what User Blogs is based on and it uses a feature I wasn't really aware of on the page model.  You can set active or non-active on any page like this:

  1. if($this->post('draft')=="1"){
  2. $p->deactivate();
  3. }else{
  4. $p->activate();
  5. }

This sets a flag on the page in the database that completely suppresses it from page search, page lists and autonavs.  This effectively removes the page.  It's even gone from the site map.  No trace of it exists at all.

That might pose a little bit of a problem, though if you think about it.  Once the page is set to draft mode you can no longer see it so you can't navigate to it and you can't edit it.  Unless you have copied the URL you wouldn't be able to edit the page again.  There are several 'ghost' pages in the system now that were drafts in wordpress.  These ones weren't posts so they weren't sorted in with the rest of the blog, but the actual pages themselves were there and just invisible.  I figure this is livable, they won't cause any harm by being there in the database.

This turned out to be pretty easy to get around.  In our custom page list we are filtering by date public, to make sure that no future posts show up.  This seems like a good place to hook in and make our check - if our user is logged in then we will show them posts that are scheduled in the future and posts that are in draft status (both future and past drafts.)  This is pretty simple to accomplish, there's a method built into the page list object for enabling disabled pages just like the ones that we are saving as drafts.

  1. $u = new User();
  2. if (!$u->isRegistered()){
  3. $pl->filterByPublicDate(date('Y-m-d H:i:s'),'<=');
  4. } else {
  5. $pl->includeInactivePages();
  6. }

By default concrete 5 page lists do not filter by date public, neither do autonav blocks.  So we don't need to specify a filter at all for date if the user is logged in and they will see all posts.  The includeIncactive() function includes our draft copies as well.  In a more complicated scenario you might want to have this be only a group of users or users with edit access to the page list, but the concept is the same.  This code is in the getPage() function of our User Blog List block. 

After that was worked out I had to modify how the block caching worked.  I hope I have it working properly, there has to be some pretty heavy caching going on on the site or it responds too slowly to grab the metadata tags when you share to facebook.  Not good.  I think I might be able to clean up some of the code and maybe make some helper functions for doing things like outputting the author details and post tags and stuff but I'm not sure how much I can do.  There's just a ton of information that you have to grab for each post, especially generating out the links to the categories and archive pages.  Still even a few seconds helps so I'll probably end up going back to the code sometime soon and trying to refactor it.

  1. protected $btCacheBlockRecord = true;
  2. protected $btCacheBlockOutput = true;
  3. protected $btCacheBlockOutputOnPost = true;
  4. protected $btCacheBlockOutputForRegisteredUsers = false;
  5. protected $btCacheBlockOutputLifetime = CACHE_LIFETIME;

I think what I'm doing there is caching it for everyone but the registered users who are the blog editors.  It seems to have sped up the site enough that sharing works again which is the main goal. 

After that the next thing to work out was search results - you could still search the site from the front end and return pages that weren't actually published to the blog yet.  Not ideal, but that's how concrete 5 works out of the box because it doesn't pay any attention to the public date.  You can use advanced permissions and timed release settings to control precisely when the page content is available to any group of users but that's not the collection date public.  I don't know why this is, it's just the way it's always worked.  I don't think it's really come up on many of the sites that I work on because none of them really blog at all, so they don't schedule stuff in the future.  They do a lot of scheduling of posts on the Grease Rag blog so this was a feature that needed to work really well. 

I first off today at work just went into the view and did a quick check to see if the user was logged in or not and then filter by date public but when I got home after work today and started blogging about doing this I realized this was the wrong way to do this.  What I really needed to do was go into the controller of the search block and do the check there.  The reason for this is so that the filter is on the search results before pagination, then you get accurate pagination of the search results. 

I copied all of the files from the /concrete/blocks/search/ directory to my outer /blocks/ directory and then added this to the do_search() function in the block.

  1. $u = new User();
  2. $showFuturePosts = $u->isLoggedIn();
  3. if (!$showFuturePosts){
  4. $ipl->filterByPublicDate(date('Y-m-d H:i:s'), '<=');
  5. }

This keeps any of our non-blogging users from searching for future posts but lets our bloggers find them.  This seems to be the best behaviour I could have. 

Nowhere in the autonav do you ever see a blog post page so I didn't have to try and patch autonav.  That probably would have been a pretty similar process if I had to do it. 

I also had to patch Scott C's Items Calendar, though that one isn't actually user login enabled. In the file /libraries/all_calendar_event.php I updated the createFromPage() function to make sure that the page is actually public and not scheduled in the future.  The actual time that it displays on the calendar is irrelevant, that is set with attributes. 

  1. $datePublic = strtotime($p->getCollectionDatePublic());
  2. $now = strtotime("Now");
  3. if ($now < $datePublic){
  4. return;
  5. }

I also updated the Items Calendar to be exclusive by default.  I made an attribute "Include In Items Calendar" that must be checked to enable a post being shown on the page.  By default the way it comes from the marketplace it's inclusive - if you say include all pages underneath a page or of a certain page type then it will include all of those pages regardless of whether or not they have valid attributes set for the calendar.  I knew that it would be possible especially when merging in page type associations to have pages that shouldn't be on the calendar included.  So I modified the class ScottCCalendarEvents in the file /models/calendar_items.php to use a page list instead of $c->getCollectionChildrenArray() in the getEventsByParentPage() function.  I also modified the way the page list is filtered in the getEventsByPageType() function by filtering by our new Include attribute.

  1. function getEventsByPageType($ptID){
  2. Loader::model('page_list');
  3. $pl = new PageList();
  4. $pl->displayOnlyPermittedPages(true);
  5. $pl->filterByCollectionTypeID($ptID);
  6. $pl->filterByAttribute('scottc_items_calendar_include_item_calendar', 1);
  7. $result = $pl->get();
  8. $arr = array();
  9. if(!empty($result)) foreach($result as $pageObject){
  10. //print "eaching page objects in get events by page type";
  11. $ace = new AllCalendarEvent();
  12. $event = $ace->createFromPage($pageObject,$type = 'page_type');
  13. if(is_object($event)){
  14. if(is_array($event->calendarEvents) && count($event->calendarEvents)){
  15. foreach($event->calendarEvents as $e) $arr[] = $e;
  16. }
  17. unset($ace);
  18. }
  19. }
  20. return $arr;
  21. }
  22. function getEventsByParentPage($pageID){
  23. $p = Page::getByID($pageID);
  24. Loader::model("page_list");
  25. $pl = new PageList();
  26. $pl->displayOnlyPermittedPages(true);
  27. $pl->filterByParentID($pageID);
  28. $pl->filterByAttribute('scottc_items_calendar_include_item_calendar', 1);
  29. $result = $pl->get();
  30. $arr = array();
  31. if(!empty($result)) foreach($result as $pageObject){
  32. $ace = new AllCalendarEvent();
  33. $event = $ace->createFromPage($pageObject, $type = 'parent_page');
  34. if(is_object($event)){
  35. if(is_array($event->calendarEvents) && count($event->calendarEvents)){
  36. foreach($event->calendarEvents as $e) $arr[] = $e;
  37. }
  38. unset($ace);
  39. }
  40. }

I still need to merge some of these changes into the site for Occupy but it basically finalizes the last few things that needed to happen to make the system functional.  So I think it's pretty much ready to deploy.

Next weekend I'm spending mostly working on the website I'm doing in trade for by brother and his wife to pay their doula.  That should be a simple little project to code up, then hopefully not too much time to deploy and set up.  I'm hoping that everything will go smoothly but she's hosting with GoDaddy and I've heard some bad things about getting concrete 5 working on their servers.  Hopefully that's in the past and rectified by now. 

After that it's mostly finishing up a few loose ends on Occupy but I can't really finish those until I can actually meet with the group again and get some answers on things.  I don't know how to set up the forums or what the domain name should be, I need to know both of those to finish setting everything up.  They didn't have a meeting this week because they were out doing the first test canvassing in Seward.  It sounds like that went really well, so hopefully this is something that is well received by the community which will mean people actually checking out the site and using it to post about whatever is important to them in that particular neighborhood. 

The only thing I might change on Occupy is making it so that you only see draft copies if you are the logged in user for a particular user blog page and looking at that page, not show them on the overall list or the location pages.  This is because the Occupy site is more of an individual publishing platform for a community where everyone has a voice but there are potentially hundreds of users who aren't actively collaborating on pieces toghether.  The people using the Grease Rag site do work on pieces together I think so it makes sense for them to see them on the main pages. 

It really shouldn't be this hard to do simple things in concrete 5 like use the collection date public to schedule posts in the future.

The draft status is a more difficult problem, concrete 5 does have a good version control system and you can approve or disapprove any page version pretty easily.  You can also set attributes to exclude a page that is in draft status from the autonav and page lists.  But the page still shows up in search I'm pretty sure.  I think what I'm doing here is probably the only way to reliably do it and that means using a non-standard page editing interface like User Blogs or Problog.

But yeah, now that the code base is stable I don't know what to move onto next. I've started a small freelance gig that will be giving me a few hours of work each week which will be nice but it's kind of piecemeal work and small stuff, adding in addons and making small tweaks to existing themes.  Nothing to get excited about but it's hopefully steady work and that will be nice.  Still it won't be filling up all the extra hours I have once I'm actually done and deployed with Occupy.

So what to do next?  I want to get out and do some bike touring but I know for sure that my legs couldn't handle it.  I need to do a couple loaded rides out to Stillwater packing a lunch and some rocks to build myself up to the point that I can be riding fully loaded all day on a camping trip.  So I guess I'm going to spend some time doing that.  I'm also starting a garden so some time is going to be going into that but it's going to be a pretty small garden and I don't forsee a lot of upkeep on it.  Maybe I'm wrong about that. 

Other than that I have no real plans.  There are a few ideas I've had for awhile to code up for the marketplace but none of them really appeal to me enough to actually take the time to code them up.  I'll still probably end up taking some time to code them anyway.  I wish I was better at coming up with ideas for the marketplace. 

Attributes Slider has been a good one so far though.  It's already sold 16 licenses and one developer license which I sold outside of the marketplace.  I'm not sure how if how I handled that is actually cool with the marketplace though, I might have to look into that and see if I'm in breach for selling outside. I sold the first license through the marketplace, just then allowed them to use it on all their sites.  That's actually what lead to the freelance gig as well.  I will probably post up in the leaders forum tomorrow asking if that was in fact cool or if I was breaking the marketplace rules.  Hopefully it's not in breach. If it is maybe they can add in an option for developer license to go along with the 5-pack. 

That's still nothing compared to backstretch.  Damn.  You don't think about it but that $15 dollars at a time adds up, I've sold 111 copies of that so far.  Nothing compared to my free add ons though - Herent Config Pages has 863 downloads and Vimeo a huge 6088. 

I don't think I'll be able to function without a project to work on for long though.  I'm probably going to get back into something that will be an involved process to make a huge site.  Probably it's going to be bikelove.org, at least trying to lay out what the road map is to get it constructed and start sending it out into cities.  How the business and non-profit entities need to be created and managed.  How funding can be found.  All sorts of things.  I wish I had better notes from when I was manic and did all of this before, I think I remember everything that's really needed.

blog comments powered by Disqus