Anotações sobre o uso de tecnologia.
Um local para compartilhar as minhas dúvidas, preocupações e achados.
Blog
-
site na HostNet fora do Ar.
HostNet Sábado frio de outono. Na minha caixa de mensagens, uma solicitação da redatora do site, relatando dificuldades de acesso. Ainda temos dificuldades de report de problemas, mas acho que isso é algo que é preciso ir aprimorando.
Uma primeira tentativa de acesso e podemos ver que o site não tem acesso ao banco de dados, apresentando o erro :
This page cannot be displayed due to an internal error.
You can provide the following information to the administrators of this site to help them solve the problem:
Error: Unable to connect to database
Tentativas de acesso ao painel de controle no provedor bem sucedida. Registro o problema para o Suporte do provedor. Pela urgência da situação, recebo a ligação telefonica da Editora do site. Estamos atuando no problema.
Tentativas de contato por telefone com o Suporte, mas a ligação cai logo após o redirecionamento ao serviço de suporte técnico. Problemas com a qualidade de serviço.
Sabendo que o problema é com o Banco de Dados, tento acesso ao banco de dados pelo phpMyAdmin, obtendo o erro.
phpMyAdmin – Erro
#1040 – Too many connections
Será que temos outros webmasters com problemas…. Muitos fazendo acesso neste momento. Aguardemos. Problemas de capacidade?
De repente, estamos de volta ao ar. Tempo Estimado de Indisponibilidade : 7hs (observado pelo acompanhamento dos acessos no log).
Encerrei a ocorrencia no Help Desk. Será que um dia conseguiremos sair deste atendimento reativo e obter um atendimento mais próativo, detectando a falha e corregindo mais rapidamente?
-
Codificação dos caracteres, ISO8859-1, UTF-8…
Apanhando mais que boi ladrão, estas são as minhas notas sobre o problema da codificação de caracteres em meus site, sobre as condições de contorno, etc.
Se aparece o losangulo preto com a interrogação ( � ) , é sinal que a página está sendo mostrada em formato UTF-8 mas o caracter, no arquivo ou no banco de dados, está codificado com formato ISO8859-1.
Se aparecem caracteres duplicados ( Páginas disponÃveis para vincular ), é sinal que a página está sendo codificada em formato ISO8859-1 enquanto o caracter no arquivo ou no banco de dados está em formato UTF-8.
Referências
- O mínimo absoluto… – texto com os conceitos básicos sobre o conceito de codificação de caracteres. Isso você deve ler.
- PHP, MySQL e UTF-8 (o guia) – um tutorial que pode ajudar na solução de problemas com a codificação de caracteres.
- Archived – Mac OS X: How to Set Up TextEdit as an HTML or Plain Text Editor – No caso do Mac, também é possível impor a codificações de caracteres para os textos.
- Character encoding and Mac OSX – um pouco mais sobre a codificação de caracteres no Max OSX.
- Change your browser’s character encoding – as vezes, não é tão simples ajustar a codificação de caracteres em seu navegador. Cada um quer inventar a sua moda.
-
smartsection para a versão 2.14
Estas são as notas para a atualização do SmartSection para a versão 2.14 nas minhas instalações Xoops 2.4.4.
Não sei ao certo porque estou fazendo esta atualização, mas algumas coisas que me incomodam é quanto a falta de tradução de alguma variáveis no módulo. Vamos procurar corrigir estes problema na versão mais atual.
Não entendo porque, mas parece que esta nova versão do Smart Section requer o módulo Smart Objects instalado. Baixando do site SmartFactory. Os hacks no núcleo do xoops são necessários somente para usos especiais do SmartObjects.
Parece que está funcionando… Vamos acompanhar para ver como fica.
-
datas no News 1.64 do Xoops 2.4.4 …
Parece que temos algum problema com as datas no módulo News (1.64) do Xoops 2.4.4. Quando especificamos a data de expiração para uma notícias, observamos que a data entrada é alterada internamente no sistema, causando a expiração da notícia em data errada.
Depois de pensar um pouco sobre o caso, pedi ajuda no forum do GuxBrasil.org. Mas continuo estudando o problema.
Aparentemente, no processo de tradução do módulo News ou do próprio Xoops core, introduzimos alguma incompatibilidade entre os formatos de datas.
O PHP tem a função date() que providencia a formatação mais adequada para as datas. Mas, deveria trabalhar sempre sobre uma data em formato padrão interno. Se bem usado não deveria causar maiores problemas.
Por indicação do Andrax, subi a versão do módulo News para 1.66. Parece que já ajuda um pouco.
Clique no Icon da Agenda em Editar Notícia não funciona.
No meu site pessoal, o módulo News estava na versão 1.63, subindo para a versão 1.66, o problema de clicar no icon da Agenda em Editar Notícia continua a não funcionar.
Encontrei a classe ./class/calendar/JSCal2 que me pareceu desatualizada no núcleo do Xoops. Atualizei com a versão mais recente. E isso passou a funcionar.Formatação das Datas
As datas estão sendo apresentadas em formato DD/MM/AAAA pelo painel de edição, mas ao fazer a entrada pelo Calendário aparece AAAA-MM-DD! Será que isso pode causar algum problema?Não respeita o horário especificado.
Me dá a impressão que o horário especificado em seu campo a propriado é alterado internamente, aparecendo alterado na proxima edição. Parece que isso está relacionado com o horário do servidor, especificado no painel de administração do Xoops, em Preferencias, Especificações Gerais.Procurar fazer uma regra de três simples para ajustar a hora do servidor.
Calendário marca segunda feira em vermelho.
calendario O arquivo pt_BR.js em ./class/calendar/JSCal2/JSCal2/src/js/lang precisava ser configurado para marcar o sábado e o domingo como dias do final de semana. Neste arquivo você pode ajustar ainda o dia em que a semana começa. Se segunda feira ou domingo.
-
sobre o gabinete do seu microcomputador.
Recebi estes dias um gabinete para manutenção. Observei logo de cara que ele estava sem as duas tampas laterais do gabinete.
Fiquei pensando como tratar a situação.
Note que ao fragilizar a estrutura do gabinete, as placas que se encaixam dentro dela, podem se deslocar potencialmente causando curtos nos seus contatos, se energizados.
Inspecionando as placa, observei que a placa de video (adicional, aliem da OnBoard) tinha se soltado do seu slot, provavelmente por causa da alteração na geometria do gabinete durante o transporte. É claro que o fato de a placa não estar aparafusada contra o gabinete facilitou o estrago.
Claro que o equipamento fica mais leve para ser transportado sem as tampas laterais, mas elas precisam estar lá, não somente para proteger os componentes, mas também para melhorar a precisão da geometria do gabinete. Sem as tampas, o gabinete fica vulnerável a torções que podem danificar os componentes encaixados que assumem a constância dos contatos.
Não há muito o que fazer, é necessário fazer a manutenção, mas alertando ao proprietário e ao transportador os efeitos danosos que um transporte nestas condições pode trazer.
