[RÉGLÉ] Question portant sur une tâche CRON

[Visiteur]

Je possède 2 tâches CRON que mon serveur exécute chaque nuit sur mon site.
Pour permettre à ce serveur d'atteindre sans problème ces tâches, j'ai paramétré les 2 liens correspondants :
- en accès public,
- et dans l'onglet "lien" de chaque tâche, j'ai demandé le "non affichage du lien dans le menu" (pour éviter l'exécution catastrophique de ces tâches par toute personne, enregistrée ou non sur le site).
Mais ceci crée un problème, Google me reprochant de "cacher des informations" !

Question : quelle est la technique adéquate à utiliser ?

nb: chacune de ces tâches est un script php & mysql écrit dans un article Joomla

[Visiteur]

Peut-être qu'une solution réside dans l'enregistrement des 2 scripts de tâches dans 2 fichiers xxx.php placés dans un dossier particulier du site ? Ceci éviterait d'avoir à définir 2 liens cachés.

[RobertG]

Ce serait peut-être en effet plus simple.

[Visiteur]

Ce serait peut-être en effet plus simple.

Merci RobertG.
Mais après un test, cela ne fonctionne pas. Car je fais appel dans mes scripts à JFactory & JImport !

Question: existe t-il un moyen de faire fonctionner ces 2 librairies -JFactory & JImport- à partir de scripts logés dans un dossier annexe mais placé à la racine du site ?

[lefabdu51]

salut,
regardes le contenu du dossier cli de ton site.
La tu auras des exemples à modifier et qui font appel au framework.
Vu que tu parles de taches cron, celle ci doit avoir une commande php directement vers le fichier de ta tache.
Et tu l'édites depuis le serveur via crontab -e.
C'est la procédure si c est un serveur dédié.

Ps: normalement, tu n as aucun lien de menu à créer pour ces tâches.
Et les fichiers écrit dans les articles doivent faire quoi au juste?
Ton contenu php est il parsé directement via sourcerer ou pas?

[Visiteur]

salut,
regardes le contenu du dossier cli de ton site.
La tu auras des exemples à modifier et qui font appel au framework.
Vu que tu parles de taches cron, celle ci doit avoir une commande php directement vers le fichier de ta tache.
Et tu l'édites depuis le serveur via crontab -e.
C'est la procédure si c est un serveur dédié.

Ps: normalement, tu n as aucun lien de menu à créer pour ces tâches.
Et les fichiers écrit dans les articles doivent faire quoi au juste?
Ton contenu php est il parsé directement via sourcerer ou pas?

Bonjour et merci de ton aide, lefabdu51.

1. j'ai bien regardé attentivement le contenu de mon dossier "cli": mais je ne comprends pas suffisament pour en élaborer ensuite ma solution,
2. écrits tel quel dans des articles Joomla, mes 2 scripts sont parsés par le plugin Sourcerer (pour utilisation avec un lien de menu). Mais je les ai écrits dans mon nouveau dossier comme des scripts php à part entière, sans Sourcerer.
Ils fonctionnent si je ne fais pas appel à des notions de "class" logées dans mon template, ou aux librairires JFactory & JImport. Je peux me passer de JImport, mais plus difficilement de JFactory,
3. ces scripts ont pour fonction :
- l'un de générer les créneaux horaires d'un nouveau jour dans un planning, et de faire une màj de la BDD (cf. JFactory),
- l'autre d'envoyer des mails aux clients, et de mettre à jour une table de BDD (cf. JFactory).

Je viens de créer mes 2 tâches CRON depuis mon CPANEL et en activant directement les urls des 2 articles Joomla parsés avec Sourcerer, et j'ai détruit les liens de menu cachés par sécurité ... et qui incommodaient Google..
Je verrais demain matin comment ont tourné mes 2 tâches dans la nuit !

[roland_d_alsace]

Bonjour et merci de ton aide, lefabdu51.

1. j'ai bien regardé attentivement le contenu de mon dossier "cli": mais je ne comprends pas suffisament pour en élaborer ensuite ma solution,
2. écrits tel quel dans des articles Joomla, mes 2 scripts sont parsés par le plugin Sourcerer (pour utilisation avec un lien de menu). Mais je les ai écrits dans mon nouveau dossier comme des scripts php à part entière, sans Sourcerer.
Ils fonctionnent si je ne fais pas appel à des notions de "class" logées dans mon template, ou aux librairires JFactory & JImport. Je peux me passer de JImport, mais plus difficilement de JFactory,
3. ces scripts ont pour fonction :
- l'un de générer les créneaux horaires d'un nouveau jour dans un planning, et de faire une màj de la BDD (cf. JFactory),
- l'autre d'envoyer des mails aux clients, et de mettre à jour une table de BDD (cf. JFactory).

Je viens de créer mes 2 tâches CRON depuis mon CPANEL et en activant directement les urls des 2 articles Joomla parsés avec Sourcerer, et j'ai détruit les liens de menu cachés par sécurité ... et qui incommodaient Google..
Je verrais demain matin comment ont tourné mes 2 tâches dans la nuit !

1) +1 avec lefabdu mais uniquement s'il s'agit d'une "moulinette" à usage unique.

Mais la place de ton script, vu qu'il est à usage régulier et cyclique, est plutôt dans un composant (le tien).

Surtout que de temps en temps (ou pour faire des tests) tu souhaiteras lancer tes scripts depuis l'administration.

Pour cela tu peux utiliser un contrôleur et un model spécifique.

Par exemple la méthode "lance" du contrôleur ./components/com_toncomposant/controllers/cron.php
que tu lancerais avec l'url :

https://www.tonsite.com/index.php?option=com_toncomposant&task=cron.lance

Un peu aussi comme le fait Acymailing pour envoyer les newsletters depuis un cron perso.

2) Pour envoyer des mails le mieux serait aussi d'utiliser les API de acymailing pour te créer une liste de diffusion et une newsletter (à usage unique) (voir : https://www.acyba.com/acymailing/64-...mentation.html)

Ainsi tu bénéficierais de toute la logique de ce composant pour éviter d'être classé en spam par les FAI et les clients de messagerie.

Et accessoirement tu n'aurais pas besoin d'une tâche cron supplémentaire, vu que c'est le cron d'Acymailling qui se chargerait de l'envoi.

3) Pour générer des créneaux horaires dans un planning d'un composant tiers, si ce composant respecte la norme de programmation de Joomla, il faut faire appel à la méthode correspondante du model adéquat du composant et garder une table de chainage pour ne pas faire de doublons lors des mises à jour (je l'ai fait avec Jevents par exemple pour injecter des compétitions importées d'un webservice Fédéral).
Ainsi tu es (presque) sûr de ne pas avoir de surprise en cas de mise à jour de la structure des données lors d'une mise à jour du composant en question.

[lefabdu51]

roland_d_alsace
Une moulinnette unique dans une tache cron....
Mais le principe, c est de recuperer le code, créer la fonction et ensuite l'éxécuter.
Sans voir le code en lui même, dur de dire.. mais pour moi, cela reste le plus simple

Visiteur
Ce serait possible d'avoir le code de tes articles par mp pour voir comment t en faire des scripts?

[Visiteur]

roland_d_alsace
Une moulinnette unique dans une tache cron....
Mais le principe, c est de recuperer le code, créer la fonction et ensuite l'éxécuter.
Sans voir le code en lui même, dur de dire.. mais pour moi, cela reste le plus simple

Visiteur
Ce serait possible d'avoir le code de tes articles par mp pour voir comment t en faire des scripts?

Merci pour ta proposition. Comme je l’ai écrit précédemment, je verrai demain matin d’après le résultat du fonctionnement de mes 2 CRONS cette nuit.
Si pas ok, je te les envoie.

[roland_d_alsace]

roland_d_alsace
Une moulinnette unique dans une tache cron....
...

Non bien sûr on ne lance pas une "moulinette" par un cron.

C'est le fait de faire un outil de la sorte donc on utilisant le framework hors CMS que je dédie aux "moulinettes" à usage occasionnel.

....
Mais le principe, c est de recuperer le code, créer la fonction et ensuite l'éxécuter.
Sans voir le code en lui même, dur de dire.. mais pour moi, cela reste le plus simple
...

Oui bien sûr je suis de ton avis, cela évite de créer un composant, surtout si on est pas dev.

Mais si c'est pour un usage récurrent, je pense qu'il est bon de passer un peu de temps pour faire un petit composant avec une partie admin, surtout qu’apparemment les besoins justifieraient d'utiliser des méthodes d'autres composants.

Ce n'est qu'un avis et quelques idées.
Ensuite à chacun ses façons de faire, en tenant compte aussi de l'investissement qu'il souhaite y consacrer.

[Visiteur]

lefabdu51
Euréka : mes 2 tâches CRON fonctionnent à merveille. Le test effectué en réel cette nuit est probant. Et je n'ai plus la présence gênante sur mon siite de 2 liens cachés.
Merci à vous tous pour vos conseils, et bonne journée.

[lefabdu51]

un composant n'as pas le même but qu'une tache cron...
Une tache cron est une procédure, un composant geres le contenu et est axé sur les événements...
Le fait que tu utilise des classes ou fonctions Joomla ne changes pas le but de chaque procédure.

[roland_d_alsace]

un composant n'as pas le même but qu'une tache cron...
Une tache cron est une procédure, un composant geres le contenu et est axé sur les événements...
Le fait que tu utilise des classes ou fonctions Joomla ne changes pas le but de chaque procédure.

Merci pour la leçon, mais je n'ai jamais comparé un composant au sens Joomla et le cron de Linux.
J'aurai bien du mal à comparer l'incomparable.

Nombreux sont les composants qui ont une tâche appelée périodiquement.

La plupart du temps on intercepte la venue d'un internaute pour voir s'il n'y a pas un "truc" à faire, comme envoyer des mails par exemple.
Ceci juste pour simplifier la vie des webmasters.

Mais les composants un peu plus sérieux font appel à des taches cron pour lancer leurs procédures récurrentes.

C'est la cas d'Acymailing ou d'Acysms.
Ce donc donc bien des composant qui utilisent des tâches cron et inversement des taches cron qui appellent des routines d'un composant, ne t'en déplaise.

Dans le cadre d'un outil pour Joomla, on ne peut pas conseiller à un développeur de placer un code à lui dans l'arborescence du CMS ou du Framework, même s'il s'agit d'un tout petit fichier avec un tout petit bout de code.

Pour moi la formule la plus respectueuse des normes de développement de notre framework préféré est de placer ces routines dans un model d'un composant, appelées par un contrôleur, même s'il n'y a pas besoin d'une partie "frontale" (ni même d'une partie "admin").

Après comme je l'ai déjà dit, chacun fait comme il veut et notre ami a trouvé la solution à son problème, c'est très bien.

Bon dev.