Doorlinkservice of domain pointer of allebei

Status
Niet open voor verdere reacties.
Dan moet ik er nog eens induiken, heb nu even snel wat gekeken en gedaan wat je zei, maar ik k rijg die venstertjes niet te zien hoor.
Je hoort nog!
Alvast bedankt voor je moeite!
 
Oho! :shocked:
Ik zie dat in Gimp 2.8 de opslag-methode aanzienlijk veranderd is (via www.omgubuntu.co.uk/2012/05/gimp-2-8-released naar www.gimpusers.com/tutorials/gimp-2-8-features-preview-april-2010).
Onder punt 5 staat daar:


  • "Changed file export offers a siginificantly faster workflow!
    The “Save” and “Save as” function is now only used to store GIMPs own file format XCF. No save as png or jpg is available here.

    If you want to make a png version of an open file you have to export it using the new “EXPORT” entry. This offers all file formats you previously know GIMP is capable of."

Dat is dus andere koek. :) Welke versie draai jij?
 
Laatst bewerkt:
Ik heb de nieuwste nog niet, ik heb dus nog 2.6
Vandaar!
 
Ik weet dat er verschil in zit, tussen de Linux versie en Windows, maar welke dat zijn, weet ik dus niet. Ik gebruik geen Windows.
Nou ja, even een andere manier zoeken denk ik, aangezien je in Gimp niet helemappen met foto's kan comprimeren. Dus mijn hoop was die van Devil, maar die doet niet wat hij moet doen, hij gaf geen verschil op een foto van 2 MB naar 1 MB bijv. Jammer!
 
... aangezien je in Gimp niet hele mappen met foto's kan comprimeren.
Klik om te vergroten...
Toe maar! Je wilt dus "batch conversion". :)

Misschien moet je dan voor één keer van je geloof afstappen ;) en een Windows-kast opzoeken waar IrfanView op zit (of kan komen).
De hele image-directory op een USB-stick zetten, of op een CD-rommetje branden voor het transport (ze zijn toch wel met Mint er op te zetten en met Windows uit te lezen, en vice-versa, als het img-bestanden zijn?).
  • Of anders aftappen/heruploaden met FTP.

Want IrfanView heeft aan boord:
=======
Batch Conversion/Rename
Click on the File Menu, select Batch Conversion/Rename. A dialog allows you to select a directory from which the files will be taken. Use Look in, File name and Files of type to limit the search.

Select the output directory at middle right. If you don't have the full path for this directory, click the Browse button to find it. Find a directory and when you have selected a directory, click the OK button to load the directory name as output directory.

You can set the current directory as output directory, if you press the Use this directory as output button.

Batch Conversion:
Select the Output Format at bottom left. This works just like Save and Save As. The Options button lets you choose from the various file format specific save options, just like the Save and Save As dialog.

Use the Set advanced options button to apply many special operations to the images during conversion. These options are much like their versions on the Image Menu. The options are:
  • Crop, Resize, Change color depth, Auto adjust colors, Horizontal flip, Vertical flip, Rotate left, Rotate right, Convert to greyscale, Negative, Sharpen, Brightness, Contrast, Gamma correction, Saturation, Color balance, etc.

Hint: for Batch Resize: If you set both, width and height, to e.g. 640 and activate the preserve aspect ratio option, the result image dimensions are: width = max. 640, height = max. 640, proportional.​
=======
Staat Windows waarschijnlijk wel even te stampen, maar intussen kan je iets leuks gaan doen. :d

Met vriendelijke groet,
CSShunter
 
Even naar die foto-mappen gekeken:



Doe dat met 10 foto's, en je gaat van 38MB naar 1,65MB.
Dus het klusje gaat zeker de moeite lonen: de bezoeker is 25 keer zo snel af en je haalt bijna je hele server leeg. :cool:
 
Precies!!
En daarom zei ik ook, de foto's verwijder ik allemaal van de server, ga ze allemaal op mijn pc comprimeren (of map voor map en pagina voor pagina op de site, anders staat er niets meer op de website) en dat scheelt enorm natuurlijk!

Tja, en dat Windows, er moet toch iets zijn wat in Mint foto's van comprimeren.
Ik ga zoeken!!

Heb jij die foto nu gedaan met Gimp of met iets anders?
 
O, met PaintShopPro, want die ben ik gewend. *)
Maar met Gimp had 't ook gekund, en met IrfanView ook.

______________
*) PSP kan wel batchen, maar alléén om het bestandstype te veranderen: niet om alles op 1 formaat te schalen. IrfanView kan dat wel.
 
Hé....................wat lief van je dat je bent gaan zoeken.
Ik ga er straks even naar kijken, maar zo te zien zo even gauw, kan dit wel eens wat zijn.
Nu had ik op het Ubuntu forum waar ook Mint gebruikers zitten (maar Mint is gebaseerd op de repro's van Ubuntu dus.....wat je in Ubuntu gebruikt kan je ook in Mint gebruiken) maar dat heb ik nog niet gelezen, of daar reactie op gekomen is.
Bedankt en ik laat het deze dag even weten!!

(moest wel even lachen, ik wil mijn website voor de vereniging goed, snel en "perfect" maken. Ik klik op de link, zie ik die website. Nou ja, niet iedereen is het zelfde zullen we maar zeggen. ;))
 
Laatst bewerkt:
Hoi Femke,
... wil mijn website goed, snel en "perfect" maken.
Klik om te vergroten...
Perfect? Zoiets hier nooit hardop zeggen! :P
En ook niet zachtjes zeggen! :)
En zelfs niet fluisteren. :rolleyes:

=======
De overdaad aan html-errors wordt er in geplugd door het Wordpress-CMS (met ongeldige rel="..." eigenschappen), daar kan jij ook niets aan doen.
Maar weer wel een beetje. Want als je kans ziet om het Doctype te veranderen van:
HTML: 
<!DOCTYPE html><!-- HTML 5 -->
<html dir="ltr" lang="nl-NL">
naar:
HTML: 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="nl" xml:lang="nl">
... dan blijven er nog maar zo'n 20 "echte fouten" over.
Daar kan je altijd nog eens naar kijken.

=======
Wat betreft de css-errors: die zitten vooral in de browser-specifieke codes om alle browsers hetzelfde te laten doen. Daar zou ik me niet al te druk over maken.
Wat me opeens opvalt: er zitten ruim 400 code-regels aan "embedded css" in de <head> (en deels in de <body>!) van elke pagina! Dat is ongeveer 1/3 van het totale aantal html-coderegels van een pagina. Als die regels in een apart stylesheet worden gezet, hoeven ze niet elke keer meegenomen te worden, want dan zijn ze al aanwezig op de kast van de bezoeker. Snelheidswinst!

Met vriendelijke groet,
CSShunter
 
Daarom staat perfect ook tussen aanhalingstekens!! hahahaha.

Wat het Doctype betreft: waar moet ik dat veranderen dan? Kan je mij dat aangeven?

Wat me opeens opvalt: er zitten ruim 400 code-regels aan "embedded css" in de <head> (en deels in de <body>!) van elke pagina! Dat is ongeveer 1/3 van het totale aantal html-coderegels van een pagina. Als die regels in een apart stylesheet worden gezet, hoeven ze niet elke keer meegenomen te worden, want dan zijn ze al aanwezig op de kast van de bezoeker. Snelheidswinst!
Klik om te vergroten...
En wat kan ik daar aan doen? Wat mij zegt het helemaal niets.

ps. fouten afkomstig van Fancybox, daar kan ik weinig tot iets aan doen, want dat is een plugin die zorgt ervoor dat de foto's in een popup komen als je op de eerste klikt op een pagina met foto's.
Ik kan het ook zonder Fancybox, maar dan heb je elke keer 1 foto op de pagina en moet je elke keer weer terug om de volgende te kunnen zien. En dat is niets natuurlijk.
 
Laatst bewerkt:
csshunter zei:
Hoi Femke,

Perfect? Zoiets hier nooit hardop zeggen! :P
En ook niet zachtjes zeggen! :)
En zelfs niet fluisteren. :rolleyes:

=======
De overdaad aan html-errors wordt er in geplugd door het Wordpress-CMS (met ongeldige rel="..." eigenschappen), daar kan jij ook niets aan doen.
Maar weer wel een beetje. Want als je kans ziet om het Doctype te veranderen van:
HTML: 
<!DOCTYPE html><!-- HTML 5 -->
<html dir="ltr" lang="nl-NL">
naar:
HTML: 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="nl" xml:lang="nl">
... dan blijven er nog maar zo'n 20 "echte fouten" over.
Daar kan je altijd nog eens naar kijken.

=======
Wat betreft de css-errors: die zitten vooral in de browser-specifieke codes om alle browsers hetzelfde te laten doen. Daar zou ik me niet al te druk over maken.
Wat me opeens opvalt: er zitten ruim 400 code-regels aan "embedded css" in de <head> (en deels in de <body>!) van elke pagina! Dat is ongeveer 1/3 van het totale aantal html-coderegels van een pagina. Als die regels in een apart stylesheet worden gezet, hoeven ze niet elke keer meegenomen te worden, want dan zijn ze al aanwezig op de kast van de bezoeker. Snelheidswinst!

Met vriendelijke groet,
CSShunter
Klik om te vergroten...

In mijn header.php staat het volgende:
Code: 
<!DOCTYPE html><!-- HTML 5 -->
<html <?php language_attributes(); ?>>
Dus iets anders dan jij vertelde.

Moet ik dan die header.php veranderen in wat jij zegt:
HTML: 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="nl" xml:lang="nl">

Wil je dat nog even aangeven? Of moet ik niet in de header.php zijn, aangezien ik iets anders zie staan dan jij.
 
ps. Ik heb het gewoon gedaan, hahaha. De oude wel even genoteerd in gedit uiteraard.
Ben benieuwd hoeveel fouten ik nu nog vind. Het worden er steeds wat minder!!

Krijg nu minder fouten te zien op het DocType, maar toch nog een aantal. Is raar toch, aangezien ik het veranderd heb.

Houd structuur en vormgeving zoveel mogelijk gescheiden: gebruik HTML of XHTML voor de structuur van de site en CSS voor de vormgeving ervan. Deze pagina bevat een strikte DOCTYPE en bevat geen inline styles. (die is dus goed)

Gebruik HTML 4.01 of XHTML 1.0 volgens de W3C specificaties voor de markup van websites. De DOCTYPE van de pagina lijkt ongeldig te zijn. (die niet)

Bij het aanpassen van een bestaande website: gebruik van HTML 4.01 of XHTML 1.0 alleen de Transitional variant als het gebruik van de Strict variant onmogelijk of onwenselijk is. Er is geen geldige DOCTYPE gevonden. (die ook niet)

en dan zijn er nog 2 die iets aangeven van het DocType.

(misschien wil je zelf weer even via http://versie1.webrichtlijnen.nl/toetsen voor mij kijken?
 
Laatst bewerkt:
Moet ik dan die header.php veranderen in wat jij zegt: ...
Klik om te vergroten...
Correct! Ik vermoedde al dat het in de header.php geregeld zou worden, maar omdat het dat een php-onderdeel van het CMS is, kan ik dat niet zien.
Ik zie alleen de uitkomst in html (waarbij de php op de server dus de inhoud van de variabele language_attributes() heeft geplaatst).
Die inhoud was dus kennelijk dir="ltr" lang="nl-NL"
Dan klopt het weer als een zwerende vinger, en is het verschil verklaard: er is geen verschil.

Prettig dat je de header.php hebt gevonden, want zo is het meteen mooi geregeld.
  • Waarschijnlijk heb je op een heel andere plaats (in een of andere algemene instellingen-riedel waarschijnlijk) bij de site-eigenschappen opgegeven dat de voertaal van de site NL is, anders kan Wordpress dat nooit weten > vervolgens heeft die dat als inhoud in onze variabele gestopt.
  • Door direct de header.php te wijzigen, heb je dat nu gepasseerd.

======
De huidige Quickscan-resultaten onder de loep

Deze pagina bevat een strikte DOCTYPE en bevat geen inline styles. (die is dus goed)
Klik om te vergroten...
Ehm, ja, die is dus goed ... als het goed is.
Maar hier maakt de Quickscan een erbarmelijke vergissing!
  • Het Doctype is helemaal niet Strict, maar Transitional! Dat heb je nu verordonneerd, dat zie je in de broncode van de homepage, en dat wordt ook automatisch vastgesteld door de html-validatie van de pagina: Doctype (detect automatically): XHTML 1.0 Transitional.
  • Snap ik helemaal niets van. Maar er zitten fouten in de pagina, waardoor de Quickscan zich wellicht verslikt. Dat komen we misschien nog tegen.

===
De DOCTYPE van de pagina lijkt ongeldig te zijn. (die niet)
Klik om te vergroten...
Dat is dus in strijd met de bewering dat het een mooie Strict is!
Alweer misgeschoten door de Quickscan. - Dat kom ik toch niet vaak tegen. :eek:

===
Bij het aanpassen van een bestaande website: gebruik van HTML 4.01 of XHTML 1.0 alleen de Transitional variant als het gebruik van de Strict variant onmogelijk of onwenselijk is.
Er is geen geldige DOCTYPE gevonden. (die ook niet)
Klik om te vergroten...
De eerste zin hebben ze gelijk in: liefst Strict. Maar dat is hier onmogelijk/onwenselijk, want er staan links in die op een nieuw tabblad moeten openen. Dan kan er geen Strict gebruikt worden.
De tweede zin is een herhaling van de verkeerde diagnose.

===
en dan zijn er nog 2 die iets aangeven van het DocType.
Klik om te vergroten...
Ja, en er staan nog een paar merkwaardige opmerkingen bij:
Specificeer de basistaal van een pagina in de markup. - Er is geen basistaal voor de pagina gespecificeerd.
Klik om te vergroten...
  • Welles! :p
  • Die basistaal staat keurig in het Doctype: lang="nl" xml:lang="nl".
===
Specificeer de UTF-8 karakterset. - De UTF-8 karakterset is niet gespecificeerd.
Klik om te vergroten...
  • Welles! :p
  • Die staat keurig in de regel: <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
===
Specificeer de karakterset voor webpagina's. - 1601 geen karaktersetclass locationresultmodel { var $in_cmd = NULL; var $in_wid = NULL; var $in_cid = NULL; var $in_lid = NULL; var $in_aid = NULL; var $in_user = ... enz enz.
Klik om te vergroten...
  • Dat is wel een hele rare specificatie van de karakterset, en iets heel anders dan onze <meta>regel!
===
En dan de laatste van het opmerkingenrijtje:
Gebruik (minstens) het meta element voor het specificeren van de karakterset en plaats dit element zo hoog mogelijk in de head sectie van de markup.
- Er is geen meta tag gevonden waarmee de karakterset wordt gespecificeerd.
Klik om te vergroten...
En ééééé, daar komt de orang-oetang uit de mouw! :)
De <meta>regel met de utf-8 charset staat niet zo hoog mogelijk in de <head>, dwz. meteen na de <head>-tag.

Wat staat er wel in de broncode? Een <script>-aanroep voor het jquery.js.
Dit opdringerige javascript op de verkeerde plaats haalt alles overhoop!
  • Dat verklaart dan de abracadabra in het "geen karaktersetclass locationresultmodel" dat werd gesignaleerd.
  • Het zal ook de Quickscan-rariteiten over het Doctype en de charset veroorzaken.
En ... browsers zullen er waarschijnlijk ook last van hebben: een mogelijke reden voor vertraging en lagere paginasnelheid!!!

Kortom:
De <meta>regel met de charset moet naar boven gehesen worden in de html-code.


  • Zie de hocus-pocus: dan zijn alle rare opmerkingen opeens helemaal weg!
    Het gevonden Doctype is nu Transitional, zoals het hoort, enz.
    Er zijn wel andere fouten/opmerkingen bijgekomen, maar die slaan nu ergens op.

Tip:
  1. Eerst de errors corrigeren die de html-validator aangeeft.
  2. Daarna pas de Quickscan er op los laten om de pagina bijzonder perfect te maken.

Met vriendelijke groet,
CSShunter
 
Hé, jij bent goed!!

Maar....ik snap even niet wat ik nu moet doen.
Moet ik nu nog iets veranderen en waar moet ik dat doen?

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
Hier gaat het dus om, neem ik aan en die staat nu in jouw test wel goed, maar waar moet ik dat veranderen, is dat in de head.php?

Kan jij dat aangeven?

Trouwens, in jouw test (de link dus, geweldig dat je dit doet!!) zie ik nog steeds dat DocType niet goed is. Er lijkt geen strikte DocType te zijn gebruikt. Dus dat snap ik toch niet helemaal.
En ja, die javascripts, dat zijn sowieso die Cookie Control, en nog iets.............maar dat hou je toch echt niet tegen, lijkt mij. Ik vind dat ook niet zo heel erg.

En dan de rest van de fouten neem ik voor lief hoor, die nu nog overblijven.
 
Dit is de header.php in mijn DirectAdmin.
Ik zie die meta charset toch keurig in de head staan.

Code: 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="nl" xml:lang="nl">

<head>
	<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />
	<link rel="pingback" href="<?php bloginfo('pingback_url'); ?>" />
	
	<title><?php bloginfo('name'); if(is_home() || is_front_page()) { echo ' - '; bloginfo('description'); } else { wp_title(); } ?></title>

<?php if ( is_singular() ) wp_enqueue_script( 'comment-reply' ); ?>
<?php wp_head(); ?>
</head>

<body <?php body_class(); ?>>
<div id="wrapper">

	<div id="header">

			<div id="logo">
				<?php 
				$options = get_option('themezee_options');
				if ( isset($options['themeZee_general_logo']) and $options['themeZee_general_logo'] <> "" ) { ?>
					<a href="<?php echo home_url(); ?>"><img src="<?php echo esc_url($options['themeZee_general_logo']); ?>" alt="Logo" /></a>
				<?php } else { ?>
					<a href="<?php echo home_url(); ?>/"><h1><?php bloginfo('name'); ?></h1></a>
				<?php } ?>
			</div>
			<div id="navi">
				<?php 
					// Get Navigation out of Theme Options
					wp_nav_menu(array('theme_location' => 'main_navi', 'container' => false, 'menu_id' => 'nav', 'echo' => true, 'fallback_cb' => 'themezee_default_menu', 'before' => '', 'after' => '', 'link_before' => '', 'link_after' => '', 'depth' => 0));
				?>
			</div>
	</div>
	<div class="clear"></div>
	
	<?php if( get_header_image() != '' ) : ?>
	<div id="custom_header">
		<img src="<?php echo get_header_image(); ?>" />
	</div>
	<?php endif; ?>
	
	<div id="wrap">

Ik zie het verschil met jouw test en met mijn voorpagina.

Die van mij ziet er zo uit, als ik via de brower de paginabron wil zien:
Code: 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html
xmlns="http://www.w3.org/1999/xhtml" lang="nl" xml:lang="nl"><head> <script type='text/javascript' src='http://www.hsvnaardenbussum.nl/wp-content/plugins/wp-minify/min/?f=wp-includes/js/jquery/jquery.js&amp;m=1333311216'></script> <meta
http-equiv="Content-Type" content="text/html; charset=UTF-8" /><link

Maar ik weet dus niet waar ik dat moet veranderen. In welke file uit de Direct Admin, want zoals je ziet, is de header.php niet de goede dus, want dat ziet er anders uit dan de paginabron.
Ik zit al te kijken in de files van de DirectAdmin, maar kan het vooralsnog niet vinden.

ps. ik heb Firebug, en daar kan je het een en ander mee veranderen, maar dat heb ik nog nooit gedaan en weet dus niet hoe.
 
Laatst bewerkt:
Ik moet in de index.html zijn, bedacht ik mij opeens..............maar....................die kan ik helemaal niet vinden in de DirectAdmin!!

Okee, ik heb het volgende gedaan.

Ik heb jouw hele code overgenomen, dus de hele index en deze als index.html opgeslagen in de DirectAdmin waar deze hoort. Dus waar ook de index.php staat (die was er wel!!) en waar ook de pagina's 401 en zo staan. Hoewel deze opgeslagen zijn als shtml bestanden, heb ik de index gewoon op html gelaten.

Nu start ik de website op en kijk dan weer eens naar de paginabron en zie daar, het is precies die van jouw.

Ik ga hem nu weer testen in Webrichtlijnen quickscan.

(edit: nog steeds een aantal doctype fouten)

Edit 2: maar als ik de paginabron bekijk van bijv. "Voor uw gelezen" dan staat het daar toch weer fout! (en ik denk dan ook de andere pagina's!!)
Waar verander ik dat dan?
 
Laatst bewerkt:
Ik hoop dat je mij nu even wilt helpen, want er gaat iets stevig mis.

Op de site van hsvnaardenbussum.nl kan ik een nieuw bericht schrijven, maar deze wordt niet meer getoond op de v0orpagina. Wel ergens anders, maar bij de updates en dus de voorpagina niet.
En ook de zoekfunctie doet het niet meer.

Hoe kan dit opeens en hoe lossen we dit zo snel mogelijk op?

edit: kwam door de index.html die ik had aangemaakt, dus die weer verwijderd!
Zo leren we nog eens wat, hahahaha!
 
Laatst bewerkt:
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan