Jump to content

Pete Jones

Members
 View Profile  See their activity

  • Posts

    88

  • Joined

  • Last visited

 Content Type 

Posts posted by Pete Jones

    Database constraints and building an admin area

    in Dev Talk

    Posted

    Right, so let's just say we have a members area which holds all of the User/Horse/Payment details and a CMS. Is there a way in which we can have a single point of access for all this? We've been discussing perhaps a Laravel user/horse system and expose some JSON for the website area.

    What I don't want to to provide 2 'admin' system to the client. One for users/horses and one for the CMS.

    Database constraints and building an admin area

    in Dev Talk

    Posted

    We are currently looking at building a custom administration area with the basic outlined functionality. Users will be able to login and see their horses, their events and their payments. Admins will be able to login and see all users, horses, events, payments. Data structure below.

    Questions

    1) Would this make sense to build as a single frontend with different 'admin' levels' rather than customising the backend of PW? Ultimately the PW install will be running a full frontend website (showing Horses for Sale, Events and other misc content) so users will need to login to update content.

    2) How does PW handle database relationships? Could this structure be built?

    Users
    ------
    ID
    Email

    Horses - one user can own many horses
    -------
    ID
    UserID
    Membership Level (payment)

    Events - one horse can enter many events
    -------
    ID
    HorseID
    Required Membership Level

    Payments
    -----
    ID
    TransactionID

    Payment Items - one payment can have many payment items
    ----
    ID
    PaymentID
    Order Type - Horse Registration/Donation/Event
    ItemID - HorseID, DonationID, EventID
    Cost
    VAT

     

    Many thanks

    Pete

     

    ProCache omitting the body tag when minifying HTML

    in General Support

    Posted

    Quote

    Certain tags can be omitted.

    In my mind, the word can should be in bold here. Just because you can, doesn't mean you should. Omitting the <body> tag, whilst saving a couple of bytes opens a can of legacy worms. Older browsers will revert to quirksmode and Google Analytics 'prefers' analytics code immediately after the <body> tag. 

    The module is awesome, and has shrunk down the first site we built to be so quick, the web inspector barely keeps up, but this one seems like it should be optional in ProCache to help with legacy development.

    What do you think Andreas?

     

    • Like 2

    Downgrade from 3.x to 2.7 and using CroppableImage

    in General Support

    Posted

    Hi,

     

    We recently installed the 2.7/2 version with CroppableImage (which worked fine). We then upgraded to 3.X which broke CroppableImage. When you try to upload an image and then click on the crop button we get the following error message:

    Unrecognized path
    The process returned no content.

    We have since tried to downgrade the site back to V2.7.2 (fresh install and then copy over the existing database), but I still get the error. I assume this means a DB problem somewhere.

    Is there anything version specific stored in the DB that might need to be 'rolled back'?

    Improve performance of big query

    in General Support

    Posted

    Yes, I have noticed that renderPager() is giving more pages than needed. Before I look at that, there is a strange reordering happening. Take this pair of selectors: 

    $notes = $paginator(array(
		"template=horse-note, parent.h_type=2, h_notes_comments.count>0, h_notes_comments.$session->unread_by>0, sort=-h_notes_last_comment",
		"template=horse-note, parent.h_type=2, $session->unread_by>0, sort=-h_notes_last_comment"
	), $pageNum, $limit);

    One of the pages from the second selector is appearing first in the list. It's definitely coming from that selector, because if I remove that from the array, that page is no longer returned. All other pages seem to be in the correct order.

    I've also noticed that on page 1, where I am echoing out count($notes), this is returning 96 even though $limit is 100. It's fine on all subsequent pages though.

    Selector 'where all repeater items'

    in General Support

    Posted

    In reference to http://processwire.com/api/fieldtypes/repeaters/ is it possible to say 'where all repeater items' rather than 'where at least one repeater item' inside your selector?

    What I have is a repeater with a checkbox. I want to find pages where all repeater items on the page are checked or unchecked. If I do this: 

    $pages->find("my_repeater.my_checkbox>1");

    I get pages where at least one repeater item has the checkbox ticked, but what I want is pages where the checkbox is ticked in all of the repeaters.

    Improve performance of big query

    in General Support

    Posted

    Just stripping this back to basics so that I can prevent duplicates in my selectors and have noticed that the order is being controlled by the sort that I have in the selectors, rather than the order that the selectors are put into the $paginator function. That probably makes no sense, so I'll try to illustrate.

    My paginator function looks like this: 

    $notes = $paginator(array(
	"template=horse-note, h_notes_comments.$session->unread_by>0, sort=-h_notes_last_comment",
	"template=horse-note, $session->unread_by>0, sort=-h_notes_last_comment"
), $pageNum, $limit);

    h_notes_comments is a repeater with a few text fields and some checkboxes.

    So what I should get is:

    • pages with 1 or more of the h_notes_comments repeaters containing a checked checkbox, sorted by the h_notes_last_comment datetime field
    • other pages without a checked checkbox inside the h_notes_comments repeater (or no repeater items at all), sorted by the h_notes_last_comment datetime field

    But what's happening is the h_notes_last_comment field is taking precedence, so pages found with the second selector are appearing before pages found with the first, if the h_notes_last_comment happens to be more recent. Is that the expected behaviour or are we doing something wrong in our selectors?

    As an aside, am i right in thinking that when we're doing 

    h_notes_comments.$session->unread_by>0

    that will match any page that has at least one of the h_notes_last_comments repeaters with that checkbox checked? So even if there are 8 repeater items on a page, and 7 of them don't have the checkbox checked, it will still be returned?

    Improve performance of big query

    in General Support

    Posted

    Hi LK, we appear to have an issue with where the results are starting from on a particular page. For example, we're getting items on page 2 that have already been shown on page 1. Could this be something to do with the 'no duplicates' functionality that is somehow affecting start and end points?

×
×
  • Create New...