Hola Cracks.
Cuando me di de alta con vosotros, seguí un consejo (ya no me acuerdo de quien) y para almacenar todas mis imágenes creé un subdominio "contenidos.orgonangel.com"
Todo empezó porque Wordfence me daba avisos todos relacionados con imágenes que recién subí a mi Blog. Me pasé por la carpeta contenidos en mi FTP y "oh sorpresa!" esta vacía!!!
¿Qué he hecho mal?
Luego mirando en otra parte del cPanel pude sacar este pantallazo que no entiendo ná de ná.
Ayuda porfi
Gracias y saludos 🙂
URL del sitio: Contenido solo visible a usuarios registrados
Hola,
Entiendo que utilizas o utilizaste un CDN. Este servicio, permite que tu web descargue contenidos estáticos en paralelo, y lo haga más rápido a través de los servidores, puedes revisar la siguiente guía: https://www.webempresa.com/blog/como-conseguir-que-tu-wordpress-sea-ultrarrapido.html
Luego el código que se visualiza en captura seguramente lo genero el plugin que estabas utilizando para que funcione de forma correcta el CDN.
Hola Johnny.
ahora sí que sí estoy hecha un lio. Esto me puede... te comento. cuando activé el CDN (y creo que incluso antes de eso), me salía un mensaje arriba del todo que decía
WP_CACHE constant added to wp-config.php
If you continue to see this warning message please see point 5 of the Troubleshooting Guide. The WP_CACHE line must be moved up.
Cuando me meto en el enlace de Troubleshooting Guide y miro el punto 5 del mismo me encuentro con una explicación como esta:
Description
This plugin generates static html files from your dynamic WordPress blog. After a html file is generated your webserver will serve that file instead of processing the comparatively heavier and more expensive WordPress PHP scripts.
The static html files will be served to the vast majority of your users, but because a user’s details are displayed in the comment form after they leave a comment those requests are handled by the legacy caching engine. Static files are served to:
Users who are not logged in.
Users who have not left a comment on your blog.
Or users who have not viewed a password protected post.
99% of your visitors will be served static html files. Those users who don’t see the static files will still benefit because they will see different cached files that aren’t quite as efficient but still better than uncached. This plugin will help your server cope with a front page appearance on digg.com or other social networking site.
If for some reason “supercaching” doesn’t work on your server then don’t worry. Caching will still be performed, but every request will require loading the PHP engine. In normal circumstances this isn’t bad at all. Visitors to your site will notice no slowdown or difference. Supercache really comes into it’s own if your server is underpowered, or you’re experiencing heavy traffic.
Super Cached html files will be served more quickly than PHP generated cached files but in every day use, the difference isn’t noticeable.
The plugin serves cached files in 3 ways (ranked by speed):
Mod_Rewrite. The fastest method is by using Apache mod_rewrite (or whatever similar module your web server supports) to serve “supercached” static html files. This completely bypasses PHP and is extremely quick. If your server is hit by a deluge of traffic it is more likely to cope as the requests are “lighter”. This does require the Apache mod_rewrite module (which is probably installed if you have custom permalinks) and a modification of your .htaccess file. Visits by anonymous or unknown users will be served this way.
PHP. Supercached static files can now be served by PHP. The plugin will serve a “supercached” file if it exists and it’s almost as fast as the mod_rewrite method. It’s easier to configure as the .htaccess file doesn’t need to be changed. You still need a custom permalink. You can keep portions of your page dynamic in this caching mode. Your server may not cope as well with a really large amount of traffic. (You’re gaming Digg aren’t you? You’ll need mod_rewrite, the rest of us are ok with PHP!)
Legacy caching. This is mainly used to cache pages for known users. These are logged in users, visitors who leave comments or those who should be shown custom per-user data. It’s the most flexible caching method but also the slowest. As each page is different it’s often better not to cache pages for these users at all and avoid legacy caching. Legacy caching will also cache visits by unknown users if this caching mode is selected. You can have dynamic parts to your page in this mode too.
If you’re new to caching use PHP caching. It’s easy to set up and very fast. Avoid legacy caching if you can.
Recommended Settings
Advanced users will probably want to use mod_rewrite caching, but PHP caching is almost as good and recommended for everyone else. Enable the following:
PHP caching.
Compress pages.
Don’t cache pages for known users.
Cache rebuild.
CDN support.
Extra homepage checks.
Garbage collection is the act of cleaning up cache files that are out of date and stale. There’s no correct value for the expiry time but a good starting point is 1800 seconds if you’re not using legacy mode. If you are using that mode start with an expiry time of 600 seconds.
If you are not using legacy mode caching consider deleting the contents of the “Rejected User Agents” text box and allow search engines to create supercache static files.
Likewise, preload as many posts as you can and enable “Preload Mode”. Garbage collection will still occur but it won’t affect the preloaded files. If you don’t care about sidebar widgets updating often set the preload interval to 2880 minutes (2 days) so all your posts aren’t recached very often. When the preload occurs the cache files for the post being refreshed is deleted and then regenerated. Afterwards a garbage collection of all old files is performed to clean out stale cache files.
With preloading on cached files will still be deleted when posts are made or edited or comments made.
See the WP Super Cache homepage for further information. Developer documentation is also available for those who need to interact with the cache or write plugins.
There’s a GIT repository too if you want to contribute a patch.
The changelog is a good place to start if you want to know what has changed since you last downloaded the plugin.
Interested in translating WP Super Cache to your language? Grab the development version where you will find an up to date wp-super-cache.pot. Send any translation files to donncha @ ocaoimh.ie and thank you!
The cache directory, usually wp-content/cache/ is only for temporary files. Do not ever put important files or symlinks to important files or directories in that directory. They will be deleted if the plugin has write access to them.
How to uninstall WP Super Cache
Almost all you have to do is deactivate the plugin on the plugins page. The plugin should clean up most of the files it created and modified, but it doesn’t as yet remove the mod_rewrite rules from the .htaccess file. Look for the section in that file marked by SuperCache BEGIN and END tags. The plugin doesn’t remove those because some people add the WordPress rules in that block too.
To manually uninstall:
Turn off caching on the plugin settings page and clear the cache.
Deactivate the plugin on the plugins page.
Remove the WP_CACHE define from wp-config.php. It looks like define( 'WP_CACHE', true );
Remove the Super Cache mod_rewrite rules from your .htaccess file.
Remove the files wp-content/advanced-cache.php and wp-content/wp-cache-config.php
Remove the directory wp-content/cache/
Remove the directory wp-super-cache from your plugins directory.
If all else fails and your site is broken
Remove the WP_CACHE define from wp-config.php. It looks like define( 'WP_CACHE', true );
Remove the rules (see above) that the plugin wrote to the .htaccess file in your root directory.
Delete the wp-super-cache folder in the plugins folder.
Optionally delete advanced-cache.php, wp-cache-config.php and the cache folder in wp-content/.
CDN
A Content Delivery Network (CDN) is usually a network of computers situated around the world that will serve the content of your website faster by using servers close to you. Static files like images, Javascript and CSS files can be served through these networks to speed up how fast your site loads. You can also create a “poor man’s CDN” by using a sub domain of your domain to serve static files too.
OSSDL CDN off-linker has been integrated into WP Super Cache to provide basic CDN support. It works by rewriting the URLs of files (excluding .php files) in wp-content and wp-includes on your server so they point at a different hostname. Many CDNs support origin pull. This means the CDN will download the file automatically from your server when it’s first requested, and will continue to serve it for a configurable length of time before downloading it again from your server.
Configure this on the “CDN” tab of the plugin settings page. This is an advanced technique and requires a basic understanding of how your webserver or CDNs work. Please be sure to clear the file cache after you configure the CDN.
Custom Caching
It is now possible to hook into the caching process using the add_cacheaction() function.
Three hooks are available:
‘wp_cache_get_cookies_values’ – modify the key used by WP Cache.
‘add_cacheaction’ – runs in phase2. Allows a plugin to add WordPress hooks.
‘cache_admin_page’ – runs in the admin page. Use it to modify that page, perhaps by adding new configuration options.
There is one regular WordPress filter too. Use the “do_createsupercache” filter
to customize the checks made before caching. The filter accepts one parameter.
The output of WP-Cache’s wp_cache_get_cookies_values() function.
See plugins/searchengine.php as an example I use for my No Adverts for Friends plugin.
Links
WP Widget Cache is another caching plugin for WordPress. This plugin caches the output of widgets and may significantly speed up dynamic page generation times.
Updates
Updates to the plugin will be posted here, to Holy Shmoly! and the WP Super Cache homepage will always link to the newest version.
Thanks
I would sincerely like to thank John Pozadzides for giving me the idea for this, for writing the “How it works” section and for testing the plugin through 2 front page appearances on digg.com
Thanks to James Farmer and Andrew Billits of Edu Blogs fame who helped me make this more WordPress MU friendly.
Translators who did a great job converting the text of the plugin to their native language. Thank you!
Gianni Diurno (Italian)
Omi (Spanish)
tomchen1989 and Christopher Meng (Simplified Chinese)
Tai (Japanese)
Vitaly (Ukranian)
Pseric and Priv (Traditional Chinese)
Ma�tre M� (French)
Mathias Roth (German)
Bar�� �nver (Turkish)
Elvis Fweb (Russian)
Fredrik Fors�ll (Swedish)
Alyona Lompar (Ukranian)
Nata Strazda (Lithuanian)
Alexander Alexandrov (Belarusian)
Michail Bogdanov (Romanian)
Anja Skrba (Serbo-Croatian)
FAQ
Note: this functionality is disabled by default. You will have to enable it on the Advanced Settings page.
There are 2 ways of doing this. You can use Javascript to draw the part of the page you want to keep dynamic. That’s what Google Adsense and many widgets from external sites do and is the recommended way. Or you can use a WP Super Cache filter to do the job but you can’t use mod_rewrite mode caching. You have to switch to PHP or legacy caching.
WP Super Cache 1.4 introduced a cacheaction filter called wpsc_cachedata. The cached page to be displayed goes through this filter and allows modification of the page. If the page contains a placeholder tag the filter can be used to replace that tag with your dynamically generated html.
The function that hooks on to the wpsc_cachedata filter should be put in a file in the WP Super Cache plugins folder unless you use the late_init feature. An example plugin is included. Edit dynamic-cache-test.php to see the example code.
There are two example functions there. There’s a simple function that replaces a string (or tag) you define when the cached page is served. The other example function uses an output buffer to generate the dynamic content. Due to a limitation in how PHP works the output buffer code MUST run before the wpsc_cachedata filter is hit, at least for when a page is cached. It doesn’t matter when serving cached pages. See this post for a more technical and longer explanation.
To execute WordPress functions you must enable the ‘Late init’ feature on the advanced settings page.
Ahí ya me pierdo 🙁
Hay algo que pueda hacer que no sea tan complicado?
Saludos
Hola Mari Carmen.
La mejor opción es utilizar un servicio como puede ser Amazon S3 para el tema de servicios de servicio CDN y con un plugin realizar la conexión.
Ventajas:
.- Tienes repartidas tus imágenes en diversos servidores y se descargan dependiendo de la localización del usuario.
.- No ocupa espacio en tu hosting.
Si quieres configurar el CDN en subdominios puedes utilizar el plugin -> Domain Sharding
Un saludo
Muchas gracias Pepe. Ahora voy a rizar el rizo.
Veo que Amazon S3 solo trabaja con Wordpress. Hay alguna solución para hacer lo mismo con Prestashop?
Verás, tengo mi Presta en www.orgonangel.com y WP en www.orgonangel.com/blog.
Tú que harías en mi lugar? Eso sí, explicame la versión para ultra-principiantes 🙂
Un fuerte saludo
Hola Mª Carmen.
En el siguiente enlace tienes un tutorial de como configurarlo:
Cómo crear un CDN en Amazon CloudFront para Prestashop
Para la carga de imágenes estáticas en subdominios estos serian los pasos a realizar:
1- Crea 3 subdominios para tu tienda online, por ejemplo estaticos1.orgonangel.com, estaticos2.orgonangel.com, estaticos3.orgonangel.com y que los 3 apunten a orgonangel.com.
2- En la backoffice de tu Prestashop, dirígete a Parámetros avanzadas > Rendimiento y activa todas las opciones de CCC ' "Smart cache" para las hojas de estilo (CSS) '
3- Una vez esté todo el CCC activado, tienes que configurar los subdominios. Esto lo haces en la opción Servidores multimedia, Configurando los 3 servidores en cada una de las casillas Servidor multimedia n°1/2/3.
Una vez guardada esta configuración, Prestashop repartirá automáticamente los enlaces de carga de imágenes, CSS y Javascripts en esos 3 subdominios.
Un saludo