This is not really question, more an answer...
I recently updated Joomla to version: 3.4.8 and after that the Global configuration page was missing the CSS-styling.
I quickly tried solving it and came across alot of similar cases from searching Google... Some had "answers", but not and easy fix..So if anyone else is stuck with this problem, here is the solution :)
Run your FTP and locate the folder name "libraries" in your Joomla install on your server.
Then take a backup of this "Just in case".
Delete this folder and replace it width the same folder from a fresh Joomla install.
Some of the files in that folder was causing the issue, and if don't bother finder the specific file, then just do the above and the problem is solve.
Hope this helps someone :D
Run your FTP and locate the folder name "libraries" in your Joomla install on your server.
Then take a backup of this "Just in case".
Delete this folder and replace it width the same folder from a fresh Joomla install.
Some of the files in that folder was causing the issue, and if don't bother finder the specific file, then just do the above and the problem is solve.
Hope this helps someone :D
So basically you were hacked. Simply replacing the libraries and includes folder is enough to get your site online again, however it is not the solution. You need a complete security audit and review conducted.
Many hacks for Joomla install dodgy session or cache handlers - as a hook for them - and this can and will create an issue when loading the Configuration page.
Also if you are on a mac and you upload dot underscore ._ files to some parts of the libraries folder you can again kill the configuration page as Joomla is stupid and includes all the files in the folder irrespective of filename (actually a security issue in itself, but been that way for ages)
Related
For the past 6 or so months I have been working on Laravel projects that are closer to web apps rather than full, content managed sites.
Recently I've started a Wordpress project and there's something that baffles me, how do you use Git with WordPress?
I ask because in Laravel you can basically push everything asides from node_modules, storage and the composer vendor folder.
I have also read that it is not a good idea to store wp-config in your repository, it's a strange one as Laravel uses an .env file to similar effect.
I found the following .gitignore
*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php
/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz
You can ignore almost everything with the following exceptions:
wp-content/themes/my-theme (your theme and/or child theme)
wp-content/plugins/my-custom-plugin. (any custom plugins you create)
Additionally, I have found two very good sources for gitignore files for WordPress. The first which is very straightforward is on gitignore.org and the second which is extremely surgical is by Sal Ferrarello and can be found here: https://salferrarello.com/wordpress-gitignore/
Just modify as required and of course, avoid the config.php. It has install specific info such as your database host & login which you may not want to expose to prying eyes.
Laravel's .env file contains sensitive data just as WP's wp-config.php so we don't usually push it into the repo.
As to how I use Git with WordPress:
I exclude the wp-config.php file, the developer cloning the repo doesn't need it anyways: they can fill in the credentials themselves when working on the project on their local development environment. Another good reason to leave this file out is you don't want to expose your site's details (host, database name, username, password, salts, etc) to the world.
I exclude the uploads folder. The reason is that while developing we usually add dummy images to our posts and pages, images that won't be used at all when the site is finally ready for production so there's no reason to "pollute" the repo with these.
One of the things I love about Laravel is that database changes can also be tracked thanks to migrations. WordPress, on the other hand, doesn't have anything like that so you'll have to find a plugin (or some other mean) to keep your local database in sync with the staging one.
Update:
Since you updated your question to ask which files should be specifically excluded from the Git repo, I think the ones you posted from that .gitignore file you found are good enough. I don't see the need to ignore the readme.txt file though but that won't do any harm either.
I can't figure out why my wp site is stuck in maintenance mode. I made no update and there's no .maintenance file. I can't even access to admin.
Has anyone encountered similar issue?
Try renaming the plugins/ folder to _plugins/ and see if you can access your website, if you can, rename the plugins folder to plugins/. Try disabling every plugin and re-enabling the plugin until your site breaks again to find the culprit.
If you can't access your website after renaming the plugins folder, disable your theme (by renaming the folder).
These are the common troubleshooting steps, if you provide more details, I will be able to help you more :/
Finally got it, it was a domain redirection error. The url pointed to a folder with a default index.html.
If anyone is still having this problem in 2017, I fixed it by going to my /wp-content/endurance-page-cache and deleting two files called _index.html and a_index.html (to be safe, I would download these first so that if this ISN'T the issue you can still recover them). This is what my domain was redirecting to.
Before I figured it out, I deactivated the WP Maintenance Mode plugin, looked through the directory for a .maintenance file (which I didn't find even after showing hidden files), and completely deleted the plugin. So hopefully if anyone is having this issue, this will work for you!
The back story: I transferred all the data from wordpress.com site to a self hosted site. That messed with a lot of the images in the posts etc. (not displaying) so naturally I just started messing with things (I don't really know what I'm doing). After changing a bunch of file permissions (with FileZilla) the images started to work but now all my plugins stopped working. I deleted them and tried to reinstall and I get this error:
Unpacking the package…
Installing the plugin…
Could not create directory. /homepages/35/d579288618/htdocs/kevin-heinrich.com/kevin-heinrich/wp-content/plugins/jetpack/
Plugin install failed.
I don't really know where the "/homepages/35/d579288618/htdocs/..." part of the error is coming from...
I have tried changing ALL my file permissions to 777, no luck.
I tried manually downloading a plugin and putting it into the plugins folder via FTP, no luck. (The folder is in there but nothing appears on my dashboard).
Any help would be greatly appreciated. I'm afraid to keep messing around on my own because well, I break things.
Wow what a simple problem. After literally a month of banging my head against the wall...
My problem was that my plugins folder was in my uploads folder NOT my wp-content directory. I moved and boom solved.
Hopefully any other idiot who tinkers where he/she shouldn't might find this helpful :)
Just had this issue. Check that user and group in /etc/php/php-fpm.d/www.conf are set to www-data. By default it's http.
I've been trying to uninstall a magento plugin I've recently installed to reinstall it using Magento Connect. The log said that the plugin uninstalled successfully and if I go to the admin panel, the plugin's no longer there but when I went back to Magento Connect, the plugin is still listed there so I can't reinstall. Why is this happening?
Based on the answers, what I've tried so far are:
Clear cache through Admin Panel
Removed wordpress entry in core_resource
I've made sure wordpress xml in etc/modules is removed
I've made sure Fishpig folder in app/code/community is removed
Cleared cache in var/cache
Cleared cache in downloader/cache
Checked if there's xml for wordpress in var/package (there was none)
Reindexed magento
And none of this worked. The wordpress extension was still listed as installed in Magento Connect. I've been trying to uninstall repeatedly but it just won't go away even though the log said that the uninstall process completed. I've also tried reinstalling and upgrading. No success.
to remove the extension:
remove all the modules files, includeing the file which enables the module:
app/etc/modules/COMPANY_MODULE.xml
also make sure the entry is gone from the database by removing the correct entry in table:
core_resource
then refresh the magento cache
It should then disappear from connect.
Which module have you installed? Can you give me name so I can give you solution if possible for me. If module add new own tables in db then dont delete any module file otherwise may be magento crash. Its better way to uninstall from magento connect manages.
Clear the .cache folder in the downloader directory, in addition there is also another area where an xml can be present in var/package/
The package files are from magento connect so delete from here and have another check!
delete all files in var/cache/ and double check you are actually working in the right folder! if you have another caching system then clear it.
To delete the extension from Magento Connect (I believe you have already uninstalled it from Magento) you will need to delete the file var/package/Fishpig_Wordpress_Integration_{{version}}.xml
Thank you very much for all your help and time. I really appreciate it. I've managed to solve the problem. It's apparently a problem with permissions. I didn't realize soon enough that the permission for all folders had to be 777. I had most folders set to 777 except for 2 files on my etc folder (local and locals.xml) because of security issues. But after getting a go signal changing said permissions, I managed to uninstall the plugin and reinstall it. Now the Wordpress is fully integrated in the website with no problems and I've also returned the permissions for local and locals.xml back to it's original. Thanks again a lot for all your time.
I run my blog using Wordpress and all too recently became a big believer in SCM. I really want to put my site into subversion (that's what I'm using right now, maybe git will come later) but I can't think of the correct way to do it yet. Basically, my repository is set up currently with an 'implementation' directory and a 'resources' directory, with implementation holding what will eventually be published to the live site. I want to be able to preview my site locally without having to upload to the server for obvious reasons. However, to do this I found that I needed to actually install Wordpress locally (not just copy the remote site down to my local box). This was told to me over at Wordpress.org.
This brings up the problem of being able to use SCM with the install because I need to upgrade my local site every now and then but this generates inconsistencies with subversion because it can’t track what’s going on because an external system is messing with it’s repository structure. That just won’t work.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
Anyway, I’m sure other people have tackled this and the solution is probably applicable to many apps similar to Wordpress (Drupal, phpBB, phpMyAdmin, etc.). So, how do you do it?
It's actually not that hard to do, but I'll break it down into a few suggestions here. What you're describing is more or less a "vendor drop" directory. This is basically where you maintain the code in SVN, but replace the contents with the newer stuff as it comes out.
What you should start with is an empty directory. Set up an SVN repository, and then do an SVN checkout into the empty directory (it will still be empty, except it will get a hidden .svn directory added). Next, install wordpress here normally, and then add its files to svn. You can probably just "svn add *" but be careful, and remove anything you don't want versioned (uploads/temp/cache directories, if applicable). You can also use the svn:ignore property to tell it to ignore certain directories or file types, if you'd like. Run "svn stat" to show you what is going to be checked in, etc, and once all is good, commit it (svn commit) and start working from there. Now you have a base installation of wordpress in SVN.
As you work and make changes, commit them.
When it comes time to upgrade, simply replace wordpress over top of what you have. Make sure when you replace directories, you replace the contents, and not the whole directory itself. You don't want to lose the hidden .svn folder in every folder because that is what will mess subversion up. Do an svn stat and/or svn diff to figure out what's changed, if anything, and mostly what's newly-added. At this point, you can commit again.
To deploy on your production site, you can do an svn export, or do a regular checkout into the web directory. If you do a checkout, be sure to only update when you are ready to deploy.
This is the method I'm testing. It takes some time to setup but you should then (in theory) have a future-proof install:
Installing WordPress The Right Way
Also look at svn:externals for pulling in plugin updates:
Use svn:externals to install WordPress plugins
I think the upgrade part can even be a little easier than that; I do this with the most current version of both 2.5 and 2.6, as well as bleeding-edge trunk revision of WP.
Since Wordpress offers all of their stuff as subversion repositories, getting the current rev of a stable tag is as easy as making the blog directory and then
# svn co http://svn.automattic.com/wordpress/tags/2.6.2/ (replace the current rev here for the first check out).
When an upgrade is available, simply navigate to your blog directory and run
#svn sw http://svn.automattic.com/wordpress/tags/2.6.3/ (or whatever wordpress rev you're updating to)
Then releasing to your production site is just an export, as gregmac mentions
However, I don't think this answers your actual question, which I interpret as "How do I keep my custom stuff in SCM while being able to upgrade Wordpress". Your instainct about what directories to tack is pretty much on target (your own personal blog's stuff - themes, pplugins - will be in wp-content, so you should only need to put that into subversion) but I'm not proficient enough with subversion to tell you how to place the directory into your own repository while still being able to rely on Wordpress's repo for upgrades. My "SCM" for those files on my site is an off-server copy of the wp-content directory.
Maybe from that standpoint gregmac's answer works better for you.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
That's exactly how I version control my blog. I've found that it works great. Generally, if you're editing WordPress' files, you're doing it wrong and will be in for misery when it's time to upgrade.
To simplify this, I use TortoiseSVN. I navigated to my /wp-content/themes/ directory in Windows Explorer, right clicked on my custom theme's directory, and chose import from the context menu. After importing all of the existing files, I performed a checkout on that directory and everything was set.