File_Structure_Test to make sure we don't regress.
According to the PHP docs, the "public" keyword is implied on static
functions, so remove it. Also, require private static functions to
start with an _.
http://php.net/manual/en/language.oop5.visibility.php
* Refactor blocks so that they have a separate id vs css_id. This way
we can have a unique identifier for each visual block.
* Store blocks with a random id as their unique identifier
* Add Admin_Dashboard::remove_block() and modify
themes/admin_default/views/block.html.php to call it when you click the
remove box.
OLD:
$form->submit("Foo") --> <input type="submit" value="Foo">
New:
$form->submit("foo_button")->("Foo") --> <input type="submit" name="foo_button" value="Foo">
Mostly we don't care what the button is so we leave the name blank.
- And refactor printf to our string interpolation / pluralization syntax
- Also, a slight change to the translations_incomings table, using binary(16) instead of char(32) as message key.
dialog for deleting tags. Remove the 4 character restriction on tags
(it was getting ignored by the add form anyway since it was mistakenly
referred to as tag_name there).
communicate. Almost all controllers now use JSON to speak to the
theme when we're dealing with form processing. This means tht we only
send the form back and forth, but we use a JSON protocol to tell the
browser success/error status as well as the location of any newly
created resources, or where the browser should redirect the user.
Lots of small changes:
1) Admin -> Edit Profile is gone. Instead I fixed the "Modify Profile" link
in the top right corner to be a modal dialog
2) We use json_encode everywhere. No more Atom/XML for now. We can bring those
back later, though. For now there's a lot of code duplication but that'll be
easy to clean up.
3) REST_Controller is no longer abstract. All methods its subclasses should create
throw exceptions, which means that subclasses don't have to implement stubs for
those methods.
4) New pattern: helper method get_add_form calls take an Item_Model,
not an id since we have to load the Item_Model in the controller
anyway to check permissions.
5) User/Groups REST resources are separate from User/Group in the site
admin. They do different things, we should avoid confusing overlap.
the various modules. In the process, rename xxx_menu::site_navigation() to just
xxx_menu::site(). And add xxx_menu::admin().
The menus are the same as before, but I changed the HTML to be
consistent with the way that we do it in the regular site, and this
broke the superfish styles. I don't know how to fix this.. help me
Chad!
convention. To respond to the "photo_created" event in the gmaps
module, you create modules/gmaps/helpers/gmaps_event.php containing
class gmaps_event which has function photo_created.
Renamed all events from gallery.foo.bar to foo_bar
Updated tag module to use new convention.
1) Generate the form in Tags_Controller::_form_add()
2) Process the form submit in Tags_Controller::_create()
3) Create the tag properly
This required me to limit our scope to adding one tag at a time, which
I think is fine if we're doing Ajax style tag addition.
1) change buckets to be 1-7 not 0-6.. zero-based indicies don't make sense in the
real world and are liable to confuse themers.
2) Change tag API to popular_tags($count) which just returns the popular tags. Let
the block code massage it into the right format for the view.
3) Move alphasort into the block code, simplify it and rename it to sort_by_name so
that it's more descriptive
4) Do the bucketing in the view; this allows the themer to override it and create their
own bucketing algorithm to go with the theme's CSS.
5) Don't create any temporary objects.
multiple items, so don't create a confusing API where we don't need
one. The caller can just as easily loop over items and tags.
Use ORM::has() instead of manually looping over items, which would be
wildly inefficient on large installs. Document that we're calling
ORM::has() a second time just so that we can update the count
correctly.
Avoid using restrictions on our data in the database; let's design the
system to keep integrity in the app (and make the app robust against
minor integrity issues like duplicate tags, etc).
$theme->block_type() so that the themer has a consistent interface.
Also added a bunch more callbacks and normalized the names so that the
module author has plenty of options for where stuff gets put on the
page. Especially renamed album/photo/sidebar to be album_blocks()
photo_blocks() and sidebar_blocks() to make it clear that those are
going to be larger content sections and not just basic insertion
points.
Used __call() to collapse all functions in the theme, which
incidentally makes it trivially easy to add a new insertion point.
Andy Staudacher
Bharat Mediratta
Chad Kieffer
Tim Almdal