@xaa
I put my "special" directories in the project root with ./web being a sibling. These are
.priv // private files
.sync // synchronization files
.trans // translations
.temp // temporary filesNote the "." -- one more level of invisibility.
The directories are set 755, and this works since 8.x appeared.
Ownership is set to webuser:webuser, as Apache runs as webuser instead of member of group www-data. In case your Apache is set to run as www-data, you will have to set www-data:webuser -- but there are many different ways to set up a server, so there's no general guideline. Just try your settings and see if there are issues in the protocol or in access.log
What information do you need? Please specify …
The backend is just the database, nothing "third party".
If you test it on the "bare bones install" you can tell whether search works for words with non-7bit-ASCII characters or not. And if it works for you, I'd be grateful to be notified. In my initial post I showed you how to spot the issue: Put the word "franzö" in any of the fields search is enabled for, then use the "search" box to search for "franz" -- it should yield the text containing "franzö". Next, search for "franzö" - the result should be empty.
This is how it works here, and I am sure you can do this simple test in less than three minutes yourself. Please let me know your findings.
No, I didn't upload anything, but just changed the background colors of certain areas to see the effect. In a certain combination of settings, the (default) white logo was put on a white background.
I've done a lot of work with my Bootstrap5 subtheme since 2021 and I can't tell what combination of settings lead to that phenomenon. As nobody cared for my report until 10 months ago, I can't tell anymore what happened two and half year ago with Version 1.0.0 …
@ravi kant
Please read my initial post and try for yourself. If things work now, all is fine. But if you have to make the changes you show in your screenshots, there will always be people having (unnecessary) problems. Better make sure things behave when the header area is left undefined. That's why I submitted this issue. I wasn't asking for a workaround, but a solution.
To answer your question: I never had a problem with this behavior, but I got accustomed to all the quirks and I usually dig my way out of a strange situation. However, I think things should work for Joe Average without having to subscribe a college course on how to use a certain module or theme in Drupal.
Added steps how to use a sym-link for to make Bootstrap icons available without having to copy files whenever the icons get updated.
@IGosh
Trying to see what can be done, I disabled the "Correct faulty and chopped off HTML" option.
The result?
<p>
Share <a href="#"><em> </em> </a>
</p>And even when I reverted to the enabled state, things didn't change any more. Seems I broke CK5… Is there any reliable editor which can be used instead? I'm tired of working with a "regular" editor for dev and copying code to CK5 hoping it will suffice this buggy implementation.
Why can't there be a "let my stuff alone" option, keeping the faulty guessing of an immature module out of the equation?
See my #13 request -- only 5 months later (#14) it was "recently fixed". Things simply take too long when CK5 is trying to make my code valid. So for Gods sake, allow to stop the nonsense for Admin mode …
Have a look to permissions. The Admin role has "Administer CAPTCHA settings" and "Skip CAPTCHA" set, and you cannot revoke these permissions. So I suppose there is no way to change this behavior, although I wonder why you want to be confronted with a CAPTCHA as an Admin who ist setting the rules? If it is for testing purposes: generate a second user with non-Admin permissions.
This of course will always be the save way to deal with permissions: create at least two accounts and do the admin tasks as admin (with a very cryptic and hard to guess user name) and the editing tasks as f.e. editor. Helps a lot to keep people from guessing your admin password, when they can see the display name on every article you put online …
This is the perfect scenario for the --no-update option.
Once you're ready to upgrade, you issue the upgrade command with the --no-update command. Then you issue individual requires, also with the --no-update command. Once everything is put in place, you issue composer update and everything happens miraculously just in time. I think this is also (somewhat) explained in the "upgrade 9 to 10" article I linked before.
First: If upgrade_status wants you to remove custom stuff, but you want to keep it, you may try to change dependency in the module.info.yml file. Adding <code>| 10</code> might do the trick. But save this for later, once 10 is up and running.
Regarding the line you didn't get: If I can avoid, I don't run trial and error with module versions by changing version numbers line by line. This is only the very last resort in case everything else fails.
From the report, I'd remove those six projects where the maintainers haven't released a working version yet and look for alternatives. Then I'd remove the four custom theme modules, and then run <code>composer update --dry-run</code> If this doesn't show any downgrades, I'd retry with option -W -- if there are still no downgrades shown, run the update.
Composer has plenty of smart features, one is running composer require with the option of --no-update -- the required module is put into the .json file, but nothing is installed. Using this feature allows you to deal with conflicting modules/versions. By postponing with --no-update you can work with various versions next time you issue composer update.
To put any changes in composer.json to effect, simply run composer update. But if you follow the hints from upgrade_status and the "upgrade 9 to 10" article, you should be fine soon.
All the best!
Upgrade Status is a Module which helps you upgrading to 10 -- highly recommended, as it knows which modules won't work with 10, so you won't try to run impossible upgrade routes (which may is the cause of the downgrades you see with composer).
There's a lot going on, and I would be honestly concerned about the downgrades in your Composer output. But dealing with a broken 9.x installation is far beyond my capabilities. I would
- get back to the state before the update
(by providing the then working composer.json and renaming composer.lock to f.e. composer.lock.bak to have composer.lock recreated) - Once working again, make a complete backup, including the database
- composer require drupal/upgrade_status
and try to get the site to D10. Dealing with an unsupported vs. 9 installation is like walking on broken glass -- it may hurt if you don't set steps carefully.
Hope this helps.
Not every installation is equal, and to get helpful support, you should tell at least the versions and modules in effect.
Maybe posting your composer.json will put everything in perspective in an instant.
However, have you tried <code>composer update -W --dry-run</code> already? If there are any error messages you should post these as well.
This is how it worked for me:
First, use composer to install the icons using composer
composer require twbs/bootstrap-icons
This puts the bootstrap-icons stuff into
../vendor/twbs/bootstrap-icons
Next I copied and renamed this folder to
/web/themes/contrib/bootstrap5/dist/icons
Now you have to edit bootstrap5.libraries.yml:
base:
version: VERSION
css:
component:
…
css/components/icons.css:
weight: -10
…
global-styling:
css:
theme:
css/style.css: {}
dist/icons/1.11.0/font/bootstrap-icons.css: {}
To show the icon using CK-Editor5, you cannot use the <i> tag, as CKE5 zaps it. I went with
<span class="bi-globe-europe-africa display-1 text-danger"> </span> <br>
instead - voilá:
@ressa, I very much appreciate your attitude. Glad if I can be of help with this -- let's see if I can still remember. I'm going to edit the initial post per your suggestion. Have a great day.
Thanks, @ressa. Seems the Token module was missing -- makes me wonder why simplenews doesn't require it in the first place?
And even now, when everything works, the token reads [simplenews-subscriber:field_firstname] without the :user part your see.
Oh, those Gremlins …
Found something still:
## INTRODUCTION
This is a very non-prescriptive vanilla Bootstrap 5 theme
with simple configuration. It can be used out of the box or
as a subtheme for creating very flexible web designs with
minimal changes (just override Bootstrap 5 _variables.scss
or this theme's _variables_theme.scss and recompile css!)
Sadly, there is no _variables.scss any more. There is _variables_bootstrap.scss and _variables_drupal.scss, in either contrib/bootstrap5/scss or custom/b5subtheme/scss.
Thus the line in "Introduction" won't help anybody.
I suppose this line
if $programname startswith 'drupal' then {should read
if $programname startswitch 'drupal' then {
OK, as promised in #63, I investigated the issue (at least as how I was affected) and I was right with my assumption. To help you to understand the issue, here's the background of all this:
Apache runs as user: www-data and group: www-data. This work in small (dev) environments, but not in public server hosting environments, as you have top protect clients from getting their data accessed by other clients. Hence every instance of Apache starts as root and once the proper vhost is determined, it becomes that user -- quite common f.e. 'web1'. Once files are written by Apache, they have [siteuser]:www-data as owner:group attached.
In shared hosts, the server admin put everything in order, but if you have set up your own Apache on a local machine, trying to use that thing to work an several websites, you're likely to also set up vhosts. Whenever you work within such a virtual "client space", you should become the proper user, web1, f.e. When you (as web1) create a file (touch myfile.txt) it will have web1:web1 as owner:group. If you run drush in this webspace, it will run as web1:web1. If you access the site through Apache, it will run as www-data:www-data. And then drush will complain about missing file access rights …
Now let's solve the issue (if you use Apache2, of course). To make use of this recipe, you have to have root/sudo access to your webserver.
Check if Apache has mpm_itk_module installed (# apache2ctl -M |grep mpm_itk)
If mpm_itk_module is missing
check if the mod has been already installed: ls -lha /etc/apache2/mods-available/ |grep mpm_itk
if it's there, enable it using a2enmod mpm_itk.load, then restart Apache (on Debian/Ubuntu et al.: systemctl restart Apache2)
if it's NOT there, search for mpm-itk and how to install it on your version of Linux/Apache2, … and then restart this procedure.
in any case, check if it's enabled and running using (# apache2ctl -M |grep mpm_itk)
When it mpm-itk is working, use your favorite editor to edit /etc/apache2/sites-available/[your virtual host file] (f.e. web1.conf)
There should be a line
DocumentRoot "/var/www/[siteuser]/htdocs/[drupal project]/[web base]"
Add this line beneath DocumentRoot …:
AssignUserId [siteuser] www-data
Repeat for every in this file.
Here's what the final thing look like with a server 'playground.lan', a siteuser 'web1' and Apache being in group www-data:
<VirtualHost [your ip]>
ServerName playground.lan
DocumentRoot "/var/www/web1/htdocs/playground/web"
AssignUserId web1 www-data
Once you're done, save the .conf file and check it's syntax using apache2ctl -t
If the result is Syntax OK, restart Apache.
In Drupal, clear the cache using the UI, and now drush should work without complaining about missing file access permissions.
Hope this helps your issue.
Running two servers, the production server runs on Debian 10, recently upgraded to 11, and dev runs on Debian 12.
The setup of both systems is (almost) identical -- Prod srv configures sites using a site management tool, dev srv was configured manually. Everything Drupal works identical at first glance, but there's one major difference which causes the problem reported above. First some background information:
File permissions are the same on prod & dev, following the drupal file permission guideline, set by some fix-permission.sh script
drwxrw-r-x [siteuser] [apacheuser] [dirname] and
-rw-rw-r-- [siteuser] [apacheuser] [filename]
On production, Drupal changes ownership on directories and files to [siteuser][siteuser] when writing.
On dev, the ownership is set to [apacheuser][apacheuser].
By this, files become inaccessible for [siteuser] -- and as command line operations such as drush, are run as [siteuser], file access errors occur.
The same holds true for any directory or file written by Drupal, such as images and directories in public://
As the only difference between these installations is the setup of the vhost structure in Apache, I suppose there's the cause of this problem is found. Sadly I lack experience in setting up Apache2 sites, hence I have to try to find the differences between the site-available/[siteuser].conf files.
However, I think this is not (directly) a Drupal problem, but an issue with the most basic settings of Apache vhosts.
The workaround is to add [siteuser] to the group www-data.
# sudo usermod -a -G www-data [siteuser]
I'm going to research the proper Apache settings, but for the time being this seems to work.
Thanks for the patch #7, @sarwan_verma, works for me.
Added a line + description as how I fixed file permissions on robots.txt after having fixed 129 misconfigured robots.txt files on my server.
Just to let know who ever works on this:
I did a clean install of D10.2.2 + Commerce
In Commerce I tested several ideas and later removed these product types.
Now I get this error every time I change (any) permissions on any user:
RuntimeException: Adding non-existent permissions to a role is not allowed. The incorrect permissions are "create default commerce_product", "create test_goods commerce_product", "delete any default commerce_product", "delete any test_goods commerce_product", "delete own default commerce_product", "delete own test_goods commerce_product", "update any default commerce_product", "update any test_goods commerce_product", "update own default commerce_product", "update own test_goods commerce_product", "view default commerce_product", "view test_goods commerce_product". in Drupal\user\Entity\Role->calculateDependencies() (line 207 of [site]/web/core/modules/user/src/Entity/Role.php).
Just googling for "Drupal RuntimeException: Adding non-existent permissions to a role is not allowed." yields plenty of such issues, reported with various modules while the problem appears to be in core.
However, the set permissions are stored to the role, so I assume the rruntime error occurs after sving permissions (still on 10.2.2, not 11-dev).
This is the fix -- add the dependency to -core/drupal and everything works as advertised.
elevate_image_zoom_js:
version: 1.x
js:
js/elevate_script.js: { weight: -1 }
/libraries/elevatezoom/jquery.elevatezoom.js: { weight : -2}
dependencies:
- core/jquery
- core/drupal
The js error seems to be fixed:
Makes me wonder why
composer require 'drupal/magnify:^1.0' -W
didn't install jquery_ui …
It's very human to forget the easiest ways to solve a problem. The focus is put on making things work, and every other obstacle makes it even a tighter focus. In general, it's best to quit, get a relaxed sip of tea, doing nothing for at least two hours. Once you get back to the problem mentally after the pause, the solution most often will hit you like a spark -- distance isn't a waste of time, but instead a big time saver.
However: to become proficient, you have to dig through each and every thing which may keep you from completing the job. This is how you learn to deal with this sort of problem which can become quite useful when you live site goes wild.
So no, not a dummy, but a very valuable lesson learned -- only mistakes hold the potential to rise to a higher level.
That issue with default.services.yml striked me every now and then with Drupal version 9.x, together with default.settings.php. Sometimes an update needs to overwrite these files and as far as I remember the access rights of the containing directory (sites/default) need to be changed. Maybe adding write access to the group or something like this.
Anyway: Glad you made it, and all the best for your Drupal endeavors.
So please do me a favor BEFORE doing any of the steps below: BACKUP composer.json AND composer.lock. If you have access to the shell, the easiest way would be
tar -czf composer-date.tar.gz composer.json composer.lock
Done that? Then continue:
You still know which versions are current. Open composer.json and search for the version numbers. If Drupal 10 is pending, you'll find lines reading
"drupal/core-composer-scaffold": "^10",
"drupal/core-project-message": "^10",
"drupal/core-recommended": "^10",
and revert them to the version stalled "^9" should do.
Try composer update -W --dry-run
If you see errors, set the version number in composer.json again, rerun composer update -W --dry-run
Once you don't see any errors, you're done.
After having some sparkling wine, backup the site including the database, and once again the working composer.* files and then proceed to my posting from yesterday, above.
All the best!
… todo the job. Allow for the upload of modified logo-images and supply data-fields for switching times and use the cron job to deal trigger the module to output the logofile with the set name to the location where the theme is looking for it. Should make for a nice exercise in coding modules … If you have rather tight cron runs, you could even have a dim version of the logo after sunset, and if you use the API of some of the wx-providers you could show the logo in bright sunshine or in deep snow.
The "… field Drupal has thought for…" is only a default. You are invited to make it a much more creative field than "Drupal" ever could think of.
Ans sadly, your client seem to be such an exception -- no business I dealt with in the past 40 or so years wanted to change it's logo more than once. To put the logo stuff to the theme makes a lot of sense, and it should be out of question. Better think about a valid workaround.
If you do not "upload" the logo-file in the theme configuration, but instead upload in f.e. public://media/logo/, your client will now exactly what file to change when the time comes. Either provide your client with an FTP upload or install IMCE, then he can upload the logo file(s) to the directory.
Example:
To help search engines identifying the logo as such, name it properly, let's say: logo_of_some_firm.png
Upload this file to public://media/logo/
In the theme configuration, refer to the logo using the path public://media/logo/logo_of_some_firm.npg
Now the client needs to name every future variant of the logo the same. After uploading to the proper directory and a cache clear everything should be as intended.
Caveats: Your client has to make sure the logo has the same dimensions as the original. You can of course make sure that the output size of the logo will be within save borders, but it doesn't make sense to upload a 5 MB image file to display a 200x200 px image. And you are of course restricted to a single type of image file. I prefer .SVG, as vector art scales much nicer than with any bitmap format, but if your client can only handle bitmaps, you have to use the format which will work best for him -- possible .PNG, as it allows for transparent pixels.
Sorry, I'm confused by your post. Do you really want URLs which are listed by a search process on some of your pages to be included in the sitemap? Have you ever considered XML Sitemap being a search process you can configure to put all the URLs of your pages into sitemap.xml?
If those URLs point to a remote machine, the receiving search engine will pretty soon flag your site.
To get more elaborate answers, you should provide more elaborate questions ;)
Your composer has this line
"drupal/social_auth": "^3.0",Maybe you should either install upgrade_status to get a good overview of issues when you're not used to deal with composer, or you try to bring the existing 9.5.x installation modules to the latest version(s) by running composer update -W --dry-run
If the --dry-run doesn't complain about anything, omit it and run composer update -W
If drupal/social_auth doesn't get updated, you can require its update during the updating process with
composer require "drupal/social_auth:^4.0" --no-update
Once you issue composer update, all the updates which got postponed by --no-update will be considered by composer.
If you haven't yet, find the page "Upgrading Drupal 9 to 10" on drupal.org and follow the procedure to the comma.
So if you have D9.5.11 and drush < 10, this is not ideal. Maybe you should install drupal/upgrade_status to get better hints.
Once
- status page
- available updates
- upgrade_status
- protocol
do not complain on anything, you may proceed to actually update 9 > 10 -- and there's a perfect manual for this on drupal.org, just google drupal how to upgrade 9 to 10
Pay attention to the nice --dry-run option of composer, as well as the --no-update option (which allows to have several conflicting version in the same update queue) and composer is doing a very good job to solve this sometimes tricky part once you issue composer update
In any case: search for the proper guidelines on drupal.org, and don't take any shortcuts.
… it helps -- I lack MAMP experience, so take it with a grain of salt.
However: You should install composer first, and from then on you install everything using composer.
If you follow this general rule, things should work automagically.
After composer require drush/drush you can even install modules (f. e. custom projects) by drush en <modulename>
The error message seem to indicate the logged in user is not the system administrator.
I think you're looking at a symptom, not the cause. If any possible I'd set up the site following the guidelines on drupal.org to the comma.
And as always: do not take step 2 when step 1 hasn't yet positively evaluated.
My 2%, ymmv.
I haven't tried, but it should work along these lines:
{% set d1 = date1 | date("w") %}
{% set d2 = date2 | date("w") %}
{% set diff = date 2 - date1 %}
{{ diff | date (<whatever format you want/need>) }}What this does:
First you have to convert the dates to Linux "seconds since 1.1.1970" format (should be parameter "w")
Then you can subtract these two numbers.
Finally you use the date() functionality to display the number of seconds since 1.1.1970 in a more resonable format. The format parameters are the same as in PHP date documentation.
Possible enhancement:
If you don't know which date is earlier, you may get negative values as a result. Which could work, but if you only want positive results, you may look if there's a twig | abs() filter. I hope somebody can shine more light on this.
Thanks, seems to work with a clean 10.2.1 installation.
Well, seems the token field issue has't been resolved in years, so I'm not going to give that a try. I rather write module which puts all the filled in fields from the subscription form in the right order to make for a single valid greeting field … Thanks for the heads up anyway, maybe I get good enough with coding to tackle that issue in the token module - but please don't hold your breath.
And there's one more thing …
The PHP Exception also occurs when I try to unsubscribe a list of subscribers. If there's a "non-subscribed address' in the list, WSOD occurs. This is quite a problem when having to unsubscribe 800 out of 4800 subscribers …
Uhm, I'm sorry -- it was busy months, and I totally lost track what site I was referring to. Your assumptions however do not apply -- it was a site from scratch, but after upgrading so many sites to 10.x, I cannot remember which site it was. Maybe I should put the internal ticket ID to my issue reports ;) Happy Christmas, and just ni case: I'm still trying to get a manual together, but it needs time to test all the functions available (or not available …)
I understand things work for you by now, but your explanation doesn't work for me. You cannot simply add a parameter (like tid = 1) to a field name as in field_tag_1 to display the term of tid == 1.
I rather assume the machine-name of your field 'tag' eventually became 'field_tag_1' as a field of name 'field_tag' already existed.
… you have to clear the cache to take changes in twig to take effect?
Is [Bootstrap] the way to go (and if so, in simple terms, why)?
It's a very popular way to go. The Bootstrap5 theme makes for a very got start ans it allows you to create a subtheme effortlessly. There's lots of tutorials around, and of course there's a very well made site teaching you every aspect of using Bootstrap:
https://getbootstrap.com/docs/5.3/getting-started/introduction/
As I already said in my previous reply: Thats what install modules are for. Instead of creating blocks and stuff through the GUI, you can write a module, which contains just the things you want to have set for the theme. Entity types, like content, paragraphs and blocks come to my mind. Once such a module works well, it's also a means to distribute upgrades to configuration in case it's needed. This of course depends on the complexity of your site setup. If you have the need for a dev server, a staging server and a production server, you cannot do without this, as you have to have a means to transfer all the changes you made in dev to stage and in case things get release, to production.
If' this seems to exceed your needs, as you always work straight at the production (remote) server, you'll be happy you implemented a stepped development if your internet connection is down for a day or so (I had a broken line for two weeks, when some guys flooded the cables while cleaning a bridge).
This is getting more complex -- let's see if I can all your questions:
Maybe the name of the theme is somewhere in the db, but it's not written in stone. That's why I suggest to install themes in parallel, if done properly, it should be easy to switch between themes. If it isn't easy to switch, I'd consider the theme structure to be flawed.
The "track outside the directory of the theme" gets generated at install. But this only of interest to Drupal and if you install the same theme using different names several times, Drupal won't comply. It just needs a machine name and a route to know ehere which theme lives.
If you uninstall a theme, which settings are you going to lose? The usual settings, like logo, favicon, maybe color scheme? That's correct, this form you will have to fill in again once you change machine names. Does the part of "set of blocks for a theme" mean, you're concerned about your block layout for that theme? Then you're right again, if you uninstall a theme, it's block-layout will be dumped as well.
Now for the good things in doing your own theme: You can write a module which installs all the blocks and content types and paragraph types and block types your theme may need. It's not exactly rocket science, but boring. Once the thing is written, you can move your theme and all it's dependencies wherever you need to…
The 'grep' part is a different thing, we're talking bash here.
If you get into the theme directory, you'll notice lots of files with names beginning with your theme's machine name. Of course you cannot ask grep to search for 'machine name', but for the machine name itself. Given your theme's machine name is xyz23, you'll have a xyz23.theme file around. Using grep you will find all files in some directory using
grep "xyz23"
However, if you want to change all your xyz23<whatever> files, you'll need find with the exec option. Then you can use find as a search, and every positive will be processed by the command you issue in the 'exec' part -- usually a mv statement, where you instruct the file to be renamed to the new machine name. Find is pretty neat, as it works recursively and you'll be done in an instant. However, you also have to search and replace all the theme files where you define functions, like in <theme>.theme
If you're a hard core bash user, you'll use sed for this task, but there's nothing wrong to use the editor of your choice to search and replace.
If your server supports webdev, you should be able to make the server drive a webdev target you can access like a regular drive from your local machine. If you're using a Mac, you can do the rename step using finder, which is less intimidating than dealing with proper search terms on the command line…
As far as I can see here, that's all you need to convert between machine names.
Hope this helps
The theme of D10 is as removable as the one of D7, D6, D5 or D4.7
This is the beauty of Drupal, and that's why I still use it - since 2006.
Comparing the poor Olivero to Apple or Google is in the vicinity of arrogance, God bless you. And to proclaim that "everybody liked …" is a statement only a fashion addict will make.
If you don't know him, google for Jakob Nielsen and hopefully you'll get how Google is still running on the same principles of usability design Nielsen proclaimed by the end of the 90s, based on the general ideas on design which came a long way. Modern designs have their foundations still in the Renaissance.
Just because technical possibilities will allow for funny gimmicks, which usually age fast, doesn't mean these gimmicks are the "design" of the website. This is eye candy, and as you say, obsolete the moment it's created.
Oh, and there's one more thing:
“Design is not just what it looks like and feels like. Design is how it works.”
Steve Jobs
It may be that for an online store what I need is a SaaS solution
Just give it a try -- most SaaS providers offer a trial version or even a free month or so.
All the best to get your biz going!
Well, in my .theme file I also have lots of code, and there's a custom theme-install-module, which use some API calls. If these change, I have to change this, too. Right now there's still a lot of deprecated PHP which needs to be phased out.
Regarding your "same machine name" concern -- it shouldn't be much of a problem to use an intermediate machine name and do a search and replace once you feel confident about the new theme. Just make the intermediate name cryptic enough to not create false positives on search.
What do you think makes your current theme so special that you have to stick with it at all cost? If you want to, you'll learn SASS through a weekend, and you'll need a week to convert your "Frankentheme" as a subtheme to Bootstrap5. Double the timeframe for testing and tuning, and double again for safety reasons. So in a month you're up and ready on a solid base with all the features you have today. This time is well used, as it will avoid weeks of headaches while debugging your current theme after an upgrade crashed your site. Been there, just converting my last client to a Bootstrap5 based subtheme of mine.
If you had asked me what I'd do in this situation, I'd answered either Drupal + Commerce or Drupal + Webform -- except for the cart thing, everything you asked for is doable with Drupal + Webform. Maybe Drupal + Basic Cart https://www.drupal.org/project/basic_cart → + Webform will do.
You're being shy of modules seems to be the biggest hurdle to me. Accept modules as options which help you to tweak your site to the shape you need. If you don't like modules, write the code yourself. You don't need modules, they just make life easier. I wouldn't start any, even the tiniest site, without at least 10 contrib modules (from pathauto to honeypot, there's plenty of suggestions you will find when googling "drupal 10 must have modules).
The great thing about Drupal, I have to stress this, it's not a CMS. It's a framework which happens to have a CMS put on top. There's also "headless Drupal", if you want to google that, which is Drupal with another CMS, like Wordpress, sitting on top of the framework.
Regarding your exposé: Currently I maintain a Drupal Commerce store which has no less then 69 contrib modules installed and I do not feel uncomfortable at all. So better scratch #3 from your list. Everything except the cart thing should be possible using Drupal + Webform. Basic Cart may be a cart solution for your needs. However, I would use Drupal Commerce which will help you with stock keeping, If a product isn't on stock, it shouldn't get into any cart imo. If a customer is interested in a product which is out of stock, use webform to allow for an easy inquiry, but don't stretch the sales process by initiating long winded conversation exchanges (last point in your list).
I still hesitate to recommend anything to you, as from your background I'd say you're facing a very steep learning curve for at least the next 6 months. If you're willing to go this way, consider a Drupal + Commerce solution -- it does everything you want and it can be installed in a very short period of time. Then the fun may begin, and you and your cousin can work your way through Drupal Commerce. Allow plenty of room for errors, don't shy away from roll backs and restarts (always have a fresh backup of your site at hand) and within a month or two you should have an idea as how to proceed. One word of warning, though: Stick with the English version of Drupal Commerce for the back office part. At least the German translation makes things very unintuitive.
Given your relation to the taxonomy is defined by a field named field_tags, you'll do the following:
- make your view based on fields (not content, teaser, …)
- add all the field you want to display to the list of fields, including the field_tags
- add a global field "user defined text" to the view (it's been called "nothing")
- exclude all fields except "nothing" from display
- In "nothing", start with this code
{% if field_tags is not empty %}
<h3 class="topic-{{ field_tags }}">{{ title }}</h3>
{% else %}
<h3 class="topic-unknown">{{ title }}</h3>
{% endif %}
You need to define in your .css what these classes shall do.
Beneath these first lines, you put all the other fields you want to print, in lines like these:
{{ body }}
{{ field_name }}
Of course you can style all those fields by using HTML tags, like in
<p class="lead">{{ body }}</p>
<p class="important">{{ field_name }}</p>
Have fun!
Favorite by what? If you need a small store with not so many sales and not so many products, Shopify is pretty OK. However, if you have special needs, it will become pretty expensive when you have to pay for extensions. A special case I had to deal with: A client of mine does business with a customer which uses OCI punchout for payment. With Spotify, his would cost 99 USD per month. With Drupal Commerce, it's free. Basically, I had to make some changes, but you know what I want to say.
To me, it depends on what you want to accomplish. Do you want to built sites for your clients, or do you want to administer sites? Are you a coder, or are you an implementer? If the first, learn HTML, CSS, SASS, JavaScript, PHP and stick with Drupal -- it's by far the most mature framework you can get. However, it's Open Source and you are required to deal with issues. There's nobody who will give you any warranties and in case your client's site decides to die in the middle of the night, it's you who gets called, and there will be nobody answering your calls …
If you want to become an implementer, do your research as how which products play nice at what cost. Be prepared that the smother operation will cost you money, but you have the luxury that somebody will answer your calls, depending on the support package you chose to buy.
"als" -> "also"
And yes. Magento has lots of modules to offer, some are free, some are very expensive. If you want to go Magento, you'll need at least 2000 USD per month in whatever form -- your own time or paying for support and maintenance. Operational cost (maintaining content) comes on top of this. Magento installations I'm aware of sold for 60k, maintenance cost not included.
Magento is a product on it's own, yes, but it is like Drupal a core product you can (have to) enhance with modules. You can still wrte your own modules, but this is beyond my expertise. I just had to deal with the "Drupal site of Magento", the CMS part, and it was a nightmare :)
Regarding converting content: There's no way you should set up a store be entering products in a GUI, except for very small stores. If you have let's say 2000 products which ship in five different sizes and 8 combinations of color, you end up with 80 000 SKUs/product variations.
As it will be too time consuming to calculate everything with every remote request, you have to have all those products in a table, and that's why you build a store in a local spreadsheet, and import this in whatever format to your store. This way you will never have an issue converting between stores, you just have to make sure you have the right data structure for to import in the next store …
The most interesting part -- which I think is mostly overlooked by many store builders -- is how you can get the attention of your customers on a certain product. That's where more sophisticated strategies come into play, faceted search, tracking user behaviour, what have you. This needs a very beefy server, which also adds to the operating cost. Generally speaking, you will need as much money for your online store as you would for a nice shop in the city of a decent town, and that's why some Magento stores are said to cost in excess of 80k per month… It's not Magento, it's the idea of an online store. Whether you use Drupal Commerce (which easily compares fine to the free version of Magento) or anything else: If you earn money from the store, you will have to pay for it substantial money in one way or the other or even in both. There is no free lunch …
The token [term:id] is a place holder for the tid, but it doesn't convert in every field. I.e. it only expands if so stated beneath the text field…
If expansion is not available in the field where you applied the token, you'll see the token as you do, verbatim and sanitized.
Sadly it's still unclear to me, what you're trying to accomplish, an in what context. There are so many situations where you want to write such code, but the solution may be different for every single case. All I get is you want the Term ID to become a class for the display of the title. But it's still guessing under what circumstances your try this -- can please give more detail? I.e. which kind of content does the view show, what is the relation to the taxonomy term you want the id from, etc.
But still one remark:
As commercial designers, to be successful, we have to deliver a design that appeals to the client (in addition to being functional). There is no way around that.
The word "client" is the problem with me. I rather want my designs to appeal to the client's customer, as this will generate revenue for my client and even for me in the long run.
The answer to your question is a load and clear "Yes", but sadly this doesn't help if you don't know who your "potential customer" is and how he anticipates the quality of the product by experiencing your site's design.
Don't let technical issues limit your options. Instead, try to find a theme that fits your needs and has world wide adoption. Bootstrap5 comes to my mind … Then purposefully craft the design for the issue at hand, and then team up with the maker of the theme to iron out the wrinkles, if there are any.
The perception of design is a very subjective thing.
Only when you ask somebody without any formal training on design. Most people confuse "decoration" with "design", which ultimately leads to "fashion". Another confusion may be "style", which only reflects attitude.
Good design is timeless, as it makes sense. And sense doesn't change with the wind …
Olivero is a mishap, simple as this. It holds no appeal for Joe Average, hence it won't draw any more users to Drupal. It holds no value for a seasoned themer, and it's not very friendly for a screen designer. It's best described as "You get what you pay for", the most basic UI, nothing to wrote home about. Maybe it was "design by committee", and most members of that committee have been coders, lacking any vision as how to use screens in the second decade of the second millenium. Building sites and "User Experience" since 1995, I never stopped wondering what may have hit people to come up with something like Olivero as the default UI for a well built CMS/framework in the first place.
But as I said above: It's moot to discuss, just get rid of it right after installation and replace it with something way more usable for your purpose asap.
Simply put: Don't use Olivero. I get rid of it just after the installation has completed. There are lots of more versatile base themes you can build on from.
SASS has a lot of features, but before you start with mixins and variables, make yourself comfortable with the structure of writing SCSS style sheets. It's not that much different from CSS, but way more elegant imo. Given you're using Bootstrap, which has lots of classes at your disposal, you can write f.e. in your TWIG
<h1 class="mySuperLargeHeadline"> …
and define the SCSS class like
h1.mySuperLargeHeadline {
@extend .display-1, .text-warning, .fw-bolder, .pb-3, .border-warning, .border-bottom;
}
This will assure consistency across the whole style, because you won't mess with arbitrary values, but reuse whatever Bootstrap has already to offer. This will help you to write cleaner and more reusable .html.twig code as well … In case you need more than this, mixins and variables come into play. So yes, I'm quite sure you'll love SASS after tinkering with it for an afternoon :)
When I'm about to compare themes side by side, I prefer to set them up at the same installation. Basically, I first create a clone of the site to be upgraded, then I install the other theme on the clone and do what it takes to make both themes work on the clone installation. Once I'm happy, I'll can the new theme. At this stage it's easy to change the theme's name and it's machine name wherever this has to be done.
Then I may strip remove both themes from the clone and install the packaged theme I created. If this works as intended, it's easy to put that new theme on any installation which might require it.
I cannot say for sure whether you'll be happy with B5+subtheme, but I'm almost sure you will want to start over once you learned how to handle B5, SASS, CSS, and your subtheme. Enjoy the ride ;)
First of all, Drupal isn't a CMS, but a very clever framework. It happens to look like a CMS, but that just makes for an easy start. Magento isn't a CMS at all, it's a e-commerce solution which needs a CMS front ens to work properly. There are some CMS like options, but nothing to write home about. Magento als needs (sometimes very expensive) modules and is rather cumbersome to set up. After a few installations with then Ubercart I created some stores using Drupal Commerce, but this is a rather steep learning curve. Shortly put: if you're not a coder, chances are, you're not going to be happy.
In any case, don't hope for a "one thing does it all" product -- especially e-commerce is a very complicated matter if you think globally, and this is where Drupal Commerce shines: it sits on top of the same framework as the CMS you know already, which makes it easier to understand.
If you want an easy to use e-commerce platform, better have a look at some SasS product, like WiX, Shopify, or what's popular in your part of the world.
Actually, you don't need to code SASS is you don't want to. There's always client.css where you can put your regular css stuff, if you wish to. However, SASS is nothing more than CSS on steroids, and it's quite easy to learn, if you know how to write CSS.
Gisle summarized all the benefits using Bootstrap5. To answer your question:
So, before making several steps back to replace that theme with something else, I would like to be fully conscious of any good reason for such a painful regression.
I'd say:
- It's very easy to have two themes co-existing -- install Bootstrap5 and switch between your theme and B5
- If you think B5 needs to be customized, make a subtheme. Or better yet: have B5 make a subtheme for you (in the settings page)
- Copy your code to the subtheme files as needed.
- The sooner you start, the sooner you're done.
As I had the same problem to solve when upgrading a dozen or so sites from D8 to D9, I chose B5 and I never regretted. Even the upgrade of these sites to D10 was a breeze, despite other Bootstrap based (licensed) themes which gave me big headache and took days to upgrade from D8 to D9.
So by all means: give it a try and test B5 for yourself for a day or two -- I think you'll like it, but of course, ymmv.
It's always good to provide at least some information if you want help in getting things to work.
The statement on the project page of Olivero tells the full story: As the project was integrated in the standard Drupal distribution, the project will not receive any more updates, but Olivero in core still will. Hope this helps.
run drush version
It should read > 10 (11.6.0 here)
Then you should be able to run drush config:export without changing any settings.
Problems I've seen so far: Running composer drush/drush doesn't necessarily install the version of drush you're intending. Make it drush/drush:^11 and you'll get most recent version 11. I had issues with drush 12, so for the time being I stick with 11 and it works fine.
Depending on your access level at the command line, you may execute a different version of drush. I was pulling hairs for a while in such a scenario, where running drush in the wrong directory caused a different version to launch. Make sure you run drush version in the directory where you intend to use drush.
I also encountered a access rights problem on OS level. drush had an issue accessing a hidden subdirectory because of either missing access rights or wrong owner:user settings.
As you say you have a long time installation, always make sure you access the right PHP, too. My current server provides PHP 7.x on system level and PHP 8.x on user level, which causes issues when running scripts as root (which is bad behaviour, but …).
Generally, you shouldn't mess with the database and/or .yml files. There are tools to solve all (at least of my) issues, especially access rights within Drupal. I also upgraded lots of vs. 9 sites in the past weeks, and although there where plenty of issues, all got resolved without touching any configuration files or records. And finally, drush can't do much more in the upgrade process than the UI can do. So there's no immediate need to have drush. However, I would recommend to install upgrade_status before attempting to upgrade to see possible pitfalls.
Hope it helps you to get your site going.
Reading through the code, I found:
In CartProvider.php
/**
* Helper.
*/
protected function shouldUseParent() {
if ($this->currentUser->id() == 1) {
// Admin never gets that.
return TRUE;I made it a habit to have at least two admin-accounts on sites I administer. So a uid of 1 isn't exactly representative for all administrators. People could as well delete the #1 admin just to avoid any guesswork attacks.
I also faced this error when duplicating a site on the same server in the same webspace (i.e. cp -rpa 9 10)
After checking and rechecking the config files at every level, I remembered that things are slightly different when you run a multilingual site which auto selects by the TLD. After creating a .com subdomain paralleling the .de domain, everything was fine again.
So be aware if you clone a multilingual site that you have to have a paralleling URL for every other language TLD. In my very case this was
https://10.xyz.com -> redirecting to https://10.xyz.de/*
Hope this helps if the above hints don't work for you …
Pardon my ignorance to the Closed state, but I don't want to clutter the other thread with noob questions:
a.) Yes, I'm wiling to help, but I have no idea as where to begin. Could you point me to straight and consistent information as how to help?
b.) Would it be possible to change the module's name in the process to commerce_oci_punchout?
"checkout" isn't used for OCI, and possible renaming the module would attract more people to use it.
c.) from my last encounter I remember the admin UI isn't exactly attractive -- would it make sense to think about this to help non-coders to configure the punchout?
Great -- and where/how do I pass a "clear" option?
@barbarae -- I think you should direct your request to " Bootstrap Barrio → " which is a different theme, this is "Bootstrap5"