Beiträge von pkambach

Hallo Herr Keppler,

bleibt der Zeitplan unverändert? Wann wird die Online-Demo wieder gehen?

Viele Grüße

Hallo!

Gibt es evtl. schon Neuigkeiten? Die Live-Demo unter https://demo.liveconfig.com:8444/ funktioniert aktuell nicht - vielleicht ein Vorbote, dass alles fertig ist und die finale Version hoch geladen wird?

VG
Patrick

Hallo Andreas,

das hört sich eher nach nem langsam antwortenden Resolver / DNS an. Evtl. mal in die Richtung geschaut?

VG
Patrick

Hallo,

ganz ehrlich: Ich hätte mir hier eine "ordentliche" Information gewünscht und kein klammheimliches Ändern der Routemap und des KB Artikels. Ein bisschen Erklärung dazu (auch wenn wir die Gründe vermutlich alle kennen...). Es ist ja nicht das erste Mal, dass hier Zeitpläne nicht eingehalten werden, aber sollte daraus nicht gelernt werden? Was bringt es, wenn es doch nicht kommt oder der Fortschritt nicht transparent gezeigt wird. Da kommen sich viele vermutlich etwas veräppellt vor.

Nicht falsch verstehen, ich mag LiveConfig und werde es auch weiter nutzen - es tut, was es soll, ist trotz Preiserhöhung noch günstiger als die meisten anderen Panels, etc. Nur Kommunikation ist halt auch wichtig

Viele Grüße

Hallo,

auch ich würde nun nach einem weiteren Monat einmal nachfragen, wie nun der aktuelle Stand ist

Danke vorab!

Hallo,

okay, alles klar - habe auf MySQL 5.7 umgestellt.

VG

Hallo!

Ich habe hier das gleiche Problem mit CentOS 7 und MySQL 5.6.51 - innodb_large_prefix sind aktiv, als SQL Mode ist noch "NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES" hinterlegt.

Ich hänge nicht an der MySQL Anbindung von LiveConfig - gibt es ansonsten ein mini Howto (wie https://www.liveconfig.com/de/kb/sqlite-mysql/) um von MySQL wieder zu SQLITE zu gehen? Auch mit der aktuell "fehlerhaften" Datenbank?

Vielen Dank!

Hallo!

Gibt es hierzu eigentlich einen aktuellen Stand? Ja, ich weiß, der 01.06.2022 ist noch lang, aber ich denke ja eher nicht, dass es heute irgendwas gibt

Frage wäre also: Wie ist die (neue) Roadmap für v3?

Danke & Gruß
Patrick

PS: Hatte ich nun gerade eben auch bei Ubuntu 20 (Upgrade von 16 und 18).

Hallo!

Da gibt es nun folgende Rückmeldung zu:

Chrome Version 94.0.4606.61, Betriebssystem OS X El Capitan Version 10.11.6

VG
Patrick Kambach

Hallo Zusammen,

ich habe hier zumindest auch Probleme bei mehreren Kunden - In der Zertifikatskette in Chrome z.B. steht das abgelaufene Root-Zertifikat drin (welche Version und OS es ist, weiß ich noch nicht).

https://file.connectingbytes.de/index.php/s/5mQt9FXCZz86965

Das Zertifikat wurde bereits gelöscht und neu ausgestellt.

VG
Patrick

hi Christoph,

das ist (leider) nicht das Problem - der externe Zugriff klappt generell und wenn der User & DB direkt damit angelegt werden, funktioniert es ja auch. Nur beim Wechsel dann nicht (mehr).

VG
Patrick

Hallo!

Ich habe aktuell ein "Problem", dass beim Anlegen einer DB / Benutzer mit externen Zugriff dieser entsprechen eingetragen und "aktiv" ist. Ich kann ihn dann auch "weg" nehmen, aber beim Aktivieren bleibt er aus. Habe auch schon probiert mit neu gesetztem Passwort das wieder zu aktivieren, geht aber auch nicht.

OS: Debian 10
MySQL Version:10.3.27 (1:10.3.27-0+deb10u1)
LiveConfig 2.11.3

Jemand eine ähnliches Problem gehabt?

VG
Patrick

Hallo,

ist in die Richtung noch weiter etwas geplant?

VG

Hallo,

mir fällt es immer wieder auf, dass wenn z.B. beim Kopieren einer Domain schnell ein Leerzeichen mit kopiert wird. Wirft man das dann oben ins Suchfeld, wird die Domain nicht gefunden, da das Leerzeichen natürlich Unsinn ist.

Vielleicht würde hier ein "trim" auf das entsprechende Feld gut sein, damit solche Zeichen verschwinden - oder gibt es einen guten Grund, warum es Sinn machen würde so zu suchen?

Viele Grüße

Beide Einträge sind vorhanden - das Problem tritt nun aber auch nicht mehr auf... überall wo ich es zuvor probiert hatte, bekam ich z.B. solche Meldungen:

Zitat

nvalid response from https://www.xxxxx.de/.well-kno…p7RAuM-_pB-zT2_CVMttTM17k [xx.xx.xx.xx]: "<!DOCTYPE html>\n\n<html lang="de-DE" prefix="og: http://ogp.me/ns#">\n\n\t<head>\n\t\t\n\t\t<meta charset=\

Nun klappt es immer bei der neuen Überprüfung.

Sorry

So kannte ich es eigentlich auch

Also ich habe zwei Sachen - ein Kunde ohne .htaccess, der einfach einen 404er generiert...

Eine .htaccess sieht z.B. so aus:

Zitat

# BEGIN WpFastestCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} ^domain-name.de
# Start WPFC Exclude
# End WPFC Exclude
# Start_WPFC_Exclude_Admin_Cookie
RewriteCond %{HTTP:Cookie} !wordpress_logged_in_[^\=]+\=Detlef\sBeyer|klaus
# End_WPFC_Exclude_Admin_Cookie
RewriteCond %{HTTP_HOST} ^domain-name.de
RewriteCond %{HTTP_USER_AGENT} !(facebookexternalhit|WhatsApp|Mediatoolkitbot)
RewriteCond %{HTTP_USER_AGENT} !(WP\sFastest\sCache\sPreload(\siPhone\sMobile)?\s*Bot)
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{REQUEST_URI} !(\/){2}$
RewriteCond %{REQUEST_URI} \/$
RewriteCond %{QUERY_STRING} !.+
RewriteCond %{HTTP:Cookie} !comment_author_
RewriteCond %{HTTP:Cookie} !woocommerce_items_in_cart
RewriteCond %{HTTP:Cookie} !safirmobilswitcher=mobil
RewriteCond %{HTTP:Profile} !^[a-z0-9']+ [NC]
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/all/$1/index.html -f [or]
RewriteCond /var/www/WEBNAME/htdocs/wp-content/cache/all/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/all/$1/index.html" [L]
</IfModule>
<FilesMatch "index\.(html|htm)$">
AddDefaultCharset UTF-8
<ifModule mod_headers.c>
FileETag None
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Mon, 29 Oct 1923 20:30:00 GMT"
</ifModule>
</FilesMatch>
# END WpFastestCache
# BEGIN GzipWpFastestCache
<IfModule mod_deflate.c>
AddType x-font/woff .woff
AddType x-font/ttf .ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE font/opentype font/ttf font/eot font/otf
</IfModule>
# END GzipWpFastestCache
# BEGIN LBCWpFastestCache
<FilesMatch "\.(webm|ogg|mp4|ico|pdf|flv|jpg|jpeg|png|gif|webp|js|css|swf|x-html|css|xml|js|woff|woff2|ttf|svg|eot)(\.gz)?$">
<IfModule mod_expires.c>
AddType application/font-woff2 .woff2
ExpiresActive On
ExpiresDefault A0
ExpiresByType video/webm A2592000
ExpiresByType video/ogg A2592000
ExpiresByType video/mp4 A2592000
ExpiresByType image/webp A2592000
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/ico A2592000
ExpiresByType image/svg+xml A2592000
ExpiresByType text/css A2592000
ExpiresByType text/javascript A2592000
ExpiresByType application/javascript A2592000
ExpiresByType application/x-javascript A2592000
ExpiresByType application/font-woff2 A2592000
</IfModule>
<IfModule mod_headers.c>
Header set Expires "max-age=2592000, public"
Header unset ETag
Header set Connection keep-alive
FileETag None
</IfModule>
</FilesMatch>
# END LBCWpFastestCache

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Alles anzeigen

hi!

Ich habe nun etliche Kunden, bei denen die Validierung von LE nicht mehr geht, da /.well-known/ mittels .htaccess umgeleitet wird... das war früher meine ich immer von LC verwaltet, oder irre ich mich?

Gleiche CentOS und LiveConfig Version

VG

Febas: Danke, hat mit "sperren" und wieder aktivieren im Vertrag funktioniert...

hi!

Sorry, dass ich mich hier jetzt so dran hänge, aber meine Support-Anfragen werden seit März nicht beantwortet zum Thema Backup (LC#2018061434000018 && LC#2018031334000034).

Ich habe ein ähnliches Problem unter CentOS. Nur ich erhalte bei einem Kunden einfach die Meldung "not permitted" - egal ob zip oder tar. Bei anderen Kunden auf dem gleichen System geht es. Im Logfile ist nichts zu finden. Gleiche LiveConfig-Version.

VG,
Patrick Kambach