Apache Friends Support Forum

Gutenberg’s Project Leadership Sits Down with New Outreach Team to Discuss Problems with the Site Editor

Brian Coords has written an interesting article on WPTavern - concering the FSE-Program and the Site-Editor (see the link below)
https://wptavern.com/gutenbergs-project ... ite-editor


What do you get when you put a handful of outspoken WordPress developers, agencies, product owners, and community advocates on a video call with both the Lead Architect and the Product Owner of the entire Gutenberg project? Hopefully progress.
Matt Mullenweg may have surprised a few people when he recently stated that the Gutenberg project still has years of development to go, but I doubt that anyone using it would disagree. The tentpole feature of Gutenberg’s Phase Two, the “Site Editor,” has been in core (and enabled by default for new installations) for the last two years, but the adoption of block-based themes has felt underwhelming at best, especially compared to the market share of page-building tools like Elementor.

Everyone has their opinions of the block editor, one need only browse the comments section of this very site to find them. The reality however is that WordPress is a vast and complicated project. While it’s certainly subject to the decisions of its “Benevolent Dictator”, it is also subject to the very real constraints of large-scale, distributed, open-source software development. Not to mention the work is entirely based on contributions, many of which are sponsored by large organizations with their own goals for the project.

At the center of all of this are the individual WordPress end users who can feel like they have no agency in the project, no ability to communicate their experiences or give feedback. And there may be no piece of software in more critical need of user feedback than the WordPress Site Editor.

The Outreach Experiment
The FSE Outreach Experiment was launched three years ago as a way to bridge that gap between users experiencing the Site Editor and the core contributors building it. Last week, the team announced a simplified name and scope: Outreach. As part of this new simplified scope, any core contributor can now tag the Outreach team directly in GitHub as they develop new features when they want early feedback from the broader community. The goal is getting more two-way communication happening, and keeping the feedback where it can be most effective: the Make WordPress Slack and the Gutenberg code repository on GitHub.

Social media may feel like the easiest place to voice an opinion (something I am certainly guilty of), but it doesn’t always manifest into meaningful change. “Most of our issues are around just discoverability,” Developer Advocate and Outreach team member Justin Tadlock pointed out recently. “Just getting people to come and take all their reactions and thoughts from social media and bring it in and have some constructive conversations in an official channel.”

Automattic Product Wrangler Anne McCarthy started the original FSE Outreach experiment but has since moved on. That didn’t stop them from providing some feedback on the Site Editor in the form of a widely circulated blog post, “Overlapping problems“. It’s a breakdown of some of the most common user experience complaints, but nearly every piece of feedback links to a specific issue or pull request where work is being done to improve it. If you haven’t already, I recommend pausing now to read it.

Because the problems are “overlapping”, some feel that they speak to an underlying problem with the Site Editor itself and the Gutenberg development process more broadly. Many armchair theories were thrown out, including some from yours truly, at last week’s Hallway Hangout, hosted by the Outreach team, and attended by a wide array of folks, including Gutenberg’s Lead Architect, Matias Ventura and Product Owner, Rich Tabor.

Is the Core Team listening?
Feedback loops in a community this large and diverse are (un)surprisingly hard to get right. One clear piece of feedback, though, seems to be a general feeling that while the Site Editor’s power and feature-set continue to grow, the actual user experience needs more polish. Yet when concerns about this user experience are raised, the general response is that it’s the users who just need more education and training.

“There’s a sentiment that I kept seeing,” Mike McAlister of Ollie explained on the call, “that ‘they’re not listening to us’. And whether that’s perception or their experience or whatever, I think that is very important for us to carry that and to kind of acknowledge it.”

Part of the disconnect between the different sides of our large community is related to that imbalance of incentives amongst contributors. Unless you are employed by a hosting company or a product team like WooCommerce or Yoast, it may feel discouraging to push a feature forward or feel like no one is advocating for your use case.

WordPress is meant to democratize the ability to put content on the internet. So there’s an expectation that its interface should feel, well, easier or at least more intuitive. Nick Diego, Developer Advocate from Automattic, shared an experience of watching his non-technical parents navigate the Site Editor.

“One of the biggest issues I see in the Site Editor,” he explained, “is around how changes that you make are preserved to prevent people from making mistakes. And this seems like such a small little thing, but I watched [my dad] delete a template that had been customized and there was no way to get it back easily. I watched him click on ‘Clear Customizations’ and everything was gone. And he was like, wait, what, what’s happening?”

Nick was showcasing a great practical example of the types of gaps in the user experience that eventually erode their trust in the platform’s ability to safely manage content. He also pointed out that there are tried and true conventions for many of these interactions. “In old WordPress, when you trash the page, it goes into the trash and then you can delete it permanently, right? It goes into your trash. Oh, I made a mistake? I can bring that back. It’s a very logical flow. It’s very similar to other applications.” But the Site Editor often veers into uncharted territory when it comes to user interface.

New tools and new paradigms aren’t just hard for the non-technical users. They can present new challenges for the developers who are trying to launch new WordPress sites. Time that developers previously spent building websites is now often spent exploring new potential workflows, and we can’t rely on our previous two decades of established best practices when scoping new projects. “I think part of this too,” said Anne McCarthy, “is also how to use these tools and changing process because everything I’ve heard is it’s not only a technical change and adjusting to new technology, but it’s changing process.”

This idea of slowing down and refining the basic user experience was reiterated by Brian Gardner, Developer Advocate at WP Engine, who advocated “a call to rally around making what we have already better and consistent and easy to identify and work and document and educate.” WP Engine in particular has leaned into the developer/freelancer side of the community, with a team of educators and content creators, and products like Advanced Custom Fields and LocalWP, all focused on a segment of the market they call “Builders” and what the Core Team often refers to as “extenders”.

The Extenders2
Extenders, builders, developers, freelancers, agencies. There’s plenty of names for this side of the community, but the one thing they have in common is that they build a lot of websites, often for other, less-technical people. There’s widespread sentiment in this group that the Gutenberg project is not prioritizing their needs, driving them to the Classic Editor or page builders like Elementor, Divi, and Bricks. Fabian Kägy is a member of the Outreach team and a sponsored contributor from the agency 10up. He’s focused on fostering more conversation between the extender community and core development, so I spoke to him about this disconnect in priorities.

“There are so many different users that have all different calls”, he told me. “And kind of the reason why I am trying to participate is to share that one side of the story and be an advocate for that particular work. And I am very much hoping that I can actually get more similar folks from other agencies to also chime in and be a part of a conversation.”

Like Fabian, I come from the agency world, where we are constantly stuck trying to balance the desire to adopt the newest technologies for our clients with the need for assurance that those new features are actually ready to be used in production. That presents a tough problem to solve. The core team needs more people using and testing these features, to help refine them. But from the outside perspective, we’re hesitant to use anything that may not be production-ready.

“At the time a feature lands in WordPress Core,” Fabian explained, “there could be four or five months since the developer had originally worked on the feature. Since they last even thought about the feature, they’ve moved on and shipped three other features. And so that feedback cycle from the agency space is incredibly slow because by the time we adopt it, that is not top of mind anymore.”

This gap between the development of a new feature and its adoption by the wider community is the main problem the Outreach team is hoping to solve.

“That is why I am hoping that this kind of outreach,” he continued, “getting more pings, getting asked the question of ‘Hey, is this the right thing?’ Being asked to provide feedback earlier in kind of the development cycle should help us be able to deliver that feedback earlier in the cycle so that we don’t end up in the situation where a year after the feature has been developed, we all of a sudden say, “Hey, but this didn’t account for these issues that we are running into.”

If airing your Gutenberg grievances on social media is unhelpful, raising them six months after a feature was originally developed and tested might even be less so. But with the huge array of features being worked on (there are over 1,000 open pull requests just in the Gutenberg repository), some on a timescale of years, WordPress needs the Outreach team’s ability to do some human curation, often in the form of “Hallway Hangouts” where new features are showcased and discussed.

We are the world, we are the contributors
Watch any meeting of the Outreach team, and you’ll quickly realize that everyone, including a number of Automattic-sponsored contributors, often feel just as “in the dark” as we do. They have many of the same struggles we have. The difference is, they are trying to build a space where we can all connect the dots together. It was a great reminder that we’re all contributors here. WordPress isn’t some people over there building a thing, it’s just a whole lot of us.

read on - get more insights :

https://wptavern.com/gutenbergs-project ... ite-editor

WP: bald signifikant schnellere Ladezeitzen in non-eng-Sites :: Neu: Performance Translations soll in den Core der 6.5 wandern: signifikant schnellere Ladezeitzen v.a. in non-eng-Sites.

in der WordPress-Entwicklung tut sich einiges: für die nächste Version 6.5 soll Performance Translations in den Core wandern. Das Performance-Team von WordPress schlägt vor, "Performant Translations" rechtzeitig für die kommende Veröffentlichung von WordPress 6.5 in den Core zu integrieren.
Nachdem eine eingehende Leistungsanalyse Anfang des Jahres ergeben hatte, dass Übersetzungen die Antwortzeiten des Servers erheblich beeinflussen können, diskutierte das Team verschiedene
Lösungen und landete bei einer Lösung, die keine Konfiguration durch Benutzer erfordert.
Mehr als 2.000 WordPress-Sites haben es nach der Veröffentlichung im August über das Feature-Plugin Performant Translations getestet.

Die ersten Ergebnisse sind sehr eindrücklich:


in einem neuen Artikel auf WP wird es diskutiert. Pascal Birchler, Mitarbeiter des Performance-Teams, der den Vorschlag verfasst hat, das Plugin in den Kern zu integrieren, erklärte, wie es Websites durch Übersetzungen beschleunigt: Performant Translations basiert auf einer neuen, leichten i18n-Bibliothek, die binäre MO-Dateien schneller lädt und weniger Speicher benötigt. Es unterstützt sogar das gleichzeitige Laden mehrerer Gebietsschemas, was den Wechsel des Gebietsschemas beschleunigt. Darüber hinaus unterstützt es in PHP-Dateien enthaltene Übersetzungen, vermeidet ein binäres Dateiformat und nutzt OPCache, sofern verfügbar. Wenn eine MO-Übersetzungsdatei über eine entsprechende PHP-Datei verfügt, wird diese stattdessen geladen, was die Arbeit noch schneller macht und noch weniger Speicher verbraucht. Birchler hat außerdem einige überzeugende Benchmarks veröffentlicht, die die Fähigkeit des Plugins demonstrieren, die Speichernutzung zu reduzieren und die Ladezeit zu verkürzen:

Code: Select all

+=========+==========================+===============+============+
|         |                          |               |            |
+=========+==========================+===============+============+
| Locale; | Scenario;                | Memory Usage; | Load Time; |
+---------+--------------------------+---------------+------------+
| en_US;  | Default                  | 15 MB;        | 159 ms;    |
+---------+--------------------------+---------------+------------+
| de_DE;  | Default                  | 29 MB;        | 217 ms;    |
+---------+--------------------------+---------------+------------+
| de_DE;  | Performant Translations; | 17 MB;        | 166 ms;    |
+---------+--------------------------+---------------+------------+


Quelle: Vorschlag zur Zusammenführung performanter Übersetzungen in Core


Das Performance-Team hat ein Ticket für die Einbindung des Plugins in WordPress 6.5 geöffnet. Core-Committer Felix Arntz bezeichnete dies als eine hohe Priorität für die nächste Veröffentlichung, „aufgrund der geschätzten erheblichen Auswirkungen, die dies auf die Leistung lokalisierter Websites haben wird“.
Die Verbesserungen werden sich voraussichtlich positiv auf die Mehrheit der WordPress-Sites (mehr als 50 %) auswirken, die Übersetzungen verwenden. WordPress 6.5 wird für Ende März 2024 erwartet. Eine Zusammenführung so früh im Veröffentlichungszyklus würde Performant Translations die Zeit geben,
die es braucht, um umfassender getestet zu werden und einsatzbereit zu sein. Benutzer, die nicht bis zum nächsten Jahr warten möchten, um diese gemeldeten Leistungsverbesserungen zu erhalten, können das Plugin in der Zwischenzeit installieren.

„Das Performant Translations-Plugin wird auch nach einer Kernzusammenführung weiterhin beibehalten, um auf der Kernlösung mit einer besonderen Zusatzfunktion aufzubauen“, sagte Birchler. „Wie bereits heute üblich, wandelt das Plugin automatisch alle MO-Dateien in PHP-Dateien um, wenn aktuell keine PHP-Datei existiert. Dies ist nützlich für Websites, deren Übersetzungen nicht von translator.wordpress.org
stammen oder nur lokal auf diesem Server vorhanden sind.“


und hier [/b]einige Rückmeldungen - zum Einsatz des Plugins[/b].

- Required for non-English speaking WPs
- It does what it promises
- Oh, yes
- Does what is states well!
- Plugin speeds up the presentation of your site
- Great job !
- Beneficial for any sites not using English en_US
- Works great!


mehr Infos, Hintergründe, Daten, Quellen und Links:

der aktuelle Artikel: https://wptavern.com/wordpress-contribu ... zuQgDdz6Cw
Hintergrund: WordPress Performance Analysis Finds Translations May Significantly Slow Down Sites https://wptavern.com/wordpress-performa ... down-sites
Favorite Performant Translations :: By WordPress Performance Team https://wordpress.org/plugins/performant-translations/ Version:1.0.6 Last updated:3 weeks ago Active installations:2,000+

Hello! Here's my situation.

I have a PC (acts as a server) and a mobile that is connected through a router (without internet). I can't connect to my PC using my mobile by typing in the IP address of the PC to the browser. It just keeps on loading. However, if I try to assign the IP address of my mobile manually, I can connect to it.

Also, when using my PC, I can access my PHP files quickly if I use localhost/(insert PHP files here). But when I type in my own IP address instead of localhost, it still loads but it is slow. I can fix this by also assigning the IP address of the PC manually.

In summary, if I used static IP addresses on both of my devices, there are no issues. But If I used DHCP or dynamically assigned IP address to them, the mobile wouldn't connect to the server, and the PC would load its own files slowly.

P.S. Both of the devices can see each other. Pinging my mobile whether it has a static IP address or dynamic IP address produces the same result.

I found some web search results that might help you with the bugs known in XAMPP 8.X.X versions. Here are some of them:

[BUGS] Known XAMPP 8.X.X issues - Apache Friends Support Forum1: This forum thread lists some of the common issues with XAMPP 8.X.X versions, such as Apache not starting, setup_xampp.bat throwing PHP warnings, phpMyAdmin not loading, etc. It also provides solutions and references for each bug.

How to Fix XAMPP If It’s Not Working (3 Common Solutions) - Kinsta: This article explains how to check your XAMPP PHP error log and resolve three common problems that may prevent your local server from starting. These include port conflicts, missing Visual C++ components, and incorrect file permissions.

How to Troubleshoot and Fix Common XAMPP and WordPress Issues: This article covers four of the most frustrating issues that WordPress developers may encounter when using XAMPP, such as slow loading times, database connection errors, missing images, and permalinks not working. It also suggests some ways to fix them.
I hope these results are useful for you. If you need more help, please let me know.

WordPress Performance Analyse zeigt auf, dass Übersetzungen signifikanten Einfluss haben.

Die Leistungsanalyse von WordPress zeigt, dass Übersetzungen Websites erheblich verlangsamen können: Nachdem kürzlich in diesem Jahr eine ausführliche Leistungsanalyse gezeigt hat, dass Übersetzungen einen Einfluss auf die Server-Reaktionszeiten haben können, schlagen WordPress-Mitwirkende ein halbes Dutzend technische Lösungen zur Verbesserung der Leistung von etwa 56 % der WordPress-Websites vor, die Übersetzungen verwenden. Das Performance-Team plant, diese Ideen im Rahmen seines Feature-Projekts „Performance Lab“ in größerem Umfang zu testen, nachdem es Feedback von der breiteren Sarah Gooding hat in einem neuen Beitrag das Thema erörtert (vgl. Link unten):

„Erste Benchmarks haben gezeigt, dass die mittlere Ladezeit für eine lokalisierte Website bis zu 50 % langsamer sein kann als für nicht lokalisierte Websites,
je nachdem, welche Themes und Plugins verwendet werden“, sagte der von Google gesponserte WordPress-Core-Committer Pascal Birchler.

Basierend auf den jüngsten Diskussionen auf GitHub hat das Performance-Team eine aktualisierte Liste mit sechs möglichen Top-Anwärtern für die Beschleunigung
von Websites durch Übersetzungen erstellt, einschließlich der Vor- und Nachteile jedes einzelnen:

Lösung A: Verwenden Sie ein anderes Dateiformat
Lösung B: Native gettext-Erweiterung
Lösung C: Cache-Übersetzungen
Lösung D: Lazily ausgewertete Übersetzungsaufrufe
Lösung E: Vorhandenen MO-Parser optimieren/neu schreiben
Lösung F: Übersetzungsdateien aufteilen

Lokalisierte WordPress-Sites laden derzeit .po- und .mo-Dateien herunter, die die Übersetzungen enthalten, aber die erste vorgeschlagene Lösung schlägt vor,
Übersetzungen in .php-Dateien zu speichern und die .mo-Datei als Fallback zu verwenden, wie Birchler vorschlägt, dass PHP eine andere PHP-Datei laden und ausführen
würde ein schnellerer Ansatz sein. Er hat einen Proof of Concept auf GitHub unter swissspidy/wp-php-translation-files und swissspidy/ginger-mo.

„Wenn man all diese Faktoren betrachtet, scheint es, dass ein überarbeiteter Übersetzungsparser (Lösung E) die bedeutendsten Verbesserungen für alle lokalisierten
WordPress-Sites bringen könnte“, sagte Birchler. „Vor allem in Kombination mit einem neuen PHP-Übersetzungsdateiformat (Lösung A), das Ginger MO unterstützt,
wird der i18n-Overhead vernachlässigbar. Natürlich bestehen dieselben Risiken wie bei der Einführung eines neuen Formats.

„Darüber hinaus könnte eine überarbeitete i18n-Bibliothek wie Ginger MO auch mit anderen Lösungen, wie etwa Caching oder dynamischem MO-Laden kombiniert werden,
um möglicherweise weitere Verbesserungen zu erzielen. Diese Routen müssen jedoch noch erkundet werden.“

Das Performance-Team plant, diese Ideen im Rahmen seines Feature-Projekts „Performance Lab“ in größerem Umfang zu testen, nachdem es Feedback von der breiteren
Community eingeholt hat. Der 6. August 2023 ist die Frist für die Abgabe von Rückmeldungen zum Vorschlag, die Benchmarks und weitere Details aus der Analyse enthalten.

weitere Infos, Daten und Quellen :

der Artikel von Sarah https://wptavern.com/wordpress-performa ... down-sites
die aktuelle i18n-performance-analysis: https://make.wordpress.org/core/2023/07 ... -analysis/
die Diskussion auf Github: https://github.com/WordPress/performance/issues/171
das Performance-Lab: https://wordpress.org/plugins/performance-lab/
Pascal Birchler - von Google gesponserte WordPress-Core-Committer https://pascalbirchler.com/about/

chinmayborkar3 wrote:How can I Set the Ip. In which File I have to do this configuration ?

In your router. It depends on your router where and how to set it. Most routers have a menu like "Forwarded Ports" or similar. The router also should have a screen where it shows all connected PCs and their LAN IPs. You have to forward the port 3306 to the PC running MariaDB.

BUT: Running an SQL server (like MariaDB) not on the same computer (i.e. localhost) or at least not in the same LAN, but instead remote via Internet on another PC is extremely slow and a huge bottle neck. I cannot recommend to do so. Any SQL command which results in a big table will have lots of internet traffic based I/O which is way slower than TCPIP on LAN or localhost. You really *should* run the main scripts (PHP or whatever) on the same server or LAN as the MariaDB server.

In my.ini for MySQL it says that config is for small projects iunder 64M, I've tried to tune it but still pages locally load slow, any idea where to look to make xamp work fast for larger projects

Current my.ini

Code: Select all

# Example MySQL config file for small systems.
#
# This is for a system with little memory (<= 64M) where MySQL is only used
# from time to time and it's important that the mysqld daemon
# doesn't use much resources.
#
# You can copy this file to
# E:/xampp/mysql/bin/my.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is E:/xampp/mysql/data) or
# ~/.my.cnf to set user-specific options.
#
# In this file, you can use all long options that a program supports.
# If you want to know which options a program supports, run the program
# with the "--help" option.

# The following options will be passed to all MySQL clients
[client]
# password       = your_password
port=3306
socket="E:/xampp/mysql/mysql.sock"


# Here follows entries for some specific programs

# The MySQL server
default-character-set=utf8mb4
[mysqld]
port=3306
socket="E:/xampp/mysql/mysql.sock"
basedir="E:/xampp/mysql"
tmpdir="E:/xampp/tmp"
datadir="E:/xampp/mysql/data"
pid_file="mysql.pid"
# enable-named-pipe
key_buffer=16M
max_allowed_packet=10M
sort_buffer_size=512K
net_buffer_length=8K
read_buffer_size=256K
read_rnd_buffer_size=512K
myisam_sort_buffer_size=8M
log_error="mysql_error.log"

# Change here for bind listening
# bind-address="127.0.0.1"
# bind-address = ::1          # for ipv6

# Where do all the plugins live
plugin_dir="E:/xampp/mysql/lib/plugin/"

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
#
# commented in by lampp security
#skip-networking
#skip-federated

# Replication Master Server (default)
# binary logging is required for replication
# log-bin deactivated by default since XAMPP 1.4.11
#log-bin=mysql-bin

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id   =1

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
#    the syntax is:
#
#    CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
#    MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
#    where you replace <host>, <user>, <password> by quoted strings and
#    <port> by the master's port number (3306 by default).
#
#    Example:
#
#    CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
#    MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
#    start replication for the first time (even unsuccessfully, for example
#    if you mistyped the password in master-password and the slave fails to
#    connect), the slave will create a master.info file, and any later
#    change in this file to the variables' values below will be ignored and
#    overridden by the content of the master.info file, unless you shutdown
#    the slave server, delete master.info and restart the slaver server.
#    For that reason, you may want to leave the lines below untouched
#    (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id       = 2
#
# The replication master for this slave - required
#master-host     =   <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user     =   <username>
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password =   <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port     =  <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin


# Point the following paths to different dedicated disks
#tmpdir = "E:/xampp/tmp"
#log-update = /path-to-dedicated-directory/hostname

# Uncomment the following if you are using BDB tables
#bdb_cache_size = 4M
#bdb_max_lock = 10000

# Comment the following if you are using InnoDB tables
#skip-innodb
innodb_data_home_dir="E:/xampp/mysql/data"
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_group_home_dir="E:/xampp/mysql/data"
#innodb_log_arch_dir = "E:/xampp/mysql/data"
## You can set .._buffer_pool_size up to 50 - 80 %
## of RAM but beware of setting memory usage too high
innodb_buffer_pool_size=10G
## Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size=2G
innodb_log_buffer_size=80M
innodb_flush_log_at_trx_commit=0
innodb_lock_wait_timeout=50

## UTF 8 Settings
#init-connect=\'SET NAMES utf8\'
#collation_server=utf8_unicode_ci
#character_set_server=utf8
#skip-character-set-client-handshake
#character_sets-dir="E:/xampp/mysql/share/charsets"
sql_mode=NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTION
log_bin_trust_function_creators=1

character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
[mysqldump]
max_allowed_packet=128M

[mysql]
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer=100M
sort_buffer_size=100M
read_buffer=20M
write_buffer=20M

[myisamchk]
key_buffer=100M
sort_buffer_size=100M
read_buffer=20M
write_buffer=20M

[mysqlhotcopy]

Allow External ip in "apache"?? Why Apache?? Its an issue of MariaDB / MySQL, not Apache. Apache has nothing to do with that.

You simply have to create a (new) user in MariaDB (i.e. using PhpMyAdmin), which has sufficient rights for your database and is assigned to the host 78.30.44.67 (in PhpMyAdmin Formular for creating new Users its the second field "Hostname" after the name of the User). Its that easy. Instead (quick and dirty) you might use "root" User of MariaDB for connection, which may access all hosts with all privileges. You *should* assign a passwort for "root" though.

islanublark wrote:I have been trying to find information but everything I have found has not helped me

Really? When i enter "Host '78.30.44.67' is not allowed to connect to this MariaDB server" into Google, i get tons(!) of helpful links. Is your Google broken?

P.S.: You should explain more precisely, what your planning. Its not clear, where your Apche and your PHP script runs and where the MariaDB server runs. If you are planning to open a remote SQL Database via Internet, i strongly recommend NOT to do this. Some Queries may result in huge amount of data and in case your remote database is connected via Internet (instead of LAN), it might slow down dramatically, as LANs usually are way faster than Internet connections. Actually you should run Apache/PHP and MariaDB either on the same server, or (at least) in the same LAN. Its not recommended to separate PHP and MariaDB server via Internet connection.

Nobbie, I'll have to take your word for it. My site design requires current news content (articles). Keeping up with topics is occupying the little time I have between fighting the good fight with my tech and learning enough to evaluate the tech pieces I still need. Right now I'm not going to add Linux - at least I don't think I will.

Froosh, Glad it worked out for you.

Agreed, there is nothing magical about running/operating Linux. Just requires a bit of desire to become familiar with a few different concepts at times. But if you are using a desktop distribution, like Mint as suggested by Nobbie, there is really nothing to getting used to using the OS.

Not sure what form of development you are attempting to do, but XAMPP on Windows 10/11, works just fine. My last machine was Windows 10 running on a laptop that was rather old. XAMPP/Apache/MySQL performed well. Microsoft Edge browser tended to bog things down, but only when the development tools window was open.

VonRad wrote:As such running Linux is beyond me.

No, its not. Everybody can run macOS "out of the box" and macOS also bases on linux. Even my old aunt (82 Years!) runs a Linux Notebook (as i installed here Linux). There is no reason to be afraid of Linux. Download and install Linux Mint (for example) and you will be happy.

Thank you for your response. While I spent many years in IT I'm new to coding/ development. As such running Linux is beyond me. I installed XAMPP to c:/xampp. I'll look up how to use 127.0.0.1 instead of localhost and give it a try.

I dont think replacing Xampp will help, as Xampp is only a distribution. Its a normal Apache installation, normal MariaDB etc.. Joomla is well known for running slowly in some servers.

Where did you install Xampp? Standard c:/xampp or somewhere else? There are known issues when running DocumentRoot on a network drive. There are also known issues running databases from localhost, try 127.0.0.1 instead.

Very often Windows is an issue, if i were you, i would run Linux instead of Windows.

Hi,

I'm using Xampp v8.0.25, Gantry v5.1.16, the Gantry Helium template v5.1.16 template and Joomla 4.2.9. The localhost is running too slow to develop on. I've looked through forum posts and tried a few of the suggestions, without success. I've upgraded the RAM in my PC, reinstalled and updated Windows (with no errors), scanned the full system with Windows Defender, scanned the full system with Iolo System Mechanic Virus scan, cleaned and defragged the HD but it still runs dog slow. I've rebuilt this site three times to get a clean install and the last option I have is this forum before I have to replace Xampp. Any suggestions are appreciated. Thanks.