I guess this fix from #1857298 for D7/D8 has never been backported to 6.x-1.x-dev?
@MukhtarM: Thanks for replying so quickly!
Your screenshot shows the UI from mediawiki_api 7.x.
The "MediaWiki HTTP_Request location" is from the mediawiki_api 6.x UI which is different. Since there is nothing I could enter there, I am not sure if the 6.x branch is even operational.
mediawiki_api 7.x-1.0-rc3 works, at least rudeimentary, but unfortunately it requires D7 :)
(For background: I am using Mediawiki markup for 15+ years on most of my sites, and it has turned out to be one (among several other) showstoppers to upgrade these sites beyond D6. Since all methods I have been using - e.g. PEARwiki_filter and mediawiki_filter - were abandoned, mediawiki_api would be the only potential upgrade path to get the remaining D6 sites to D7)
New server, trying 'elysia_cron' again on three sites (in the past decade, I had been using 'ultimate_cron', which also did not work reliably)
Now using 'elysia_cron' 6.x-2.2, LTS version, from Jan 19, 2023 (https://github.com/d6lts/elysia_cron) with PHP 7.3.31-1~deb10u6.
Results as of May 28, 2024 as shown at the respective ./admin/build/cron admin pages:
1) Last run: 24.05.2024 - 23:12
2) Last run: 25.05.2024 - 05:12
3) Last run: 25.05.2024 - 05:12
These were the times I ran cron manually via ./admin/reports/status/run-cron.
According to Legend, everything is in status: "Waiting for execution Job is ready to be executed, and is waiting for system cron call".
So after a decade, still the identical issue: Cron is not automatically executed according to the settings from crontab; the search index becomes quickly stale and also has to be manually updates (e.g. drush search-index); maintenance jobs like cleaning expired access logs or removing older rows from flood and batch table are not executed unattended.
Running cron manually from ./admin/build/cron takes an exec time between 25s, 51s, and 87s, so I guess timeouts should not be an issue. Really odd.
The 'formats_updater' module works fine.
But unfortunately it is only available for D6.
The code from #20 reports:
Styles: 10, Effects new: 19, Effects exists: 0
The D6 Imagecache presets now do show up at ./admin/config/media/image-styles.
Also tried Jen's module from #11, same result.
Made a 'drush cc all', but for whatever reason the converted presets seem not to be used anywhere. Is anyone else getting this too?
Anyway, these litte migration helpers are (potentially) incredibly useful, so many thanks for it!
According to #39 from November 2011, "upgrades from 6.x-2.4 should now work".
Tried that with an upgrade from 6.x-2.18 to 7.x-3.13 which did not work (among other issues, I got the problem with the the insufficient schema version for catalog which was reported over a decade ago).
Could anyone who managed a successful upgrade please give some feedback which versions were working for the databse updates?
Thanks!
Similar issue. Error message:
Missing field module: 'filefield'. This field cannot be migrated.
- Field name: field_video
- Field type: filefield
- Content type: Video
This field is handled in D6 by the "Video" module ("Allows Creation of CCK Video Fields"). On the migrated site, "video 7.x-2.15" is installed and enabled, but the field can not be migrated for whatever reason.
And:
Missing field module: 'emvideo'. This field cannot be migrated.
- Field name: field_emvideo
- Field type: Embedded Video (= Embedded Video Field)
- Content type: Video
In D7, an "Embedded Media Field 7.x-1.0-alpha2+1-dev" exists; it "provides an embedded media widget for file fields" and depends on the "media" and "file_entity" modules. Bundled with "media" module in version 7.x-2.30 is a sub module called "media_migrate_file_types"; the latter one seems not to have an UI, but can be enabled with Drush. However, both fields are still listed as "Unavailable Fields" at ./admin/structure/content_migrate.
Still no migration path in sight after a decade?
Closing as "won't fix".
More of these non-sensical opinions from memcache module.
Reported at ./admin/reports/status:
There is a problem with your memcache configuration. Please review sites/all/modules/memcache/README.txt for help resolving the following issue:
PECL Memcache version 3.0.8 is unsupported. Please update to 3.0.6 or newer.
Information like this isn't too helpful. At least I do not understand what the poet tries to tell us here.
Thanks, sure, as the project description says: "An API for using Memcached and the PECL Memcache or Memcached libraries with Drupal." Who is supposed to understand which one is used for which purpose by the Drupal module?
Anyway, on my old production server I got php-memcached 2.2.0-2 and php-memcache 3.0.8-5; on my new server I got php-memcached 3.1.3+2.2.0-1 and php-memcache 3.0.9~20170802.e702b5f-2, so I can not meet the requirements without breaking package management dependencies. Lovely for a D7 module.
Note to self and others encountering a "PHP Fatal error" with Drush, e.g. something like this:
PHP Fatal error: Uncaught Error: Call to undefined function cache_get() in /var/www/{mysite}/includes/module.inc:763
Stack trace:
#0 /var/www/{mysite}/includes/module.inc(963): module_implements('system_theme_in...')
#1 /var/www/{mysite}/modules/system/system.module(2531): module_invoke_all('system_theme_in...')
#2 /var/www/{mysite}/includes/theme.inc(798): _system_rebuild_theme_data()
#3 /var/www/{mysite}/includes/theme.maintenance.inc(57): list_themes()
#4 /var/www/{mysite}/includes/bootstrap.inc(2965): _drupal_maintenance_theme()
#5 /var/www/{mysite}/includes/errors.inc(177): drupal_maintenance_theme()
#6 /var/www/{mysite}/includes/bootstrap.inc(2690): _drupal_log_error(Array, true)
#7 [internal function]: _drupal_exception_handler(Object(Error))
#8 {main}
thrown in /var/www/{mysite}/includes/module.inc on line 763
Drush command terminated abnormally due to an unrecoverable error.
In some cases there is a simple solution: Drush needs to be called as root or with sudo.
After upgrading some D7 sites to a new dedicated server, I am getting exatly the same issue.
PHP version 7.3.31-1~deb10u6, the sites are on Drupal 7.100 respectively 7.99 in one case.
Drush cc:
$ drush cc
Enter a number to choose which cache to clear.
[0] : Cancel
[1] : drush
[2] : registry
2
PHP Fatal error: Uncaught Error: Call to undefined function cache_get() in /var/www/{mysite}/includes/module.inc:763
Stack trace:
#0 /var/www/{mysite}/includes/module.inc(963): module_implements('system_theme_in...')
#1 /var/www/{mysite}/modules/system/system.module(2531): module_invoke_all('system_theme_in...')
#2 /var/www/{mysite}/includes/theme.inc(798): _system_rebuild_theme_data()
#3 /var/www/{mysite}/includes/theme.maintenance.inc(57): list_themes()
#4 /var/www/{mysite}/includes/bootstrap.inc(2965): _drupal_maintenance_theme()
#5 /var/www/{mysite}/includes/errors.inc(177): drupal_maintenance_theme()
#6 /var/www/{mysite}/includes/bootstrap.inc(2690): _drupal_log_error(Array, true)
#7 [internal function]: _drupal_exception_handler(Object(Error))
#8 {main}
thrown in /var/www/{mysite}/includes/module.inc on line 763
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Uncaught Error: Call to undefined function cache_get() in /var/www/{mysite}/includes/module.inc:763
Stack trace:
#0 /var/www/{mysite}/includes/module.inc(963): module_implements('system_theme_in...')
#1 /var/www/{mysite}/modules/system/system.module(2531): module_invoke_all('system_theme_in...')
#2 /var/www/{mysite}/includes/theme.inc(798): _system_rebuild_theme_data()
#3 /var/www/{mysite}/includes/theme.maintenance.inc(57): list_themes()
#4 /var/www/{mysite}/includes/bootstrap.inc(2965): _drupal_maintenance_theme()
#5 /var/www/{mysite}/includes/errors.inc(177): drupal_maintenance_theme()
#6 /var/www/{mysite}/includes/bootstrap.inc(2690): _drupal_log_error(Array, true)
#7 [internal function]: _drupal_exception_handler(Object(Error))
#8 {main}
thrown in /var/www/{mysite}/includes/module.inc, line 763Result is: sites are inaccessible, getting an "Error 503: Backend unavailable" from the SSl gateway.
No solution available five years after issue was reported. Changing priority to critical.
@budalokko: Thank you!
I removed this line of code in ./modules/image/image.field.inc, and the error is fully gone. No more bogus error messages, no more silently discarded image files. Excellent!
This applies to Plupload module 7.x-1.7 and the library in version 1.5.8.
Regarding that Drupal core issue #2345695 with status "Closed (fixed)", it simply introduced a regression affecting real data by attempting to fix a nothingburger about a fringe case. Since the broken validation routine is in Drupal core, Plupload module can not fix it or work around it, right?
In combination with plupload-7.x-2.x-dev, I used 'Plupload 2.3.9 AGPLv3' (from https://github.com/moxiecode/plupload/archive/v2.3.9.zip). According to ./admin/reports/status, the plupload module seems to have been happy with it (Status Report complained in combo with 1.5.8).
However, I noticed that ./admin/reports/libraries lists the libraries (both versions) as "Unregistered" (= "These libraries were found in the filesystem but there is no metadata about them", opposed to "Installed" = "These libraries are registered and installed correctly". I have no idea if that "Installed" vs. "Unregistered" status is merely cosmetic or has any functional impact, but I doubt that it is relevant to the file upload issue I am encountering (unless that is handled more strict since Drupal core 7.99).
Correction:
Actually, Plupload 7.x-2.x-dev and 7.x-1.7 behave differently.
- The procedure described above (upload files a 2nd time, plupload discards one file of the batch) applies only to 7.x-1.7.
- Plupload 7.x-2.x-dev makes it completely impossible to upload image files. Though, still the same error message
I reverted back to Plupload 7.x-1.7 and the dated library in version 1.5.8 which gives me the described behaviour: first upload attempt - error message - second upload attempt - files are uploaded, but one from the batch is discarded.
I restarted the Apache webserver and made a 'drush cc all'. Theoretically other caching layers could still interfere (varnish, apc), and the server has currently 2002 days uptime.
However, since 'darkodev' found the string from the error message in Drupal core and nobody reports issues with 'file_entity', I guess that D7 7.99 introduced some kind of regression. Would not be the first time, and that's one of the reasons why most of my sites still run on D6 - rock solid and fast.
@darkodev: Unfortunately I have no usable dev experience, so this would not be very targeted.
But I have good news for 'file_entity' as far as this issue is concerned - I can disable and uninstall the module, but the problem remains. It seems to be a freak coincidence that this problem occured with the 'file_entity' 7.x-2.38 upgrade.
Even more bizarre, on another D7 site (also without 'file_entity') the issue does not show up, so it might not even be related to the Drupal 7.99 upgrade. That means the issue appears to have developed without any module upgrades or configuration changes. WTF.
Related to file uploads, I am running the following modules from contrib: file_entity, filefield_paths, filefield_sources, filefield_sources_plupload, and plupload. Except file_entity, nothing of this has been updated recently.
If the error message string is in the Drupal 7.99 codebase, this could point to an issue with Drupal core since it was updated recently, but only in combination with one of the other modules. However, in the D7 issue queue I can not find anything reported recently about newly introduced issues with file uploads.
In my error log (/admin/reports/dblog), no errors are recorded, just a PHP notice from advanced_forum module about an "undefined property" (most likely unrelated).
I am out of ideas where to look for any pointers :-(
Yes, Drupal 7.99 & file_entity 7.x-2.38
Since no other reports are coming in since the last file_entity release, it is most likely an exotic interaction between the modules I am using.
However, the only updates I installed since November 2023 are file_entity and Drupal 7.99.
Hi Joseph,
thank you for the reply. I am not sure what to look for.
To me, the settings look OK.
E.g. at Media -> File settings I have "default allowed file extensions" for the file types I am trying to upload ("jpg jpeg gif png…").
At Structure -> File types, the MIME type for images is "image/*".
Can't find something that appears to be wrong or missing.
At Media -> File settings there is a setting for a "File Upload Wizard" with an option to "Skip filetype selection". I checked this setting and saved, but the behaviour did not change.
asb → created an issue.
@twilderan: Thanks for your reply.
Drupal version: 7.98
PHP version: 5.6.40-0+deb8u12
# ls -la sites/default/files/dxpr_theme/fonts
total 232
drwxrwxr-x 2 www-data www-data 4096 Aug 7 00:05 .
drwxrwxr-x 3 www-data www-data 4096 Jul 16 04:53 ..
-rw-rw-r-- 1 root root 5836 Aug 7 00:05 6xK3dSBYKcSV-LCoeQqfX1RYOo3qN67lqDY.woff2
-rw-rw-r-- 1 root root 5024 Aug 7 00:05 6xK3dSBYKcSV-LCoeQqfX1RYOo3qNa7lqDY.woff2
-rw-rw-r-- 1 root root 6004 Aug 7 00:05 6xK3dSBYKcSV-LCoeQqfX1RYOo3qNK7lqDY.woff2
-rw-rw-r-- 1 root root 20616 Aug 7 00:05 6xK3dSBYKcSV-LCoeQqfX1RYOo3qNq7lqDY.woff2
-rw-rw-r-- 1 root root 7036 Aug 7 00:05 6xK3dSBYKcSV-LCoeQqfX1RYOo3qO67lqDY.woff2
-rw-rw-r-- 1 root root 14892 Aug 7 00:05 6xK3dSBYKcSV-LCoeQqfX1RYOo3qOK7l.woff2
-rw-rw-r-- 1 root root 7972 Aug 7 00:05 6xK3dSBYKcSV-LCoeQqfX1RYOo3qPK7lqDY.woff2
-rw-rw-r-- 1 root root 916 Aug 7 00:04 6xKwdSBYKcSV-LCoeQqfX1RYOo3qPZZMkidg18Smxg.woff2
-rw-rw-r-- 1 root root 1040 Aug 7 00:04 6xKwdSBYKcSV-LCoeQqfX1RYOo3qPZZMkidh18Smxg.woff2
-rw-rw-r-- 1 root root 19828 Aug 7 00:05 6xKwdSBYKcSV-LCoeQqfX1RYOo3qPZZMkidi18Smxg.woff2
-rw-rw-r-- 1 root root 5756 Aug 7 00:05 6xKwdSBYKcSV-LCoeQqfX1RYOo3qPZZMkidj18Smxg.woff2
-rw-rw-r-- 1 root root 1032 Aug 7 00:04 6xKwdSBYKcSV-LCoeQqfX1RYOo3qPZZMkido18Smxg.woff2
-rw-rw-r-- 1 root root 14104 Aug 7 00:05 6xKwdSBYKcSV-LCoeQqfX1RYOo3qPZZMkids18Q.woff2
-rw-rw-r-- 1 root root 1220 Aug 7 00:04 6xKwdSBYKcSV-LCoeQqfX1RYOo3qPZZMkidv18Smxg.woff2
-rw-rw-r-- 1 root root 7912 Aug 7 00:05 6xKydSBYKcSV-LCoeQqfX1RYOo3ik4zwkxduz8A.woff2
-rw-rw-r-- 1 root root 6968 Aug 7 00:05 6xKydSBYKcSV-LCoeQqfX1RYOo3ik4zwlBduz8A.woff2
-rw-rw-r-- 1 root root 14780 Aug 7 00:05 6xKydSBYKcSV-LCoeQqfX1RYOo3ik4zwlxdu.woff2
-rw-rw-r-- 1 root root 5816 Aug 7 00:05 6xKydSBYKcSV-LCoeQqfX1RYOo3ik4zwmBduz8A.woff2
-rw-rw-r-- 1 root root 4928 Aug 7 00:05 6xKydSBYKcSV-LCoeQqfX1RYOo3ik4zwmhduz8A.woff2
-rw-rw-r-- 1 root root 20388 Aug 7 00:05 6xKydSBYKcSV-LCoeQqfX1RYOo3ik4zwmRduz8A.woff2
-rw-rw-r-- 1 root root 5996 Aug 7 00:05 6xKydSBYKcSV-LCoeQqfX1RYOo3ik4zwmxduz8A.woff2
-rw-rw-r-- 1 root root 7265 Aug 7 00:05 font-face.cssasb → created an issue.
I am getting the following behaviour with 'auto_entitylabel' 7.x-1.x-dev from 2017-Aug-03 in combination with 'token' 7.x-1.x-dev from 2022-Jan-12.
Setup:
Node title is constructed from two text fields (First name and Last name).
In Token browser, I get two token candidates for this:
[node:original:field_name_first_txt] [node:original:field_name_last_txt] and
[node:field_name_last_txt], [node:field_name_first_txt]
I do not know what the difference of these two variants is.
I do not get token variants with dashes (-) instead of underscores (_).
Result:
With both token variants, as well O'Toole as O’Toole is encoded properly in node title.
This works only with the latest development releases (mentioned above). With the recommended releases, O'Brien was garbled to O'Brien, Ra'ad became Ra'ad.
I believe this issue is fixed in the latest dev releases. Can anyone confirm this, and if it is fixed, could we get a new recommended release?
Thank you!
Lucky me is running legacy PHP version 5.6.40-0+deb8u12… meaning that your workaround to use synonym[ous terms] without synonyms [module] worked like a charm. I think this can really help to avoid duplicate nodes when one has to deal with pseudonymous names or nicknames, misspellings, alternative spellings, transcriptions and the like.
And I guess I am beginning to understand what the problem of the synonyms module is (or at least my trouble with it). The logic to deal with synonymous terms sits mostly in 'proprietary' (synonyms friendly) widgets, and search and views implementations, and not where it (imho) belongs - in core. I think the more powerful architecture would be if every field would have a button "enable synonyms support", and Drupal core would have to deal with feeding terminological ambiguity to all default facilities like views, search and references/relations. It is absurd that the maintainers of a contributed module are forced to duplicate so much core funtionality 'just' to enable a feature that even more belongs into Drupal core than translations. For usability and data consistency, radical synonyms support would have incredible potential. Anyway, unfortunately we can not change this, and things are as they are.
So to summarize and answer my initial question: The 7.x-1.x branch does not only mimic Taxonomy synonyms as we are used to from D5 and D6. At least under certain circumstances, it supports entity references as well. However, in reality there are a number of obstacles (e.g. module incompatibility with the "Entity reference prepopulate" and "Prepopulate Create Node Links" combo), and limitations (e.g. Views filters integration for "Taxonomy Terms" and "Entity Reference" fields only) to deal with which might become a showstopper, depending on the individual use case.
Also I got to know the 'Views filters populate' populate module which allows to quickly build a workaround to use synonyms in views exposed filters without even requiring the synonyms module.
Devad, many thanks for your help, you have been awesome!
As I mentioned in OP, at ./admin/structure/synonyms I am getting a configuration page where I can, for example, enable the field "Synonymous name" in my node type "Person". At the path ./admin/structure/synonyms/node/person, I can enable the "Autocomplete wording" with a checkbox, and I can enable the "Select wording". The default autocomplete wording is: "@synonym is a synonym of @entity".
According to the documentation page for Synonyms 2.x → , this is the first configuration step which sets up a field to serve as synonyms provider. Then, in Synonyms 2.x there would be a 2nd configuration step called "Manage behaviours", and "Adjust the widget type". I do not have similar settings in synonyms 7.x-1.x-dev, so at this point I can not follow the documentation anymore.
If I set up a View with a "Content: Title" field and an exposed filter on "Content: Title", views searches only in the node titles and not in the "Synonymous name" field. I think the reason is because these two fields have not been conneced. The first step as described above enables the "Synonymous name" field as synonyms provider generally. Though there is no way to tell Drupal to use this synonyms provider for what. In this example this would be: Use the synonyms provider field "Synonymous name" as synonyms when searching on the Person node titles in a View.
Or to use another example which avoids Views: Use the synonyms provider field "Abbreviation" as synonyms when searching on the "Organization" node titles in an entity reference with "Synonyms friendly autocomplete" widget. However, this "Synonyms friendly autocomplete" widget has another side effect as it breaks or does not support the "Entity reference prepopulate" and "Prepopulate Create Node Links" modules (which allow to create non-exsiting nodes on the fly with a modal dialog). So as far as the "Synonyms friendly autocomplete" widget is concerned, I might be encountering a simple module incompatibility.
Ok, so where do I tell Drupal to consider the synonymous name field for the person node title?
This is neither possible at ./admin/structure/synonyms nor at the content type field definitions (e.g. ./admin/structure/types/manage/person).
Hi devad,
thank you for your reply. The example use case you are describing is pretty much what I was hoping to accomplish with Synonyms. However, I believe that the 7.x-1.x branch does not have this functionality. That's the reason why I asked for a confirmation as I might have overlooked something.
From what I can see in my D7 site is that one could use Synonyms 7.x-1.x to mimic the behaviour of D6/D5 core taxonomy where synonyms used to be a built-in feature.
What Synonyms 7.x-1.x - imho - can no do is what you are describing. There is no way I could find so far to tie an entity reference field to synonyms. I believe this functionality was added in the module versions for D8, D9, D10 or whatever comes next, but it is not yet available in the 7.x-1.x branch. But again, I might have overlooked something.
"Unable to import view":
Field handler field_data_field_druh_vztahu.field_druh_vztahu is not available.
Field handler field_data_field_vztahy.field_vztahy is not available.
Relationship handler node.relation_base_left_orientovany_vztah is not available.
Relationship handler relation.relation_base_orientovany_vztah_node is not available.
Relationship handler field_data_field_druh_vztahu.field_druh_vztahu_tid is not available.
Field handler field_data_field_druh_vztahu.field_druh_vztahu is not available.
Field handler field_data_field_vztahy.field_vztahy is not available.
Relationship handler node.relation_base_left_orientovany_vztah is not available.
Relationship handler relation.relation_base_orientovany_vztah_node is not available.
Relationship handler field_data_field_druh_vztahu.field_druh_vztahu_tid is not available.
Field handler field_data_field_druh_vztahu.field_druh_vztahu is not available.
Field handler field_data_field_vztahy.field_vztahy is not available.
Relationship handler node.relation_base_left_orientovany_vztah is not available.
Relationship handler relation.relation_base_orientovany_vztah_node is not available.
Relationship handler field_data_field_druh_vztahu.field_druh_vztahu_tid is not available.
Field handler field_data_field_druh_vztahu.field_druh_vztahu is not available.
Field handler field_data_field_vztahy.field_vztahy is not available.
Relationship handler node.relation_base_left_orientovany_vztah is not available.
Relationship handler relation.relation_base_orientovany_vztah_node is not available.
Relationship handler field_data_field_druh_vztahu.field_druh_vztahu_tid is not available.
Field handler field_data_field_druh_vztahu.field_druh_vztahu is not available.
Field handler field_data_field_vztahy.field_vztahy is not available.
Relationship handler node.relation_base_left_orientovany_vztah is not available.
Relationship handler relation.relation_base_orientovany_vztah_node is not available.
Relationship handler field_data_field_druh_vztahu.field_druh_vztahu_tid is not available.
Is there anywhere an explanation how this stuff is supposed to be set up?