Hello,
I think you should check out Backdrop CMS - at least they offer transition / migration / upgrade options
Transition: Come in from an entirely different framework (WordPress)
Migration: Drupal2Backdrop Export -> Import (moves data, updates database schema & variable names)
Upgrade: Drupal in situ (attempts to preserve existing database schema & variable names as much as possible)
It's not perfect, by any measure, but I don't think anyone else is offering anything like these options to Drupal 7 "refugees" like me.
Backdrop CMS Issue:
https://github.com/backdrop-ops/contrib/issues/859
graham leach → created an issue.
Thank you.
I'll get to work on the port now.
I will use this arena to let you know when it is done.
Respectfully,
Graham leach
graham leach → created an issue.
Add WHO and WHY sections to the description to give newcomers context regarding the applicability and utility of this solution. A couple of examples go a long way. Descriptive, but not explanatory is how we would term the current content.
Hello Everyone,
This solution worked for my Drupal 7 site. The entire breadcrumb (including the last item) is now click-able.
Hopefully this solution proves useful to someone else.
N.B.: I need this for my Administrative GUI (seven). If you need it to happen somewhere else, you will need to change the function prefix ("seven") to the name of the theme you are using.
Example:
function garland_breadcrumb($variables) {
For the seven Administration GUI theme,
In:
/site/themes/seven/template.php
As:
/**
* Override of theme_breadcrumb().
*/
function seven_breadcrumb($variables) {
$breadcrumb = $variables['breadcrumb'];
# 2024-10-16-GL Get the current page title into local variable
$local_page_title = drupal_get_title();
# 2024-10-16-GL Get the current page path into local variable
$local_page_path = drupal_get_path_alias();
# 2024-10-16-GL Construct current page link
$local_page_link = l($local_page_title, $local_page_path);
# 2024-10-16-GL Add current page link to breadcrumb
$breadcrumb[] = $local_page_link;
if (!empty($breadcrumb)) {
// Provide a navigational heading to give context for breadcrumb links to
// screen-reader users. Make the heading invisible with .element-invisible.
$output = '<h2 class="element-invisible">' . t('You are here') . '</h2>';
$output .= '<div class="breadcrumb">' . implode(' » ', $breadcrumb) . '</div>';
return $output;
}
}
graham leach → created an issue.
I just got this error, and resolved it, but in a very limited scope.
What happened with me was that I left a screen open overnight editing an entity (an Ubercart Product Content Type) with about 10 images associated with it ( used in Ubercart) that had had one of its images removed by someone else in the early morning before I arrived at my desk. When I updated the record (by adding a new image), I got the AJAX 200 error. This happened twice before I did any mitigation.
To mitigate the situation, I viewed the node, then attempted to edit it. I re-attached the new image and then moved it to the first position in the array using drag&drop in the GUI. I noticed at that time that the image that was formerly the 1st image in the array was no longer there.
I presumed AJAX 200 was some kind of error code, but it is NOT. It is actually a **success* code.
Confused and not really understanding the situation, I researched the situation. I read this:
https://stackabuse.com/bytes/fix-ajax-request-returns-200-ok-but-error-e...
To me, one of the most interesting parts of the article is this little snippet:
"...The key point here is that the error usually arises from a mismatch between what jQuery expects based on the dataType parameter and what the server actually returns. Understanding this is the first step towards fixing the problem."
What was happening with me was an obsolete record on my workstation was being used to update a changed record in the server. The parameter count between the update record send by my workstation (10 images in total) and the live record on the server (9 images in total) did not match, throwing the error.
In my case, the record was NOT updated on the server.
On a somewhat unrelated note, I have also seen this error (AJAX 200) in Views when clicking on "Update preview" to see the records pulled from the back-end database.
(...an answer from the future...)
It seems to me you are struggling with two separate problems.
1) Updates are not taking effect <- Cache Issue
2) Trouble changing the logo <- Drupal Logo Bug Issue
Updates are not taking effect
This can happen when the cache is not being properly cleared, so old settings are being loaded by Drupal.
This can be maddening and the source of this problem can lie at any combination of the L, P and D layers of the LAMPD model.
L: If your Linux services layer (memcached) is not properly set up, your caching will not work right
P: If your PHP services layer (php-memcache, php-memcached) is not set up properly, you can click on "clear cache" as much as you like and nothing will change.
D: If your Drupal layer (memcache) is not set up properly, Drupal will not be able to access the memcached daemon through the memcache and memcached PHP extensions.
I have found, in this situation, that the only way to really effective way to "clear cache" at the Drupal layer is to restart the machine, which is a rather extreme way of clearing cache. It's better to work your way up, moving through the installation of memcached (L), then installing the PHP memcache extensions (P). then installing the memcache Drupal extension (D). You will also want to install the Administrative toolbar, which makes accessing "clear cache" a lot easier. You might also want to install the external resource PHPMemcachedAdmin, which enabled the external monitoring of how Drupal makes use of memcached.
This is all covered in my upcoming book, W6H: Understanding Memcache
Trouble changing the logo
Drupal has a logo bug where if you change things in Appearance with respect to a logo file, the path to that file is destroyed and the file you uploaded is changed to "logo.png". This bug tripped me up too. What you need to do here is either:
a) Replace the stock logo.png in your theme file directory with your own logo. The stock logo should be at somewhere like /sites/all/themes/{theme_name}/logo.png
In my case, that would be:
/sites/all/themes/stability/logo.pngSome people don't like going this way because it over-writes the original theme files, which is a Drupal culture no-no.
If you feel that way:
b) Replace "logo.png" with the relative path to your uploaded logo from the base of your Drupal installation, which is usually something like /sites/default/files/{logo_filename}
In my case, that would be:
/sites/default/files/HPH-Lavender-Square-Logo-Clear-280x92-2024-01-27.pngIt may be that a more modern version of Drupal 7 has resolved the Drupal Logo Bug issue, but I find even with 7.101 the approach to the logo filename weak to say the least.
To help new administrators, what Drupal should be doing is exposing not only the logo filename, but also where in the filesystem it is picked up from.
This is all covered in my upcoming book, W6H: Understanding Drupal
Scenario: Production Website Loading an Ubercart Catalog Home Page (100 Products)
11 Seconds: Baseline
The expected timing given no acceleration were implemented whatsoever.
Measure(s) Purpose
Flush memcached Eliminate possibility of caching advantage
Flush Drupal cache Eliminate possibility of caching advantage
SET GLOBAL innodb_flush_log_at_trx_commit=2; Perform COMMITs on every transaction (safe)
6 Seconds: Post Memcache Oriented Measures Taken
In this phase, I implemented memcached in order to enable caching at the Linux, Apache, MySQL, PHP and Drupal layers of the LAMPD stack (LAMP + Drupal)
Measure(s) Purpose
Installed memcached General purpose OS-level daemon for caching
Installed PHP-memcache Makes memcached availble to PHP apps (like Drupal)
Installed PHP-memcached Makes memcached available to PHP apps (like Drupal)
Installed Drupal memcache Enables Drupal to access PHP-memcache
Installed Drupal memcached-admin Enables monitoring of Drupal memcached accesses
Installed PHPMemcachedAdmin Enables external monitoring of Drupal memcached utilization
3 Seconds: Post MariaDB InnoDB COMMIT Oriented Measures Taken
In this phase, I first validated the database engine that MariaDB was using (InnoDB) and then implemented a global setting that instructed MariaDB to only process COMMITs every 2 seconds instead of after every transaction. This introduces a (very small) risk of data loss should there be a (rare) power failure, where up to 2 seconds of data may be lost. A small UPS completely resolves this, making implementing this measure a no-brainer.
> show engines;
| InnoDB | DEFAULT | Supports transactions, row-level locking, foreign keys and encryption
> SET GLOBAL innodb_flush_log_at_trx_commit=2;
3 Seconds: Forced Reload
Here, I simply measured the result(s) of my work by repeatedly forcing a re-load of the Home page.
Measure(s) Purpose
<CTRL-F5>
1 Second: Simple Reload
Here, I simply measured the result(s) of my work by repeatedly re-loading the Home page from browser cache.
Measure(s) Purpose
<F5>
Hello,
This may be a sub-system (PHP) specific problem, not a Drupal-specific problem.
I myself had this problem until I installed the following PHP modules:
memcache
memcached
I had already installed memcached, thinking that was enough. NOT TRUE.
After installing memcache, performance improved dramatically.
# apt install php7.3-memcache
# apt install php7.3-memcached
NOTE-1: You may need to enable an alternative repository to install Drupal 7 compliant PHP (i.e. 7.3.x)
NOTE-2: Then, you may need to modify the above installation commands to suit your particular distribution
I have written an entire document regarding the above.
Here's a use case:
0) Enabling watchdog module bogs site down with thousands of db transactions per minute
1) Instead, Drupal message/error logging sent to SYSLOG
2) SYSLOG then becomes *flooded* with thousands of Drupal messages per minute
3) System administration becomes much more difficult due to Drupal flooding SYSLOG
4) SYSLOG is then configured to segregate Drupal messages into a separate file (/var/log/drupal.log)
5) Site administrator is NOT technical, but want to see "what is going on" with bot-based login attempts
6) Viewing /var/log/drupal.log then becomes a useful tool to identify bots "jiggling the handle" of the site
7) Site administrator can then use Administrative GUI "IP Address Blocking" to manually block IP addresses
8) Automated IP Address Blocking is a non-option as legitimate users trip automated measures on a daily basis
In the above scenario, being able to view the contents of /var/log/drupal.log would be pretty useful
Hello,
In my experience, this error is the result of insufficiently "defensive" programming.
It occurs when PHP is asked to process something that lacks a *countable* property because what it is being presented with is NULL.
Objects that are NULL do not have a countable property, which is the nature of the error/notice given.
In previous versions of PHP, the [notice] error was not issued.
But, as the quality of PHP improved, the [notice] warning was added somewhere in PHP 7.
Here's an example of what would trigger that error:
function element_children(&$elements, $sort = FALSE) {
foreach ($elements as $key => $value) {
}
}
Unfortunately, if the above function is passed a NULL array, a [notice] will be issued regarding the countable property.
To avoid this, implement "defensive" programming akin to what is being done these days to validate form input (i.e. assume the worst) to "sanitize" it:
function element_children(&$elements, $sort = FALSE) {
if(!is_null($element) {
foreach ($elements as $key => $value) {
}
}
}
Also, for those who might not know, using "&$elements" passes a reference to the variable as it exists in memory, not a copy of it. This is indicated by the "&" character.
https://www.php.net/manual/en/language.references.pass.php
For the purposes of this explanation you can ignore the "&" character in the function definition and simply consider it as "$elements".
I have written a little paper on this aspect/shortcoming of Drupal Core. If you are interested to learn more, contact me.
I implemented the code in the patch, but maybe I'm missing something.
Using VBO on my Ubercart (D7U3) implementation, I am able to check an arbitrary number of orders and select the bulk operation (set order status) but then I get a confirmation screen that says:
You selected the following 2 items
-
-
(CONFIRM)
The item details are BLANK, but the operation is successful.
This happens *regardless* of whether email confirmation is checked or not.
The line that generates this confirmation is in:
views_bulk_operations.module
At:
line 677
As:
$output = theme('item_list', array('items' => $items, 'title' => t('You selected the following %count:', array('%count' => $count))));
The parent function is:
function theme_views_bulk_operations_confirmation($variables) {
Apparently, $variables does not contain the information the screen output command needs to identify the rows being affected.
Here's the .info file for the version of VBO I am running:
# cat views_bulk_operations.info
name = Views Bulk Operations
description = Provides a way of selecting multiple rows and applying operations to them.
dependencies[] = entity
dependencies[] = views (>=3.12)
package = Views
core = 7.x
php = 5.2.9
files[] = plugins/operation_types/base.class.php
files[] = views/views_bulk_operations_handler_field_operations.inc
; Information added by Drupal.org packaging script on 2022-10-19
version = "7.x-3.7"
core = "7.x"
project = "views_bulk_operations"
datestamp = "1666149180"
For the Apache 2 Web Server to be able to process PHP, the libapache2-mod-php Apache 2 Web Server Module must be installed along with the PHP Scripting Language Interpreter (php).
While the libapache2-mod-php Apache 2 Web Server Module sits within the Apache 2 Web Server operating environment and configuration files, it is not a product of the Apache 2 Web Server Project. Both libapache2-mod-php and php are actually products of the PHP Project.
The reason for the existence of libapache2-mod-php has to do with the way Apache used to deploy scripting languages like PHP, Perl, C and many others. In the old days, scripts were processed by way of something called the Common Gateway Interface (CGI) which involved: (A) Launching an external processing environment; (B) Loading an appropriate script interpreter into the processing environment; (C) submitting the script for processing; and, finally (D) Receiving the processed script result back. This methodology incurred significant and measurable time and space costs.
Seeking a way to make PHP faster, the PHP Project took advantage of the modular design of the Apache 2 Web Server by producing a custom Apache 2 Web Server Module called libapache2-mod-php that embeds PHP within Apache 2 Web Server operating environment, avoiding the need for external processing and making PHP significantly faster.