Mais uma vez, você ilumina tudo e torna tudo claro! Cheguei a intuir de que o erro estivesse aí e troquei o https pelo http mais de uma vez, mas por algum motivo o navegador retornava o https… O “algum motivo” devia ser um caché que retornava o https, mesmo com o http.
E mais uma vez você resolve tudo e, mais uma vez, fico muito agradecido!
Porém, novamente tropeço no mesmo erro…
Desta vez não tem a ver com https…
O arquivo abre fora da página do item. Para burlar abertura interna, tenho que transformar o arquivo em “Relation (url)” em www.veroteatro.com/sombras/portodefiguras_eros.pdf
O erro acontece com o endereço http://www.veroteatro.com/sombras/portodefiguras_eros.pdf no campo Relation (que é do tipo url).
O erro já não acontece quando abro no navegador o endereço:
PDF.js viewer http://veroteatro.com/sombras/portodefiguras_eros.pdf
Preciso, mais uma vez, da sua luz para saber onde estou errando.
bom dia @batelada
vendo aqui o endereço que você disponibilizou, ainda ocorre um erro de CORS:
Outra forma de evitar esse tipo de erro é fazendo o servidor permitir o CORS, adicionando o cabeçalho:
Header add Access-Control-Allow-Origin “*”
algumas referências:
–
Abraços
Esse problema também ocorre comigo. Analisando em ambiente local, verifiquei que durante o procedimento de upload, antes publicar o item, o arquivo é armazenado em uma pasta com esse prefixo x e a sua visualização fica indisponível exibindo esse erro que outros acima apresentaram. Após publicação, o diretório perde o prefixo, e o arquivo passa a ser exibido corretamente. Ah, dessa forma ocorre se a visibilidade for PÚBLICA.
Em se tratando de visibilidade PRIVADA, todo o procedimento inicial anterior, ocorre de forma idêntica, no entanto após a publicação do item, o arquivo continua apresentando o mesmo erro e a visualização não é permitida (mesmo estando logado como administrador).
Via localhost, ele apresenta erro de CORS:
Em produção, erro 500:
boa noite
@tigurio você pode fazer esse testes mencionado aqui:
Olá @vnmedeiros ,
Pra mim não é criado essa estrutura pois estou com uma estrutura multsite, então dentro da pasta upload, ainda tem os diretórios que apontam para o site (uploads/sites/5/[pasta do arquivo]). Seguindo a estrutura multisite, sou direcionado ao aquivo 404 padrão do tema.
O que eu percebo aqui é que durante o processo de upload/criação do item, o caminho apontado para o arquivo no frame, não é na posta com o prefixo x . Me parece que por padrão, o Tainacan, gera o arquivo como se fosse Privado, e apenas após a confirmação da postagem, ele exibe desfaz dessa pasta privada gerando a pasta pública.
No entanto, no caso de optarmos por de fato ser um documento de visualização privada, o arquivo não é exibido na visualização do painel de edição.
isso está correto, antes do usuário publicar o item ele é mantido como um rascunho, assim seu acesso deve ser restrito e o prefixo _x_ é adicionado nas pastas dos anexos associados a ele para manter a privacidade (protegendo arquivos de itens privados). Quando o usuário logado tenta acessar um anexo de um arquivo privado o Tainacan tem que verificar se ele tem permissão e então redirecionar corretamente para o endereço do arquivo (no caso adicionando o prefixo _x_).
para que o redirecionamento funcione corretamente o servidor deve sobrescrever a resposta e encaminhar a resposta para o template_redirect 404 do wordpress nesse momento o Tainacan vai tentar encontrar o arquivo correto se for possível.
No seu exemplo @tigurio o servidor estar retornando um erro 500 ao tentar acessar um arquivo que não exite:
ou para uma página "Not Found":
Creio que dentro de alguma dessas subpastas você tenha um arquivo .htaccess que esteja configurado para encaminhar um erro 404 ou 500 do servidor apache2 sem ser redirecionado para os templates do wordpress.
abraços…
Caro @vnmedeiros (sem querer ser chato, mas já sendo kkkkkkk),
Então meu camarada, ocorre que o arquivo deveria estar visível no viewer enquanto o editor/administrador faz o cadastro da publicação/postagem, independentemente de ser uma publicação privada ou pública, afinal, o editor necessita visualizar o arquivo que está vinculando. Essa questão da visibilidade, se privado ou não, deve-se ater apenas aos usuários do site (ou aqueles que não tiverem a permissão de edição), e não a seus editores e administradores.
Verifiquei aqui e nada consta referente a essa questão no .htaccess. Mas tudo bem, esse teste que você fez eu compreendo que neste caso está realmente estranho, mas não vejo relação com o problema que estou relatando, já que seu teste foi o de acessar um arquivo via URL, e o problema que relato trata da exibição/visualização do arquivo durante o processo de criação da postagem.
Resumindo tudo, a questão é "porque DURANTE O PROCESSO DE CRIAÇÃO DA PUBLICAÇÃO/POSTAGEM, o viewer está apontando para um arquivo na pasta pública quando no ato do upload o arquivo é vinculado a uma pasta privada (estou tratando de publicação do tipo pública). Após confirmação da publicação, o viewer passa a exibir o arquivo corretamente, pois neste momento, a pasta que estava com o prefixo deixa de ter este e o referenciamento de fato ocorre. Já no caso de ser uma publicação PRIVADA, o viewer não exibe o arquivo nem na tela de EDIÇÃO DA PUBLICAÇÃO/POSTAGEM.
O fato dos editores não conseguirem visualizar o arquivo durante o processo de criação da postagem não deveria ocorrer, pois a visualização serve inclusive como confirmação do arquivo a ser publicado.
Grato pela compreensão
Boa tarde, vamos lá, tentar explicar minha linha de raciocínio aqui:
Sim justamente esse é o comportamento esperado, estou querendo entender o que no seu caso pode estar levando ao problema. Acontece que quando você está criando um item novo, esse é criado como um “rascunho automático” primeiramente (ou seja com acesso restrito) até ele ser “publicado” ou mantido como “rascunho”. Nesse período (antes de ser publicado) qualquer anexo ou documento enviado vai ser salvo em uma pasta protegida, ou seja, uma pasta com o prefixo _x_ por padrão.
Aqui temos a principal questão, “Como recuperar esse arquivo presente na pasta protegida, porém utilizando a URL original gerada pelo controle de mídias do WP?”
A estratégia que utilizamos foi interceptar o erro 404 (arquivo ou URL inexistente) e fazer as validações: a URL solicitada é de um item privado? Se sim, o usuário logado tem permissão para acessar? Se sim, o Tainacan reescreve o caminho da requisição, para o endereço correto da pasta protegida. Esse comportamento pode ser visto aqui:
Por isso o meu interesse em saber se a página 404 do template está sendo exibida, pois, se o servidor matar a requisição nesse momento (não redirecionando para o template 404) o processo para acessa os arquivos presentes nas pastas protegidas não vai ser acionado.
Abraços…
Bom dia.
@tigurio como você resolveu o erro 404? Estamos tendo um problema em que as imagens não aparecem quando o item é classificado como restrito.