Inject a serialization format into key/value storages

March 12, 2014, 12:05 pm

≫ Next: Benchmark tests

≪ Previous: Move Drupal\Core\KeyValueStore\State* into Drupal\Core\State\State*

$

0

0

Objective

1. #2190723: Add a KeyValueStore\FileStorage to replace e.g. ConfigStorage discovered that all key/value store implementations in core are hard-coding PHP serialize() as serialization format right now.

2. PHP serialize() is definitely not always the most appropriate serialization format. unserialize() has security issues.

3. A key/value store MUST NOT care for the serialization format being used to begin with — its sole responsibility is to store a (string) value and retrieve it. The serialization format only needs to be consistent for each instance of a key/value store.

4. As a concrete use-case, the file-based configuration system expects data to be encoded and decoded in YAML.

Proposed solution

1. Establish Drupal\Core\Serialization as a core component that provides default implementations for serialization formats used in Drupal.

2. Inject a serialization format into each key/value store instance.

Notes

1. This issue only adds the PhpSerialize serialization format, which is currently used by key/value store implementations.

2. The set of formats is completed by

   #2208609: Move Json utility class into Drupal\Core\Serialization
   #2208633: Add a Yaml class to Drupal\Core\Serialization

---

Benchmark tests

February 6, 2014, 7:22 pm

≫ Next: Remove Test::SORT_METHODS constant opt-in support for sorting test methods alphabetically

≪ Previous: Inject a serialization format into key/value storages

$

0

0

In light of #2188661: Extension System, Part II: ExtensionDiscovery:

I wanted to know where exactly tests, or respectively Drupal core, is terribly slow.

So I quickly hacked up a naive bench() facility for TestBase, which is wrapped around individual aspects of interest and simply prints to stdout (on CLI only).

My local box shows some interesting things already, curious to see what the testbot review log will show.

Remove Test::SORT_METHODS constant opt-in support for sorting test methods alphabetically

February 21, 2014, 9:27 am

≫ Next: Rename simpletest.settings:clear_results into clear.results

≪ Previous: Benchmark tests

$

0

0

Discovered in #2201783: Simplify execution logic in TestBase::run():

TestBase::run() somehow supports a magic SORT_METHODS constant on a test class that triggers an alphabetical sort of test methods prior to executing them.

That doesn't make much sense.

1. Figure out which issue introduced it and why.
2. Remove it.

Rename simpletest.settings:clear_results into clear.results

January 16, 2014, 9:33 am

≫ Next: PHPUnit test the entity base classes

≪ Previous: Remove Test::SORT_METHODS constant opt-in support for sorting test methods alphabetically

$

0

0

#2171683: Remove all Simpletest overrides and rely on native multi-site functionality instead introduces a new configuration setting in simpletest.settings:

clear:
  artifacts: true
# @todo Move into 'clear'.
clear_results: true

For consistency, clear_results should be moved into clear.results.

---

That said, perhaps one more bigger question is: Why is the clear.results setting exposed in the Simpletest settings UI?

I bet that everyone who toggles that option is actually seeking for the clear.artifacts option. What's the use-case of retaining the simpletest assertion results in the simpletest database tables?

PHPUnit test the entity base classes

November 13, 2013, 4:37 am

≫ Next: Recoverable fatal error: Argument 1 passed to paymentreference_field_delete_instance() must be of the type array

≪ Previous: Rename simpletest.settings:clear_results into clear.results

$

0

0

Use PHPUnit to test the Entity, ConfigEntityBase, and ContentEntityBase classes. In order to do that, add wrappers to access services and procedural code.

Recoverable fatal error: Argument 1 passed to paymentreference_field_delete_instance() must be of the type array

September 25, 2013, 4:31 pm

≫ Next: Replace xpath() with WebTestBase::cssSelect() by leveraging Symfony CssSelector

≪ Previous: PHPUnit test the entity base classes

$

0

0

I have a site where i just want to uninstall the Comment module, but when I try it didn't work aand there is this error message in the log.

Recoverable fatal error: Argument 1 passed to paymentreference_field_delete_instance() must be of the type array, null given in paymentreference_field_delete_instance() (Line 286 of /srv/pub/drupal/sites/all/modules/payment/paymentreference/paymentreference.module).

Replace xpath() with WebTestBase::cssSelect() by leveraging Symfony CssSelector

April 2, 2013, 11:22 pm

≫ Next: Objectify session handler

≪ Previous: Recoverable fatal error: Argument 1 passed to paymentreference_field_delete_instance() must be of the type array

$

0

0

Problem/Motivation

XPath is hard to write and is often a barrier to new contributors writing tests.
Most devs know CSS selectors.
Symfony has a component css-selector that parses CSS selectors into xpaths.

Proposed resolution

Add symfony/css-selector to core
Add a ::cssSelect() method to WebTestBase
Refactor a couple of xpath based tests for example purposes.
Profit.

Remaining tasks

Review the attached patch

User interface changes

None

API changes

New method ::cssSelect() on WebTestBase

Before

$elements = $this->xpath('//div[contains(concat("", normalize-space(@class), ""), :field_class)]/li[@data-id=:data_id and ./h2[contains(., :text)]]', array(
  ':field_class' => 'tours',
  ':data_id' => 'tour-test-1',
   ':text' => 'The first tip',
));

After

$elements = $this->cssSelect("div.tours > li[data-id=tour-test-1] h2:contains('The first tip')");

Much easier.

Background on symfony/css-selector

symfony/css-selector is required by Mink. Mink is part of the Behat BDD QA family. Mink in conjunction with Goutte provides a headless-browser emulator in php and is fast becoming the defacto-standard for web-tests in the PHP community. Our goal for D9 is to replace SimpleTest with Goutte + Mink (see #1567500: [meta] Replace the testing framework with PHPUnit and possibly rewrite Simpletest).
Behat in turn is part of the PHP QA Toolchain, along with PHPUnit (which we already use) and PHP_CS (Code sniffer - which we use too, particularly in contrib - but not to its full extent in core).
Our longer term goal is to move towards the standard php quality toolkit. Although much of this will have to wait until Drupal 9, this change eases the burden on coders creating new tests. Whilst much of the new test functionality required for Drupal 8 is written, contrib authors will be writing SimpleTest tests for Drupal 8 for at least the next three years, most likely more as Drupal 10 is a long way off. Adding this now lowers the barrier to writing test coverage for code and improves Drupal core and contrib's overall quality.

Objectify session handler

February 25, 2014, 7:51 pm

≫ Next: Field default markup - removing the divitis

≪ Previous: Replace xpath() with WebTestBase::cssSelect() by leveraging Symfony CssSelector

$

0

0

As usual, we're shooting for way too much in #1858196: Turn session.inc into a service leveraging symfony session components

→ Baby steps!

→ http://php.net/manual/function.session-set-save-handler.php#example-4765

---

Field default markup - removing the divitis

March 9, 2014, 1:30 pm

≫ Next: Convert persistent Simpletest configuration into test-run-specific flags

≪ Previous: Objectify session handler

$

0

0

Problem/Motivation

The markup that is produced for a field is having a serious case of divitis - Looking at the discussions and the principles we build the frontend on for twig, that is wrong(tm)

The classes that a field gets added to its wrapper is in #2214249

Single value fields
A single field gets wrapped into 3 divs that is making the field fugly to work with out of the box.

<div class=".... ">
  <div class="field-label">[FIELD TITLE]</div>
  <div class="field-items">
    <div class="field-item">
        [FIELD DATA]
    </div>
  </div>
</div>

Proposed resolution

For a single field

<div class="...">
{{ data }}
</div>

with label

<div class="...">
  <h3 class="field-label">field title </h3>
{{ data }}
</div>

Do we want special markup strutures for an image ?

<figure class="...">
  <h3 class="field-label">field title </h3>
{{ data }}
<figcaption>...</figcaption>
</figure>

multivalue fields
in code now it comes out with alot of divs:

<div class="....">
  <div class="field-label">[ TITLE ]</div>
  <div class="field-items">
    <div class="field-item">foo</div>
    <div class="field-item">bar</div>
    <div class="field-item">baz</div>
  </div>
</div>

change to:

<ul class="field-items">
  <li class="field-item">foo</li>
  <li class="field-item">bar</li>
  <li class="field-item">baz</li>
</ul>

<div class="...">
  <div class="field-label">field title</div>
  <ul class="field-items">
    <li class="field-item">foo</li>
    <li class="field-item">bar</li>
    <li class="field-item">baz</li>
  </ul>
</div>

.field-label
It needs to be seperated from the fields cause we have no idea what an editor can put into a text field, same thing goes with field-item & field-items for multiple fields, so they do make sense there.

field.twig template:

<div class="soitseasy-to-add-new {{ attributes.class }}" {{ attributes }}>
  {% if not label_hidden %}
    <div class="field-label"{{ title_attributes }}>{{ label }}</div>
  {% endif %}
  {% for delta, item in items %}
    {% if loop.length > 1 %}
    <ul class="field-items" {{ content_attributes }}>
      <li class="field-item">{{ item }}</li>
    </ul>
    {% elseif  %}
      {# print only the data #}
      {{ item }}
    {% endif  %} 
  {% endfor %}
</div>

Remaining tasks

wait for theme_field to be removed #1987398: field.module - Convert theme_ functions to Twig

User interface changes

none

API changes

Convert persistent Simpletest configuration into test-run-specific flags

March 16, 2014, 7:23 pm

≫ Next: Improve DX of Settings class

≪ Previous: Field default markup - removing the divitis

$

0

0

Objective

1. Most of the Simpletest settings should not actually be stored in config. (verbose, keep-results, keep-artifacts, etc)
2. They are much rather one-off flags for a particular test run.
3. run-tests.sh already reflects that nature through command line arguments, but the Simpletest UI does not.

Proposed solution

1. Let's turn those settings into checkboxes on the Simpletest test overview page instead?

   So you can optionally tick them before hitting the "Run tests" button?

   [x] Verbose
[ ] Keep assertion results
[ ] Keep artifacts
( Run tests )

Improve DX of Settings class

March 16, 2014, 12:58 pm

≫ Next: Rename menu to menu_ui module

≪ Previous: Convert persistent Simpletest configuration into test-run-specific flags

$

0

0

Updated: Comment #6

Problem/Motivation

Settings::getSingleton()->get('foo'); is far uglier and less intuitive than it could be.

Proposed resolution

Replace with:
Settings::get('foo');

Similarly provide Settings::getAll(); and rename the ->get() instance method.

Remaining tasks

convert existing code

User interface changes

N/A

API changes

changes the method for getting settings - remove settings() function and only use static methods on the class.

Rename menu to menu_ui module

September 9, 2013, 4:40 pm

≫ Next: Clean up test results page

≪ Previous: Improve DX of Settings class

$

0

0

Updated: Comment #0

Problem/Motivation

After #2084197: Uninstalling menu module removes all custom menus current menu module goes more menu_ui module because implements only List and Form controllers for menu and menu link entities.

Proposed resolution

rename menu module to menu_ui module according view_ui module

Remaining tasks

wait for #2084197: Uninstalling menu module removes all custom menus

User interface changes

some strings

API changes

no

Related Issues

#2084197: Uninstalling menu module removes all custom menus
#1882552: Get rid of menu_list_system_menus()
#2030645: Expand Menu with methods

Clean up test results page

March 1, 2014, 11:25 pm

≫ Next: Move base theme system templates into /core/templates

≪ Previous: Rename menu to menu_ui module

$

0

0

Follow-up to #2207341: "Re-run tests" form action broken

Move base theme system templates into /core/templates

February 1, 2013, 9:30 am

≫ Next: Usability: Link to the next new comment

≪ Previous: Clean up test results page

$

0

0

Problem/Motivation

This issue was originally about providing for theme templates that would represent theme callbacks used in .inc files. However, drupal_common_theme() is only ever called once, by system_theme(). We could move drupal_common_theme() directly into system_theme(), and then all the theme functions/templates there too. All the places where these functions are used without a full bootstrap currently have to include system module beforehand.

Once they're in system module, there's incentive to factor them back out again.

Original issue by steveoliver

Drupal currently has no way of supporting templates for theme implementations defined in core/includes/* except by searching in themes/ directories drupal_find_theme_templates.

In our effort to replace Drupal's theme functions with [Twig] templates, we need a way for the theme system to find templates for theme implementations in /core/includes/.

Usability: Link to the next new comment

January 1, 2008, 11:47 pm

≫ Next: Add an 'empty image' option for picture

≪ Previous: Move base theme system templates into /core/templates

$

0

0

Quite straightforward.

---

Add an 'empty image' option for picture

May 20, 2013, 2:30 pm

≫ Next: hook_admin_paths() doesn't work with path aliases

≪ Previous: Usability: Link to the next new comment

$

0

0

Follow up for #1883526: Decide on the picture polyfill to use

Problem/Motivation

If you don't want to output an image on for instance mobile phones, you now need to use display:none; to hide it, but there's still a request for the specified image.

Proposed resolution

The Drupal 7 version of the picture module has an option to map a breakpoint to an empty image. If you select this option the image source is replaced by 'data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7'. So it adds like 50 bytes to the request, but it will not fire a new HTTP request.

Remaining tasks

1. Decide if we want this
2. Write a patch
3. Test

User interface changes

A new option is added on admin/settings/picture/group

API changes

None

hook_admin_paths() doesn't work with path aliases

August 5, 2011, 9:14 am

≫ Next: Enable page caching by default

≪ Previous: Add an 'empty image' option for picture

$

0

0

I created a 'video' content type on my site, and used pathauto to make the paths for video nodes always /video/[nid]. Then, in my custom module's implementation of hook_admin_paths_alter(), I added the path video/*. (I've added a bunch of other paths for forms I wanted to open in the overlay, and they all work fine).

When I click a link to a video (using the video/[nid] path), the overlay begins to appear (the dark overlay covers the screen), but before the content is loaded in, the page redirects to the actual node itself, at video/[nid]. I'm presuming this might have something to do with the fact that node/%node/view is overriding something the overlay is doing... but I couldn't figure out how to get a node to appear (viewing, not just editing) inside the overlay.

As a workaround, I added the path video/popup/% to my module's hook_menu() implementation, and in the callback, I set the page title and body content appropriately. Then, inside hook_admin_paths_alter(), I add the appropriate path to the $paths array. This works for me, but it was annoying having to figure out that overlay won't display node contents correctly.

Enable page caching by default

October 16, 2009, 3:06 pm

≫ Next: Redesign update.php to be more consistent with the installation process

≪ Previous: hook_admin_paths() doesn't work with path aliases

$

0

0

I don't see nor understand why we decrease performance by default.

I'm sure this is one of the points that adds negative karma to Drupal.

Even the interface says: "Normal (recommended)"

So let's just enable page caching by default and make anonymous users happier.

Redesign update.php to be more consistent with the installation process

January 8, 2014, 12:28 pm

≫ Next: Regression: routing / tabs / actions / contextual links lack way to attach replacement arguments to UI strings

≪ Previous: Enable page caching by default

$

0

0

As mentioned in #2041793: install-page.html.twig markup and CSS

When testing this, I noticed that update.php and install.php are now wildly out of sync with each other in terms of look and feel. Is there a separate issue about cleaning that up?

Regression: routing / tabs / actions / contextual links lack way to attach replacement arguments to UI strings

October 25, 2013, 1:37 am

≫ Next: Enable CSS and JavaScript aggregation by default in the standard profile

≪ Previous: Redesign update.php to be more consistent with the installation process

$

0

0

Problem/Motivation

In #2114069: Routing / tabs / actions lack way to attach context to UI strings we are adding context to UI strings to handle the case of ambiguous items like "Extend" and "Views". However tabs / routes / actions may also equally need title replacement values. The menu system supported these so this is a regression that we only allow static strings. This results in problems that derivative tab titles, eg. 'Translate @type' don't work, where we'd derive @type from elsewhere. See #2119497-9: Default local tasks are not to be assumed $route_name . '_tab' point 1.

Proposed resolution

Add support for replacement arguments that routes/tabs/actions would be able to provide. This will round out the arguments of t() to be supported.

Remaining tasks

- Commit.

User interface changes

None.

API changes

- Local tasks / local actions / contextual links get a new title_arguments key that is an optional array of key-value pairs
- Routes get a new _title_arguments key (in defaults) that is an optional array of key-value pairs

These can be used to provide static title arguments for replacement after translation (as in Drupal 7 - resolves the Drupal 7 regression). Additional title arguments are added from the request raw variables as well.

Related Issues

#2114069: Routing / tabs / actions lack way to attach context to UI strings