captain_torche

Ben, les liens qui commencent par '/', sont relatifs à la racine du domaine.

Mais qu'il faudra coupler avec un petit relooking de la requête :

Si tu sais que tu ne dois prendre que trois résultats strictement supérieurs à 5, il te suffit de faire une manip du genre :

<?php
$debut = 5;
$nb_res = 3;
$fin = $debut+$nb_res;
$sql = "SELECT * FROM tatable WHERE id <= $fin ORDER BY id DESC LIMIT $nb_res";
?>

Je ne vois pas d'autre solution que de gérer les résultats avec un array en PHP.

Tu ressorts tes résultats 6,7 et 8 avec ta requête, et dans le traitement, tu les stockes dans un array en php.

Ensuite, il te suffit d'utiliser la fonction krsort de PHP, pour inverser l'ordre des clés du tableau.

Si les horaires sont prédéfinis, afficher une icône en fonction de l'horaire, en home du forum.

Si les émissions sont lancées 'manuellement', il suffit d'ajouter une table à la base de données, et de créer un formulaire qui mettra à jour un champ de cette table.

Lorsque la radio sera en ligne, il suffit de valider le formulaire avec la mention (par exemple) 'en ligne', et avec le code adéquat, récupérer cette valeur sur le forum.

Par contre, il ne faudra pas oublier de mettre la radio 'hors ligne' à la fin de l'émission.

000000000137 est considéré comme une chaîne de caractères.

En l'incrémentant de 1, PHP le convertit automatiquement en entier numérique, d'où le 138.

Pour avoir un affichage du genre 000000000138, il faut utiliser la fonction sprintf, avec un code du genre :

<?php
$variable = sprintf("%012d", $row['ref_number']+1);
?>

[Edit : doublement grillé]

D'où la difficulté de rester en première page, vu qu'il y a un nombre plus limité de places

Sinon, tant que ça reste dans le domaine du 'je crois que tu aurais pu te tromper, je vais un peu t'aider', ça passe, mais côté ergonomie, c'est pas du tout ça.

Ca avait déjà été discuté sur ces pages, assez récemment :

Perte de la session PHPSESSID

Problème d'identification derrière un proxy

En espérant que ça répondra à tes questions.

Mais, pourquoi vouloire faire une redirection en JavaScript, alors que tout marche en PHP ?

Personnellement, j'utilise le plus(+), pour éviter d'avoir des urls à tirets à rallonge. Je n'ai malheureusement pas encore assez de stats pour en déterminer l'impact.

Sinon, évite les underscores(_), car il ne sont pas considérés comme un spérarateur de mot. Tu perdrais donc de la pertinence sur les mots-clés dans tes urls.

Le souci, c'est que les cellules, prendront toutes la place disponible dans un tableau !

Si la taille du tableau est définie, elles s'élargiront pour prendre toute la place disponible.

Les solutions :

Crée une nouvelle cellule vide en bas de tableau, sans lui donner de hauteur. Si mes souvenir de design tabulaire sont bons, celle-ci devrait prendre la hauteur 'restante'.

Si ça ne marche pas, insère ton tableau dans un autre tableau qui lui, aura la hauteur de 450px, et l'image en fond.

Tant qu'à faire, il vaut mieux mettre la vidéo dans un DIV, placé en fixe dans la page en CSS :

<style type="text/css">
#video {position: fixed; left: 10px; top: 10px;} 
</style>
<div id="video">
<!-- Ici, le code de ta vidéo -->
</div>

Comme ça, ça sera léger, et compatible avec tous les navigateurs récents.

Même si tu ne l'utilises plus, je corrige ton premier code, qui est un tantinet trop complexe :

D'une part, il vaut mieux exloiter directement les résultats de la requête (plutôt que d'utiliser une boucle for), et ensuite, tu te prends un peu la tête avec les modulos.

<?php
$sql = "SELECT * FROM tatable";
$req = mysql_query($sql);
$nombre = 1;
echo '<table><tr>';
while($result = mysql_fetch_assoc($req)) {
if($nombre%6==0)
    echo '</tr><tr>';
echo '<td>';
echo '<img src="images/'.$result['ID'].'.jpg" />';
echo '</td>';
$nombre++;
}
while($nombre%6!=0) {
echo '<td></td>';
$nombre++;
}
echo '</tr></table>';
?>

[Edit : rajout de la boucle while en fin de code, pour finir avec un nombre correct de cellules]

Oui, j'ai vu, et le souci semble être dû au fait que Firefox modifie la taille de ton div, en 100% de la taille de la fenêtre, et pas de celle du document.

Logiquement, si le reste du site respecte bien cette même règle du 100%, il ne devraut plus y avoir de souci.

Tu n'as pas tort pour l'url rewriting.

Par contre, il n'y a pas de 'vrai' ou de 'faux' GET.

GET, c'est simplement le fait de passer les variables à la suite de l'url de la page. Que ce soit en dur (avec un lien), ou par un formulaire, ça reste la même méthode.

Et sinon, ben non, t'es le premier à me la faire (sérieux). Ou alors, j'étais trop crevé pour m'en rendre compte.

Pour faire simple : un formulaire est destiné à enregistrer des données venant du client (inscription d'une adresse e-mail pour une newsletter, enregistrement d'infos sur le client ...).

Un robot arrivant sur une page contenant un formulaire, ne peut pas remplir ce dernier, et par conséquent, il lui est inutile de l'envoyer.

Par contre, une page listant des articles (chacun ayant un lien pointant vers sa fiche produit), n'utilise pas de formulaires. Par conséquent, les paramètres pour accéder à la fiche produit, sont passés en GET (de la forme page-article.php?id=54).

C'est d'ailleurs cette forme qui sera utilisée pour l'url-rewriting :

prenons un article (un mixeur, par exemple).

Son identifiant dans ta base est 54

Dans ta page, tu as une fonction, qui va générer le lien en fonction de l'identifiant (elle va chercher les infos en base).

Le résultat pourrait être le suivant :

fiche-54-mixeur-a-legumes.html

Dans ton .htaccess (centre névralgique de l'url rewriting), tu auras une règle qui fera que chaque url de cette forme, soit interprétée par le serveur comme

page-article.php?id=54

De cette manière, tu bénéficies d'une pertinence en plus dans les moteurs de recherche (le nom de l'article dans l'url), et le paramètre nécessaire (l'id de l'article) est passé en GET.

C'est le div, ou l'image, à laquelle tu as attribué un width: 100% ?

Un petit peu de code serait le bienvenu.

Dans ce cas, si tu as suffisamment de temps pour laisser tourner le script, et une fois que tu as enlevé les caractères accentués, fais juste ceci :

$search = '`affich_salar.php\?libelle=([a-z-]+),([a-z-]+),_[0-9]{4}`';
$replace = 'fiche-$2-$1.html';
$new_url = preg_replace($search, $replace, $old_url);

Juste pour info : tes urls actuelles sont-elles susceptibles de contenir des caractères accentués ?

Techniquement, si toutes les urls sont selon la même structure (fiche-Prénom-Nom.html), tu peux te passer de cette colonne, puisque tu possèdes déjà toutes les infos nécessaires à la construction de ton url en base (à savoir, le nom et le prénom).

Dans ce cas, il te suffirait, dans la page générant le lien, de construire ce dernier en fonction des noms et prénom.

A part ça :

je ne saurais que te conseiller de ne pas utiliser le tiret comme séparateur dans ce cas précis, car si jamais tu tombes sur un salarié du nom de Jean-Louis Dupont, l'url deviendra fiche-Jean-Louis-Dupont.html, et ton url rewriting va faire la gueule.

[Edit :]

je suis également en train de penser à deux choses :

la première : il faut que tu enlèves les caractères accentuées des prénoms et noms des employés, dans les urls.

Et sinon, si jamais tu as deux emplyés de même nom ? (Deux Jean Dupont, par exemple).

Si j'ai bien compris, ton url-rewriting ne concerne que les nom et prénom, sur lesquels il y a risque d'y avoir un doublon.

Ce que je préconiserais (en fait, ce que j'utilise), c'est de passer l'url de cette manière :

fiche-ID-Prénom-Nom.html

L'url-rewriting ne récupérant que l'ID (unique par définition) pour la page de traitement, qui n'effectuerait sa requête que sur ce champ (d'où un gain de performances).

Et, dans cette optique, les prénoms ou noms composés, n'ont plus d'importance.

Avec l'url rewriting, tu peux très bien mettre les mots-clés (non pris en compte dans la page), où tu veux, c'est vrai.

Donc, il est possible de les mettre avant l'extension, également

Mais sinon, c'était juste pour satisfaire ma curiosité maladive.

C'est surtout par rapport à la position dans l'url, que je me posais la question : Google accorde plus de poids aux mots-clés passés après l'extension ? (Et déjà, dans la forme actuelle, reconnaît-il l'extension ?)

Juste par curiosité : pourquoi veux-tu mettre les mots-clés 'après' le .html ?

Y a t'il une signification précise ? Ou c'est par choix personnel ?

J'imagine que ce genre de service, doit être asujetti à une offre payante : je pense qu'ils doivent louer leur serveur, payer les communications, et divers frais.

Donc, ça doit sûrement exister, mais pas de manière gratuite.

Ou sinon, tu peux également appeler les fichiers, relativement à la racine du serveur :

<?php
include '/chemin_vers_le_fichier/fichier.php';
?>

Comme free a certaines limitations de PHP (je n'ai pas de phpinfo sous la main), il est possible qu'il ne supporte pas (ou supporte mal) les inclusions absolues.

Remplace tes codes par

<?php include "menu.html"; ?>

, ça devrait marcher beaucoup mieux avec des urls relatives.