IN dieser update gab es eigentlich nichts was den Billsafe angeht odwer?
Fix16 für 2.5.15 (Refresh 25.04.2016)
Beiträge von jotest
-
-
Noch immer versionen und soweit einstellungen?
Ob ... raten bringt nichts > weil auch wen es nach ein update ist könnte es noch immer sein dass beispiel: den update comseo da ist/war ein neuerer oder sicherer version von etwas zu updaten womit dan etwass mit einstellungen oder vielleicht ältere php version nicht mehr lauft.( Auch beim Update selbst kan etwas schief gehen)
Weiter gibt es LOG files auf den server wo oft/meist ein fehlermeldung drin ist!????
-
Hallo Andrea,
gab es hier eine Lösung? Habe derzeit das gleiche Problem, dass eine weiße Seite angezeigt wird...
Weiss ich nicht aber poste besser deiner versionen:
COMSEO, PHP, Billsafe, php settings / [lexicon]php.ini[/lexicon] anders kan man überhaupt nichts dazu sagen, (Glaskugel)
Vielleicht auch dazu hosting paket info's und [lexicon]htaccess[/lexicon] und shopurl (also wichtig auch alles mit https oder alle ohne, oder teilweise https, www oder nicht www, subdomain oder nicht, Shop in ein Verzweichniss ja oder nein?????
Und ob auf dein Webspace auch noch wordpress und oder joomla drauf ist soja dein root/basis webspace mit einstellungen [lexicon]php.ini[/lexicon] und [lexicon]htaccess[/lexicon] können auch einiges machen. -
Also allen den 7, 5.5 und 5.6
5.3 und 5.4 hmm nen besser nicht mehr.
den php 7 mit letzte updates soll laufen aber ein par depricated sachen sind drin, nur warnungen wichtiger ist nicht alle plugins adons extern laufen unter php7, welche weis ich so 123 nicht weil wir benutzen wenige.
-
Sehe den neueste Beitrag von MariaDB
https://mariadb.org/mariadb-server…-cve-2016-6662/
ZitatMySQL Remote Root Code Execution / Privilege Escalation 0day with CVE code CVE-2016-6662.
It’s a serious vulnerability and we encourage every MariaDB Server user
to read the below update on the vulnerability from a MariaDB point of
view.
The vulnerability can be exploited by both local and remote users.
Both an authenticated connection to or SQL injection in an affected
version of MariaDB Server can be used to exploit the vulnerability. If
successful, a library file could be loaded and executed with root privileges. The vulnerability makes use of the mysqld_safe startup script.However, if the database user being used has neither SUPER nor FILE privilege or if the user has FILE but –secure-file-priv
is set to isolate the location of import and export operations, the
vulnerability is NOT exploitable. It is always recommended configuration
to not grant SUPER privileges and avoiding granting FILE privileges
without using –secure-file-priv. -
Also weil es gibt noch keinen HILFE wen aber MYSQL dan aufpassen.
http://legalhackers.com/advisories/MyS…-2016-6662.htmlhttp://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6662
Wen MARIADB hat bereits in den
ZitatIt (CVE-2016-6662) is fixed in MariaDB 5.5.51, MariaDB 10.0.27 and MariaDB 10.1.17 - wich all are available in
Ich schreibe es hier weil vielen mit ältere Server oft dazu noch ältere MYSQL im einsatz haben.
Weiter den:
ZitatI think also important to keep a eye on CVE-2016-6663 vulnerability
ZitatVII. BUSINESS IMPACT
-------------------------As discussed above the vulnerability could be exploited by attackers with both
privileged and unprivileged (with FILE privilege only) access to mysql accounts.
It could also be combined with CVE-2016-6663 vulnerability which will be released
shortly and could allow certain attackers to escalate their privileges to root
even without FILE privilege.The vulnerability could also be exploited via an SQL injection vector, which
removes the need for the attackers to have direct mysql connection and increases
the risk of exploitation.Successful exploitation could gain a attacker a remote shell with root privileges
which would allow them to fully compromise the remote system.If exploited, the malicious code would run as soon as MySQL daemon gets
restarted. MySQL service restart could happen for a number of reasons.Aja info MariaDB:
https://mariadb.com/kb/en/mariadb/security/Weil ZERO DAY BEIDES!
http://www.tecklyfe.com/tag/cve-2016-6663/ZitatMySQL Zero-Day Allows An Attacker To Take Full Control Of Database
Also noch ein extra Grund kein MYSQL mehr zu benutzen oder?
ZitatWhile MariaDB and PerconaDB have fixed the vulnerabilities and Oracle has not, the researcher today has gone ahead and published the proof-of-concept exploit code for CVE-2016-6662.
The last Critical Patch Update (CPU) released by Oracle was on July
19, 2016. Oracle is on a strict security update release schedule that
rolls out once every three months and the next Oracle CPU update is
scheduled for October 18, 2016. -
Generel ist ein 777 immer ein sicherheits problem
Wen Server und alles dazu richtig eingesteld soll man die gar nicht brauchen.
Benutze Magnalister nicht.
Aber zum sicherheit ( was deiner Server / Hosting Account) dein Serveradmin oder also vielleicht Hoster fragen!
Info beispiel hier wegen security.
https://www.spiralscripts.co.uk/Blog/why-777-f…urity-risk.htmlWen also doch ein 777 muss, soll man so einiges zusätzlich ganz genau richtig gesetzt haben auf/mit den Server security, und dazu dein Serveradmin / Hoster also...
-
777 ist nirgendwo auf keinen Server ein Guten Idee.
Oder es sollen zuzüglich security settings / [lexicon]tools[/lexicon] drauf stehen. die zugang begrenzen aber danoch ein 777... ist schlecht.
Wir benutzen kein Mag... kan damit also nicht helfen!
( teils braucht man nur den Rechten kurz auf 775 oder 777 setzen bei einer install oder änderung einer konfig, wie beim den configure.php von comseo, so etwas kan man versuchen wen man ahnung von security hat.
Anders nachfragen beim Hoster, weil man kan für den HOSTUser ( also dich) den Rechten auf meiste Server so konfigurieren dass es lauft ohne risikien nach drausen. -
Weis nicht ob dies geht?
Zitat"CKEDITOR.dtd.$removeEmpty.i = 0; "
in die ckeditor-config,Ander tip anderes Forum eher ein workarround
ZitatSchreib doch einfach ein als Inhalt in die Tags rein. Dann bleiben sie bestehen.
-
Ich habe mal ein wenig propiert, ABER seht hier: http://caniuse.com/#feat=link-rel-preload
preload wird fast gar nicht unterstützt!!!!!Genau hier seht man was Google so oft versucht über etwas meckern, dan dazu naturlich ein eigene lösung haben womit die Leute zum bestimmte Google Produkten fast gezwungen werden. ( und oder den rest auch tun muss was Google sagt, hier beispiel Firefox,Edge und Safari)
Sehe den ganze AMP hier versucht so wie mehrere Google also einiges auf zu dringen, wen es wirklich gut ist vielleicht kein problem aber so ein MACHT...)Ich hoffe Hier man versteht was ich hier oben geschrieben haben.
Wen man dass mit den css für Mobile macht, und dran ist sehe auch den übrige TIPS weil den css und so weiter sind wirklich nicht soviele KB dass etwas wirklich haken soll im aufbau, also auch Images, und optimierung ein Kategorie menu spezial für den Mobile users. ( Also ein extra schlichtes einfache basis Menu struktur spezial für Mobil könte ein conversion verbesserung geben!)
-
Alles gut und schön, aber da kommt genau der Effekt zu Stande:
https://developers.google.com/speed/pagespee…h%2F&tab=mobileWen man dies hier macht auch ganz genau nach den Bilder beispiel von Webseite schauen ist sehr wichtig wie die dargesteld werden
https://testmysite.thinkwithgoogle.com/ aufpassen dieser test past sich an deiner viewport an womit Du dieser macht wen Dekstop zum beispiel.
HOME
Mobile Friendliness90/100 Mobile Speed100/100 Desktop-speed 100/100Produktseite aberhttps://www.cseo.zero24.ch/dsaasd.html
Zitat80/100Mobile Friendliness
Fair
passed
consider fixing
should fix
Size content to viewport
Size tap targets appropriately
Avoid plugins
Configure the viewport
Use legible font sizesWichtige js und css teilen direkt einbinden rest onload oder so?
Eigentlich blöd weil den Render blocking hat wen dies nur kurz eben nichts mit User Experience zu tun eh im gegenteil, wen etwas nicht richtig dagesteld ist im frontend seht es ... aus. DOM hmm
Sehe conversion test zusammen mit GooG:
Zitat5. DOM ready was the greatest predictor of bounce rate
“DOM ready” refers to the amount of time it takes for the page’s HTML
to be received and parsed by the browser. Actual page elements, such as
images, haven’t appeared yet. While it isn’t shocking that DOM ready
was a predictor, it was very surprising to see that it was the number
one predictor. Our team agreed that this finding needs more study.6. Full load time was the second greatest predictor of bounce rate
Bounced sessions had median full page load times that were 53% slower
than non-bounced sessions. This finding is very interesting because in
recent years there’s been a growing movement within the performance
community to disregard load time as a meaningful metric.I’ll put my hand up and admit that I’ve been guilty of doing this.
Though the rationale makes sense on paper: with so many assets, such as
third-party scripts and below-the-fold content, slowing down total load
time, it’s difficult to see how it works as a metric for measuring
perceived user experience. But now, with such a strong correlation
between load time and bounce rate, dismissing it may be premature.7. Mobile-related measurements weren’t meaningful predictors of conversions
This came as a surprise. We looked at attributes such as device type,
OS, bandwidth, and connection speed, and found that none of these were
strong predictors of conversions. This is interesting because it
suggests that, contrary to what many people believe, internet users
don’t behave especially differently depending on what device they’re
using. As Pat said in our talk, there’s no more “mobile web”. It’s just
the web.8. Start render time wasn’t a strong predictor of conversions
Out of the 93 different metrics we studied, start render time (when
content begins to display in the user’s browser) ranked 69th in its
ability to predict whether a session would convert or not. This was
probably the most surprising — even shocking — finding. Up until now,
many user experience proponents who participate in the web performance
community have placed some value on start render time. This makes sense,
because — on paper, anyway — start render would seem to reflect the
user’s perception of when a page begins to load. But this research
suggests that start render isn’t an accurate measure of the user
experience — at least as it pertains to triggering more conversions. -
Zitat
<link rel="preload" href="/static/css/ltr_smbapp.css" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/static/css/ltr_smbapp.css"></noscript><script async="" src="//www.google.com/ads/js/peitho2/peitho2.min.js" ></script>
Und viel bilder eher in SVG
Style onpageZitat<style type="text/css">
.twglogo-st0{opacity:0.54;}
.twglogo-st1{opacity:0.38;}
.twglogo-st2{fill:#4285F4;}
.twglogo-st3{fill:#EA4335;}
.twglogo-st4{fill:#FBBC05;}
.twglogo-st5{fill:#34A853;}
</style>
Weiter wie oben auch gesagt im Mobile soll den Menu schlicht und einfach sein.
Also dort soll beser ein art besseres UNterschied in den Shopping Template hinein oder????????????Zitat2. KEEP MENUS
SHORT AND SWEET
An extensive menu might work well for your desktop
site, but mobile users won’t have the patience
to scroll through a long list of options to try and find
what they want. Consider how you can present the
fewest menu items possible - for instance, a major
department store refined the product categories
on its mobile site, presenting study participants with
a shorter, more clearly-defined list than on desktop. -
Nur so nebenbei.
Was wir finden is laut Google doch wirklich auch wichtig.Weil alles was Google "TUT" ist doch nur alles für ein besserer User-erlebnis, also wen wir dass finden sind wir doch nicht die einzige oder?
Wen es mehrere gibt wie Wir, weil wir sind ja auch User, soll es Google doch interessieren, aus rein den eigene intresse, oder?
{Aber Ok dass war vielleicht mal, oder ist gar nicht mal so gewesen]
Mach mall ganz schnell dein SHOP https://amphtml.wordpress.com/2016/08/16/amp…or-mid-q3-2016/ auf AMP https://www.ampproject.org/
Wichtig ist:
ZitatPage load time is one of the strongest reasons of page bounce. The average U.S. retail mobile site loaded in 6.9 seconds in July 2016, and according to the most recent data, 40% of consumers will leave a page that takes longer than three seconds to load [source].
Selbe glaube ich den Images für Mobile soll man IM COMSEO ein optimalisierung haben wen LOGO, SLIDER, BAckground und co, so auch ein einfacheres damit schnelleres Menu vor vor allem den KAT megadropdown.
ZitatMore complex pages can hurt conversion rates
What we found here seems relatively straightforward: Shoppers are less likely to
convert on clunky, complex site pages. But let's really dive into what "complex"
means, by looking at the top page attributes that hurt conversion: number of
elements on the page and the number of images.ZitatIn fact, we found sessions that converted users had 38% fewer images than sessions that didn't convert.
-
glaube nicht das optimierung par byte, par kb wirklich etwas bringt weil dan ist G sehr doof und sicher nicht Intelligent.!
Weiter render blocking hmm wen es dadurch spät und sehr langsam erst den Webseite wichtige aufbau gibt yep dan doch.
Man muss auch den realität nicht aus den Auge verlieren.
Cache hmm ist auch so ein sache es muss wirklich etwas bringen wen man den messwerte in time, also wirkliche geschwindigkeit im Aufbau und TFB. wirkliche ( nicht par KB oder Byte) verschwendung von BAndbreidte.
UND den wichtig USER experience.
Den Zahlen dort gehen an mir vorbei wen alles schnell und schlank genug ist in reale User erlebnis, Smartphone, Tablet und Desktop ( den wirklich kleinere Bildformate "480" werden eh wenig für WebAnkaufen benutzt), weiter ofcourse Benutzer freundlich ist. ( dass ist mit den basic templates ziemlich oft schlicht und in ordnung.
Bei mir / Uns ist de design aber leider nicht so, da können vielleicht auch Kunden die ein erlebnis mit was auch immer sehr schöne design, Bilder, Grafiken haben möchten abhaken.
Da möchte ich gerne mehr info's sehen von test bei den Grosse Shops und platformen ob design oben drauf dan noch zusätzlich wirklich viel bringt. (es gab ein test in ein Marketing Magazine, vor allem 100% Komplet SSL und Responsive war da wichtig, wie auch den Zahloptionen und leider kauf auf Rechnung und den "Betrug" Gratis Versand, Widerruf weil die ist naturlich niemals um sonst nur in den Preisen verrechnet )
( Produkt info's , Merkmale und angaben Lieferzeit auch.
-
Wen ja muss vor allem dies in shopsystem drin
ZitatIn your HTML's <head> section add this code:
<script>CKEDITOR.dtd.$removeEmpty['span'] = false;</script>
Weis es wirklich nicht mehr ob ich damals dieser teil in den js script von ckeditor draus gehold habe...
Oja den Admin ist übrigens auch dabei den bootstrap4 bereits zu testen, dieser plugin ist dafür noch nicht, ist aber noch in alpha fase.
ZitatZitatAlso in den editor.js habe ich mit notepad++ gesucht nach " $removeEmpty " da kan man dieser teil anpassen. in stattt ein 1 ein 0
Cache leermachen in shopadmin auch browser cache, dan braucht man den html head teil nicht mehr in shopsystem zu ändern
Ist nicht updatesicher also! -
Problem ist mit den editor und vor allem war mit IE 9 oder so vielleicht nocht mehr dass es sehr schnell zuviele connections / request aufbaut und dan weisses schirm error 500 und so, ich habe selbe dort gedacht o was gibt es alles an extra' s in plugin aber man hat nicht nur den plugin auch den server mit apache php und übrige shopsysteem zu beachten mit den aufbau davon.
Da hat bei Uns nur den Firefox noch gelaufen aber war auch am Grenze.
So da muss man sich genau überlegen welche optionen von editor drin und oder welche draus.
Oja wen alte commerceseo kan es auch noch sein ein ckeditor release mit ein bug
-
Oder haben es hier bei ein alte 2.5.x den editor selbst neu laden/einbinden und konfigurieren, leider kan ich nicht mehr zurückfinden wo und wie.
( damit den spans erlaubt und möglich sind)
Aufpassen dass man nicht zuviele möglichkeiten drin setzt weil dan kommt ein error zuviel .... geöfnet, wen überhaupt den error zu sehen ist.
So etwa wen die links noch gehen und dies noch aktuel ist>>>
Zitathttp://stackoverflow.com/questions/2437…379949#24379949
config.htmlEncodeOutput =
true;http://docs.cksource.com/ckeditor_api/s…_config.js.html
CKEditor correctly fills empty <div> with
an . You're trying to use CKEditor incorrectly. When you
load that empty block into CKEditor, CKEditor sees it and knows that it won't be
accessible by caret unless it's expanded. Therefore editor inserts there
something (I say something, because it depends on case).Remember that CKEditor is a document editor, not web page builder.
That's said, there's an option to prevent this natural CKEditor's behaviour -
config.fillEmptyBlocks.CKEDITOR.replace( 'editor1', {
fillEmptyBlocks: false
} );
This will leave all blocks empty.PS. There's a bug in the documentation - this option does not accept
callback.noch mehr alte links aus mein doku.
Zitat
http://docs.cksource.com/ckeditor_api/s…TOR.config.htmlhttp://docs.cksource.com/ckeditor_api/s…#.basicEntities
http://docs.cksource.com/ckeditor_api/s…_plugin.js.html
config.htmlEncodeOutput =
true; -
Wie IMMER gilt, bei Updates vorher IMMER eine komplette Sicherung durchführen!Traut man es sich nicht zu, oder hegt den geringsten Zweifel dann lasst BITTE Profis ran! Wir hatten hier in den letzten Wochen einige Schäden an Shops die sich durch ein einfaches Backup hätten beheben lassen.
DAzu gesagt also auch den Shop Datenbanken zeitgleich an den stand übrige Daten und wen man ein WAWi angebunden hat auch den BAckup von den WAWI !
-
Modeshop sehe dir den möglichkeiten für ein sichere HTTPS an bei deiner Hoster ist nicht ein TIP die unwichtig ist.
Weil ein websuche gab bei mir:
ZitatPersonally when I see a site without SSL I dont take is a being a serious site. Real companies nowadays always use SSL.
-
Shopversion, paypal ipn/express oder classic?
Gab es ein update beim Hoster, oder ein meldung dass den WEbspace nicht mehr geeignet ist für Paypal?
( oder irgendeine Zertifikat)Weil Shops auf so alte nicht TLS 1.2 ( also https) schalten die ab und noch so ein par nur zum beispiel worauf man achten soll.
https://www.google.de/search?q=paypa…2NpPZ8AeGp5WIDQWeil Paypal sagt https glaube ich!
Deiner seite hat kein richtige https wen man testedZitathttp://www.my-kleidung.de gebruikt een ongeldig beveiligingscertificaat. Het certificaat is alleen geldig voor *.ssl.goneo.de.
Pass auf alte Webspace's da kriegt man es oft gar nicht mehr hin ein noch sicheres Zertifikat drauf zu bekommen, da muss man ein menge erst Updaten lassen und oder neue Webspace / Server zulegen
Testen kan man hier aber haken setzen soll nicht public sein
https://www.ssllabs.com/ssltest/