WordPress não mostra a “Admin Bar”

Hoje depois de atualizar uma das minhas instalações de WordPress para a versão 3.1 a nova barra de admin que aparece quando estamos no site não aparecia, como é um theme feito por mim resolvi investigar o porquê.

A causa para a barra não aparecer é que não estava a implementar corretamente a class do body, para resolver este problema bastou no ficheiro em que abro a tag body, bastou adicionar a seguir à abertura da tag <body> adicionar a função do wordpress que faz echo da class adequada para ser possível a apresentação da dita barra de admin. O código a adicionar é o seguinte <?php body_class($class)?>, pelo que a declaração do body ficará <body <?php body_class($class); ?>>. E basta isto para tornar qualquer theme compatível com a nova barra de admin omnipresente.

C# usar objecto COM (32 bits) em sistemas 64bits

Comecei recentemente a trabalhar com um Windows 64 bits, hoje tentei abrir e executar um projeto de C# para fazer umas alterações, tudo abriu corretamente nenhum problema aparente, mesmo depois de fazer build não era gerado nenhum erro nem sequer um único Warning.

Quando tento fazer debug recebo um erro bastante estranho, numa parte do código que acede a uma DLL que serve de ponte entre a minha aplicação e outra aplicação de código fechado, esta dll é fornecida pelo fabricante (que por acaso é a Microsoft), depois de experimentar mil e um coisas e nada fazer com que o projeto corresse coloquei a versão que resultava do debug, numa máquina com XP 32bits e o projeto correu lindamente.

Depois de alguns testes a solução para o problema foi mudar a configuração da “Solution Plataform” para x86 por defeito é “Any CPU”, já agora no Visual Studio Express não aparece por defeito activa esta opção é necessário ir a Tools ““> Options ““> Projects And Solutions e marcar “Show Advanced Build Configurations “.

E é este o workaround para usar objectos COM de 32 bits em sistemas de 64 bits, referi em cima C# mas deve funcionar nas outras linguagens da .net FW.

Ficheiros de Log do Active Directory

A propósito do artigo anterior fica a lista da localização dos vários ficheiros de log criados na implementação de politicas de Grupo na maquina cliente, estas tabelas foram copiadas na integra do site da Microsoft (copiei para evitar futuros 404 ao aceder á página da MS) !!!!

Output from: Is located in this file: Enable verbose logging by adding this key or value”¦ “¦to this registry key

Group Policy core (UserEnv) and registry CSE

%windir%\debug\usermode
\UserEnv.log

UserEnvDebugLevel = REG_DWORD 30002

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows NT
\CurrentVersion
\Winlogon

Security CSE

%windir%\security\logs
\winlogon.log

ExtensionDebugLevel = REG_DWORD 0x2

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows NT
\CurrentVersion
\Winlogon
\GpExtensions
\{827d319e-6eac-11d2-a4ea-00c04f79f83a}\

Folder Redirection CSE

windir%\debug\usermode
\fdeploy.log

FdeployDebugLevel = Reg_DWORD 0x0f

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows NT
\CurrentVersion
\Diagnostics

Software Installation CSE

%windir%\debug\usermode
\appmgmt.log

Appmgmtdebuglevel=dword:0000009b

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows NT
\CurrentVersion
\Diagnostics

Windows Installer
(deployment-related actions)

%windir%\temp
\MSI*.log

Logging = voicewarmup

Debug = DWORD: 00000003

HKEY_LOCAL_MACHINE
\Software
\Policies
\Microsoft
\Windows
\Installer

Windows Installer
(user-initiated actions)

%temp%
\MSI*.log

Logging = voicewarmup

Debug = DWORD: 00000003

HKEY_LOCAL_MACHINE
\Software
\Policies
\Microsoft
\Windows
\Installer

E já agora os do Servidor:

Output from: Is located in this file: Enable verbose logging by adding this keyword”¦ “¦to this registry key

GPMC:
error logging only

%temp%\gpmgmt.log

gpmgmttracelevel=1

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows NT
\CurrentVersion
\Diagnostics

GPMC:
error and verbose logging

%temp%\gpmgmt.log

gpmgmttracelevel=2

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows NT
\CurrentVersion
\Diagnostics

GPMC:
Output only to log file (not to debugger)

%temp%\gpmgmt.log

gpmgmtlogfileonly=1

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows NT
\CurrentVersion
\Diagnostics

Group Policy Object Editor:
Core-specific entries

%windir%\debug\usermode
\gpedit.log

GPEditDebugLevel = REG_DWORD 0x10002

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows NT
\CurrentVersion
\Winlogon

Group Policy Object Editor:
CSE-specific entries

%windir%\debug\usermode

\gptext.log

GPTextDebugLevel = REG_DWORD 0x10002

HKEY_LOCAL_MACHINE
\Software
\Microsoft
\Windows NT
\CurrentVersion
\Winlogon

Group Policy Não Instala Software Gerido

Numa instalação de Active Directory com várias Politicas de Grupo configuradas, tudo funcionava excepto a instalação de software, isto é todas as configurações que alterava em cada politica no próximo reboot ou no próximo “gpupdate /force” entravam em vigor excepto a instalação de software gerido, o que me levou a crer que não era erro de configuração é que isto não acontecia em todos os computadores do dominio.

Depois de pesquisar todas as combinações possiveis  do erro em Inglês e em Português no Google não conseguia achar a solução, comecei então a ler os logs das politicas de grupo dos computadores em que verifiquei o problema, e o sintoma era comum nenhum encontra o controlador principal do dominio no arranque, no log em todos tinha o mesmo erro (está a bold):

USERENV(2c4.688) 12:58:22:109 ProcessGPOs: Forced option changed policy mode.
USERENV(2c4.634) 12:58:23:593 ProcessGPOs: Forced option changed policy mode.
USERENV(2c4.664) 12:58:23:718 PolicyChangedThread: UpdateUser failed with 6.
USERENV(2c4.2c8) 12:59:21:640 CUserProfile::CleanupUserProfile: Ref Count is not 0
USERENV(2c4.2c8) 12:59:21:656 CUserProfile::CleanupUserProfile: Ref Count is not 0
USERENV(2c4.2c8) 12:59:21:656 CUserProfile::CleanupUserProfile: Ref Count is not 0
USERENV(2c4.600) 12:59:23:812 ProcessGPOs: The DC for domain REMOVIONOMEDODOMINIO is not available at startup. retrying
USERENV(2c4.600) 12:59:44:031 ProcessGPOs: DC for domain REMOVIONOMEDODOMINIO is reachable after retries.
USERENV(2c4.600) 13:05:20:265 ProcessGPOs: Extension Instalação de software ProcessGroupPolicy failed, status 0x643.
USERENV(2c4.1a8) 14:31:58:924 PolicyChangedThread: UpdateUser failed with 0.
USERENV(2c4.f3c) 14:41:06:558 PolicyChangedThread: UpdateUser failed with 6.
USERENV(2c4.f80) 14:42:15:814 PolicyChangedThread: UpdateUser failed with 0.

Depois de vários testes a causa deste problema está no carregamento da rede, que não sei se será dos drivers ou das placas de rede demoram mais a ficar disponiveis no sistema e na altura que o sistema vai procurar o PDC, não o encontra!!

Solução: Alterar o tempo que o Windows (cliente) demora até concluir que não encontra o DC, por outras palavras mudar o timeout, para isso basta criar a seguinte chave no registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GpNetworkStartTimeoutPolicyValue

do tipo DWORD e com valor decimal de 30, caso o problema persista deve-se aumentar o valor até o mesmo estar resolvido.

WordPress Child Themes

Recentemente depois de actualizar um blogue para o WordPress 3.0, cliquei sem em actualizar Plugins e Temas sem me lembrar que o tema usado estava modificado. Ao actualizar as modificações foram perdidas”¦ para evitar o mesmo erro no futuro decidi criar um Child Theme, e que é um Child Theme???

Um Child Theme é um Theme que deriva de outro Theme, ou seja no Child Theme que podemos chamar Tema Derivado implementamos apenas as modificações ao tema original, se por exemplo quiser-mos alterar algo no ficheiro single.php alteramos apenas esse ficheiro ficando o original do tema intacto, viabilizando assim futuras actualizações, sem comprometer as alterações que fizemos.

A estrutura de um Child Theme é bastante simples, primeiro criamos um directório para alojar os ficheiros modificados, fazemos as alterações que pretendemos, aconselho a copiar o ficheiro original do Theme Parent e fazer ai as alterações. Depois de termos as alterações pretendidas falta apenas criar o ficheiro onde o WordPress vai ler as informações do Tema esse ficheiro tem o nome de Style.css e vai sobrepor o Style.css do tema original á semelhança do que acontece com os outros ficheiros que colocar-mos no nosso Child Theme, este Style.css tem uma particularidade em relação ao original, que é uma tag que informa o WordPress de qual é o tema em que nos baseamos, esta tag é a tag Template. Deixo a seguir o Style.css para um Child Theme baseado no novo tema por defeito do WordPress que é o “Twenty Ten”:

/*
Theme Name:     Nome do Child Theme
Theme URI:      http: //UmUrlQualquer.com/
Description:    Descrição do Child Theme 
Author:         O seu nome
Author URI:     http: //OutroUrlQualquer.com/
Template:       twentyten
Version:        0.0.1
*/

 

Se quisermos usar o css do tema original basta fazer um import do style.css original, que no caso do tema Twenty Ten será:

@import url("../twentyten/style.css");

Podemos ainda no style.css modificar o css original, basta criar os elementos com o mesmo nome e adicionar as nossas personalizações.

Depois do tema criado é só fazer upload para a pasta “wp-content/themes/” e no painel de administração do blogue activar o mesmo. E os problemas com as actualizações do tema principal deixam de ser um  problema.