pettazz / jacked Goto Github PK

Creating a new user through the admin module, always Last and sometimes First Names don't even make it to the database.

500 error on non-croppic upload to imgupload-handler, undefined variable

On a post with an existing thumbnail, clicking the re-crop button and then saving a new crop results in a 50% smaller version of the new crop with black fill. The @2x trickery is failing after a re-crop of the original.

The filename doesn't change when we re-crop, so it shows the previous version in the img tag. We need to force it to update.

PayPal integration is straight up broken thanks to a change in their REST APIs, and the SDK has also changed its API. So basically the whole thing needs to be rewritten with the new lib.

Don't allow clients to write an absurd amount of data to the session, so they can't hog all the memory on the server via the API. This limit should be either configurable or intelligent, or some combination.

Add a big magic button that exports Sale data as a CSV in a configurable format for things like UPS shipping. We can use a DatasBeard Table as a mapping of Sale data fields -> CSV column names.

Even the example does't work. Everything past one level loses table names and doesn't apply logical operators unless explicitly specified.

Trying to use something like

'User.first_name LIKE ?' => '*something*'

Syrup will try to replace the relational field with something like

User.guid = Blah.guid AND User.first_name LIKE *something* = *something*

It shouldn't edit the key and let the normal parsing run through it.

Every Sale needs to have an optional field for any 'extra' values related to it that are not defined explicitly by the Product, such as size or color. For now they don't need to be anything dynamic or special, just a simple json object to represent the fields.

Later, we can have dynamic dimensions including strict type checking and validation for every Product.

But not yet.

The Sales list in Purveyor's manager is a monolithic list of everything from the database. The bigger it gets, the slower it gets both in terms of the query putting load on MySQL and the browser being slow to render all those rows and their detail views.

We need some kind of simple paging or better yet a date picker to select date ranges

If you change the schema for any table with existing data, it will just shove the new schema in without any regard for the existing rows. It needs to:

1. check that the existing rows are all valid within the new schema
2. add/delete fields from existing rows as needed (probably should prompt the user about this)

Why does this even exist.

Without an admin interface, this whole module is pretty useless, huh?

For example: createRow takes $content as an array but just converts it to json anyway. We might as well check the type first so we can also accept strings that are already json.

Promotions should allow for either fixed numeric or percentage values, as well as whether to apply to the full order or a single product, independently of each other. This allows us to create things like 20% off the full order including shipping, free shipping, etc.

Investigate adding fixed discount line items to PayPal API call. If this is impossible, we'll need a workaround for adding to existing line items, or not allow the combination of full order application + fixed value.

Finding a sale by anything other than email is incredibly difficult. We need a search/filter field.

When a direct URL to somewhere past auth redirects to the login page, we completely ignore the original URL and go to the home page on successful login.

Login form should include a hidden field for optional post-login redirect

With the timeout set to 10 seconds by default on most entries in MySQL's use of memcached, if within a single script, an UPDATE/REPLACE and then a SELECT are called using the same rows in the db, the SELECT will return data from memcached, which will now be outdated after the UPDATE/REPLACE. The easy fix is to invalidate cached rows (memcacher->delete()) after a successful UPDATE/REPLACE, but with the existing md5 hashing for queries, there's no way to easily determine which rows to invalidate. Hashing needs to be done more intelligently, and then invalidations can be added.

No error messages, just doesn't do anything.

Why is this even in the main repo?

After editing a post and choosing to re-crop an existing thumbnail and saving it, the new filename has an extra "_cropped.png" resulting in something like http://staging.warrantynowvoid.com/assets/img/lol/30634c9752c340ada702c7322be9801d_cropped.png_cropped.png

I can only assume this would go on forever for crops on crops on crops. It works, so this is only an annoyance.

Rather than just specifying "SomerelationName" => "some-lengthy-guid" and relying on auto-generated target/guid notations, allow for specifying tables and fields as the keys with dot notation: "Category.name" => "butts"

hasOne relations, just simple guid joins, don't seem to be updated properly, and hasMany relations, it doesn't even try to handle.

It does actually do a really good job traversing all the relational objects in both cases, but it doesn't actually update the relations themselves. So you can change the User object's name in the database, but you can't change the User that this object is pointing to. Also the hasMany arrays just straight up blow my mind on a daily basis, so I can't really begin to explain the fix for that. Use the relationTable static property of the relation model? Oh god

Current version of the JSON Validator library in JACKED/lib/php-json-schema/Json/Validator.php has changes to __construct to switch from taking a path and loading a json file as a schema to just taking a string that is the schema itself. This is altered from the actual repo until either hasbridge/php-json-schema#15 is resolved or this is replaced with an actual fork.

Ex: Blag is specifically hardcoded with Curator support on posts. Modules should be able to define widgets or something that can be loaded on demand.

As requested in steempb/steempb.com#34, add some reporting on Sales and things and sorting/filtering/paging of the Sales list.

Repro on MobileSafari:

Go to Manage Promotions in Purveyor
Click edit button in existing Promotion row
Change values, click save button
A different row will have lost its name (now "") and value (now 0), while the intended row is unchanged.

Right now, the only way to register a model instance with Syrup is to just start using it and trigger lazy loading, which looks for the model's class file on the filesystem and instantiates it. Syrup needs to be able to also support programmatically creating a model instance and requesting that it be registered. This will most commonly follow a pattern like creating a new instance of BaseModel, then setting its magic members and field instances, then attaching it to Syrup with some special name that doesn't necessarily match a module.

Doing something like this:

$posts = $JACKED->Syrup->Blag->find(
    array('AND' => array('Curator.canonicalName' => $tagName, 'alive' => 1))
);

results in a bit of SQL that looks like this:

WHERE  ( ( CuratorRelation.target = Blag.guid AND Curator.guid = CuratorRelation.Curator AND Curator.canonicalName )  = '-sciencefiction' AND Blag.alive = '1' )

The parens around the relational join are causing trouble, like hanging up mysqld on trying to cache the insane result of infinite rows.

Using wildcards in the value like

'guid LIKE ?' => '*bleh*'

is fine, but

'guid LIKE *?*' => 'bleh'

will result in

guid LIKE %'bleh'%

with quotes inside the wildcards around the value.

Also applies to croppic

Rather than copy pasting each individual Sale tracking number into the modal, we should allow import of a csv or xls with Sale uuids -> tracking numbers.

It's dead and it's never coming back. Switching to Stripe from PayPal would also allow accepting bitcoin in the future.

Right now we use "guid" and "uuid" pretty interchangeably in a few places throughout the code, which is technically inaccurate. We should clean up the implementation to be consistent, and improve things like storing them in the database. (We currently use VARCHAR which is unnecessarily large, when CHAR(36) would be fine, or ideally BINARY(16).)

This module will be for a simplistic, admin-manageable, persistent data store. The goal is to enable users to create and edit what amount to tables of data without having to edit any code or add models to Syrup, and also to allow for site-implementation-specific data stores that can be used in templates and things but also be editable through Admin without requiring forking JACKED itself.

username or email? In some places it even refers to email as 'username'. It needs to be a configurable option which to use for things like login and getUser

For Moolah, transactions that haven't been confirmed within 30 minutes are cancelled, and PayPal probably has a similar time limit. We should show that on the Sales manage page instead of being forever pending.

Opening a post with an existing thumbnail for edit, then saving without changing the thumb saves NULL to the post's thumbnail field.

We're using localstorage to autosave save a draft periodically, but it only uses the actual content block as part of epicEditor. Why not just make it a json object for every field in the form?

Also, let's just pretend https://github.com/pettazz/JACKED/blob/master/JACKED/admin/Blag/edit.php#L71 never happened.

Currently Syrup will only try to load a model from its own core directory inside JACKED_MODULES_ROOT, which means if any app wants to create their own models they have to either fork JACKED or keep their model files untracked from git, which sucks.

Syrup should allow for a user configurable Models search path outside of the core stuff, like the way $PATH works, with core as the first search locations then conf-defined added after.

In createSale, if $shipping == 0, we don't construct the $details object and run into a "Undefined variable: details" error later on. Instead ignoring $details on a falsey value, we should default it to $0.

Apparently twitter is too good for og meta tags and has their own format:
https://dev.twitter.com/cards/overview