If you look at #1893730: Provide an in-memory mock implementation of Path\AliasManager for tests and update.php you might think that an alias manager is a simple thing but the interface is pretty complicated compared to what it would need it be.
↧
Refactor the alias manager according to msonnabaum session
↧
Remove deprecated drupal_explode_tags() and drupal_implode_tags()
↧
↧
document queue worker callback
This is a fairly simple callback, but it does have the ability to throw exceptions. There's also a patch for 8.x to have it through different classes of exception, which will add complexity. Hence worth documenting. Patch coming!
↧
queue cron workers can't signal a broken queue
Consider this code from drupal_cron_run:
foreach ($queues as $queue_name => $info) {
$function = $info['worker callback'];
$end = time() + (isset($info['time']) ? $info['time'] : 15);
$queue = DrupalQueue::get($queue_name);
while (time() < $end && ($item = $queue->claimItem())) {
$function($item->data);
$queue->deleteItem($item);
}
}Note that the return value of the 'worker callback' function is never checked. It could (and should) be used to indicate whether or not to delete the item from the queue (see the subsequent line).
Consider a business rule that requires that only certain items in the queue should be processed now. As a concrete example, let's say that the item has a 'send_date' and the 'worker callback' checks this date before sending an email. If the function could return FALSE to indicate not to delete the item and TRUE to indicate that the item should be deleted, then a whole host of issues could be avoided. As it is, the 'worker callback' function has to re-queue the item, but this then results in an infinite loop.
↧
Add a Drupal Yaml wrapper so we can default to PECL Yaml component if it is available
Updated: Comment #69
Problem/Motivation
We should be defaulting to the PECL Yaml component if it is available as opposed to Symfony's. We had originally talked about this way back in the beginning but it had been forgotten about.
Proposed resolution
Add a YAML class that decides whether to use the extension or Symfony. There's no point in using plugins and plugins are too heavy for this -- it's not extensible.
API changes
Config save no longer throws exceptions if the config object contains an object or resource. While we could make Symfony do this, yaml_emity() doesn't do this so we can't make this a requirement.
↧
↧
Obsolete docs in WebTestBase::drupalPlaceBlock()?
API page: https://api.drupal.org/api/drupal/core%21modules%21simpletest%21lib%21Dr...
Enter a descriptive title (above) relating to protected function WebTestBase::drupalPlaceBlock, then describe the problem you have found:
There's some documentation in WebTestBase::drupalPlaceBlock() that says:
Note: Until this can be done programmatically, the active user account must have permission to administer blocks.
But it looks to me as though the code is programmatic and would not require this any more. Should this be removed?
For the moment, moving to simplest component for decision; afterwards you can move to "documentation" component and mark "Novice" for the actual patch if it is OK to remove this documentation.
↧
Find a new OO home for drupal_get_hash_salt()
Updated: Comment #N
Problem/Motivation
We still have (and would like to convert) usages of drupal_get_hash_salt() in our OO code. This is not ideal, as tests have to do the if(!function_exists('ffdfdf')) hack etc.. We cannot just use the setting directly as we need to keep the logic that throws an exception if it is empty.
Proposed resolution
Find a new home for this. We could just check for this when we get the hash_salt setting. I think it makes more sense to just have this living somewhere though.
Remaining tasks
Find a place, patch. Convert remaining usages.
User interface changes
None
API changes
Hopefully no more drupal_get_hash_salt(), just the new thing.
↧
Node form ignores content type setting for revisions
OS: Linux Mint
Server: Nginx 1.2.6
PHP: 5.4.9
Drupal Ver: D8-Dev and D8-alpha9
Path: node/add/*
I just noticed on a fresh Standard installation that the node edit form ignores the content type setting for revisions. Based on previous versions of Drupal, if revisions are not enabled by default on the content type settings page then users must enable revisions on the node edit form. This appears not the case with D8-dev and D8-alpha9, the two version I tested.
1. Install a fresh copy of D8-dev or D8-alpha9
2. Check content type settings and ensure revisions are disabled (should by default).
3. Create a node; create a new revision is checked by default even though revisions are disabled.
↧
Clean up test results page
Follow-up to #2207341: "Re-run tests" form action broken
↧
↧
Add a search/input group component
We are adding a grouped search component to Seven in #2160545: Create search/filter component and it seems like it would suit Bartik's search form as well.
↧
add test for simpletest rerun test button
Updated: Comment #1
Problem/Motivation
Follow-up from #2207341: "Re-run tests" form action broken.
#2207341-13: "Re-run tests" form action broken has a pastebin with some work toward tests for rerunning tests in the simpletest ui. but it was an infinite recursion and tricky.
Proposed resolution
None.
Remaining tasks
investigate if there is any way to test that so it does not break again.
User interface changes
API changes
↧
"Re-run tests" form action broken
The Re-run tests button in the Simpletest UI unfortunately got broken by #1938926: Convert simpletest theme tables to table #type
Attached patch fixes it + additionally cleans up the test results page output to remove unnecessary fieldset wrappers.
This is a bug fix, and normally a bug fix should add test coverage. But I object to add tests for this to Simpletest, because it's a developer tool.
follow-ups
↧
Identify pieces of Drupal that could be replaced by Symfony code
Given that Symfony is going to be used to provide Drupal 8's HTTP library, it would be worth looking to see what other functionality could be replaced by Symfony. As a follow-on ticket, it might also then be useful to identify a path to completely immerse Symfony in Drupal, for those who want even more.
List of related issues
Please help keep this list up-to-date, and please tag all related issues with 'symfony' to help track them:
- All issues tagged with 'symfony'
- #1178246: Add Symfony2 HttpFoundation library to core
- #335411: Switch to Symfony2-based session handling
- #1269832: Use Symfony / context code to retrieve HTTP language preferences
- #1837280: Discussion: Use Symfony Console Component to decrease the Drush/Drupal specific code parts of Drush.
↧
↧
Convert COMMENT_HIDDEN & COMMENT_CLOSED & COMMENT_OPEN to a constant on the comment field interface
This constants are used by comment field to indicate the visibility/commentability of the attached field.
We should move this constants to separate class to make unit-testing easy.
↧
Primary button's border is not visible on focus
Seven's primary button focus styling sets a border colour that is really similar to the background gradient. It looks like there is no border at all.
The offending CSS is on line 83 of buttons.theme.css:
.button--primary:focus {
border-color: #0087db;
}↧
Convert menu links to the new Entity Field API
Follow-up to #916388: Convert menu links into entities.
Problem/Motivation
We now have a menu link entity but there's still quite some work to do in order to implement proper multilingual support.
Proposed resolution
Let's convert the menu link entity to the new Entity Field API as implemented in #1696640: Implement API to unify entity properties and fields. localized_title and localized_options need to die as a result of this conversion.
Remaining tasks
See above.
User interface changes
None.
API changes
A lot! TBD.
↧
Tour tab increases the height of the toolbar.
It looks like there is some specific styling on the tour tab in the toolbar that's increasing the height of the toolbar. Ideally there shouldn't be any unique styling, most of the tabs look the same.
↧
↧
Implement built-in support for internal URLs
The contrib link modules Link, URL Field, and CKEditor Link support both internal and external URLs and I get that a lot of people use the module for internal links. Right now the storage for the core link field data supports both, but the default widget only support external URLs.
Current summary from #1778858: Decide on built-in support for internal URLs which was filed against the URL module issue queue:
Plan A:
- Decide we only want to support external URLs in the widget and change nothing. Leave internal URL widget for contrib.
- Pros: Lowest complexity
- Cons: Users may find out-of-the-box solution limiting.
Plan B:
- Rename the current widget from 'URL field' to 'External URL field' and add a new 'Internal URL field' widget.
- Pros: we support both, not too much extra code
- Cons: this makes a specific instance only able to use one or the other and not mix.
Plan C:
- Add an option on the field instance to have the administrator say if this field supports internal only, external only, or both. The default widget will change it's validation based on the options.
- Pros: Able to mix/match. Seems better as a field instance setting, not a widget setting.
- Cons: Most amount of complexity to add. Widget will not be able to support HTML5 'url' FAPI type if option is not 'external only' since the url field by nature only supports external fields.
Plan D:
- Always use the FAPI 'url' type, and attempt to resolve what are 'local' URLs to un-aliased internal Drupal URLs.
- Pros: Simplicity. We are able to handle both types with the same widget and use the new HTML5 FAPI type always.
- Cons: Medium complexity.
- How does this work for sites that have multiple domains (multisite or domain access) or SSL? Would we still want to add additional logic for 'Allow the following types of URLs: [X] Internal [X] External'?
after my interdiff changes
./vendor/bin/phpunit --strict
OK (4561 tests, 8093 assertions)
↧
Remove persisted services
Persisted services are causing lots of problems since if any other service is injected into a persisted service it has to be persisted to - however nothing mandates this.
↧
Replace watchdog icons with Libricons
We already added similar icons in #2075949: Add Libricons to messages. We should reuse these and remove:
- watchdog-warning.png
- watchdog-error.png
- watchdog-ok.png
↧