





Unfortunately, it seems that Google has tightened its protection against automatic transcript parsing. YouTube now returns empty transcripts to automated tools, even when subtitles are publicly visible on the video page. This affects all libraries and plugins relying on transcript extraction. We are monitoring this behavior and working to find a stable workaround.
1:49 pm

December 2, 2024

Mine has also not pulled a video in 4 days. However, my syndicator log does not show any transcript pulling attempts (at least in the least day or so) but does say the filtering prevented a post from being published. I'll wait to see if any transcript attempts come up as I can't see further back than today's date.
It is extremely unusual to have 4 days without a post, so yes something must have changed.
Because all other operations were successful. If something is missing (e.g. an image or video was not inserted) - that's not a reason to consider a whole operation failed. We don't know how critical the extraction of the transcript was to the final result. Perhaps it makes sense to add a special checkbox that requires successful transcript extraction, similar to how the "Post thumbnail is required" option works.
The download links you're trying to access are 100% valid and publicly accessible - we've tested them directly, and the plugin successfully downloads them without any issues. If you're getting the error "Illegal characters found in URL" and both cURL and file_get_contents() fail, this usually points to a restriction on your server, most likely caused by the open_basedir setting in your PHP configuration.
This setting limits PHP's access to specific directories on the server, and when enabled, it can silently block essential operations like following redirects or creating temporary streams, which are required when downloading files from external sources like GitHub. On our servers, open_basedir is disabled, so everything works as expected - but when it's enabled, cURL can't follow redirects, and file_get_contents() may also silently fail or behave unpredictably.
To confirm this, just open the "Modification Tools" tab in the plugin, paste this code:
Login to see the code
Click "Proceed", and you'll see the result on screen. If everything is set up correctly, you should see this:
Login to see the quote
If instead you see a path or a list of directories (e.g. /home/username/:/tmp/), then your server is running with open_basedir enabled, which is very likely the root cause of the problem. In that case, you'll need to ask your hosting provider to either disable open_basedir or add the necessary system paths (such as /tmp/, /proc/, /dev/urandom) to the allowed list. Without this change, the plugin won’t be able to download external files properly.
The issue is not caused by a bug in the plugin or by invalid URLs - both Login to see this link and
Login to see this link are valid and accessible even via your broweser. The problem lies in your server configuration.
Additionally, misconfigured open_basedir settings can cause problems beyond just downloading files. They can also prevent certain feeds from being fetched correctly, which can lead to seemingly unrelated issues when importing content.
Based on your screenshot, the plugin successfully downloaded and extracted the required files - which means that cseo_file_get_contents() is working correctly on your server. The earlier errors in the log may have been caused by a temporary misconfiguration (such as open_basedir restrictions or a network issue), but right now everything looks fine.
Unless you're still experiencing a specific problem at this moment, there's no reason to troubleshoot further - the plugin appears to be functioning as expected.
However, if something still isn't working on your side (while it works perfectly for other users), the issue is clearly server-specific and needs to be investigated directly in your WordPress environment. Please provide admin access to your WP dashboard and send the credentials to Login to see this link so we can check it hands-on. Remote guessing won't help - the problem is on your server, and that's where it needs to be diagnosed.
10:14 am

March 3, 2024

I tried to rename the folder "old_" and update cyberseo plugin again. new folder is created, but i still get this error [15-06-25 08:06:25] Failed to retrieve
Login to see this link [15-06-25 08:06:25] cURL response: Illegal characters found in URL [15-06-25 08:06:25] cURL failed, switching to file_get_contents() [15-06-25 08:06:26] Failed to retrieve
Login to see this link [15-06-25 08:06:26] cURL response: Illegal characters found in URL [15-06-25 08:06:26] cURL failed, switching to file_get_contents() and grab youtube transcript still issue
i sent an email with admin access. thank you
Just a quick question regarding your latest screenshot. I see two additional folders, "old_simplexls" and "old_ytdlp." These folders were created exactly five minutes before the plugin downloaded and installed the correct files into the proper simplexls and ytdlp folders.
CyberSEO Pro does not create folders with "old_" in the name - there is no such logic in the code. This raises the question:
Who renamed or moved the original folders, and why? Was it done manually? Or automatically by another plugin? Or did someone on your hosting side intervene?
I need to understand what is modifying the plugin directory outside of its own logic because unexpected changes on the server make remote troubleshooting impossible.
Please let me know if you made these changes yourself or if someone else has access to the files.
Thanks for clarifying the old folders. That makes perfect sense. As expected, the plugin detected the missing folders and downloaded and reinstalled the components. That part is working correctly. The plugin successfully downloaded and installed the necessary scripts, and it is functioning as intended. Therefore, the original issue you raised has been resolved.
The remaining issue with yt-dlp is now an environment-level problem unrelated to the plugin itself. Whether the cause is an IP ban from YouTube, missing permissions, or server-side restrictions, your server administrator is the only one who can investigate and resolve these issues.
Login to see the quote
I think I've identified the cause: your server has shell_exec() (and most likely exec() and proc_open()) disabled in its PHP configuration. This prevents the plugin from running the yt-dlp binary at all - the command is blocked and never executed.
Consequently, no transcript is downloaded, and the plugin logs this as a missing file. This isn't a bug or failure in the plugin; it's a server-level security restriction that disables key PHP functions required for executing external processes.
To resolve the issue, your hosting provider or server administrator must remove "shell_exec" (and possibly "exec" and "proc_open") from the "disable_functions" directive in "php.ini." Until that's done, transcript extraction with yt-dlp is impossible on your current server.
As developers, we are responsible for the plugin's logic, and it is working exactly as intended. We can't fix what isn't broken, nor can we override the restrictions imposed by your server's environment.
Also, we attempted to run diagnostic code through the "Modification Tools" interface of the plugin, but your server immediately returned a fatal error, confirming that the PHP configuration has disabled eval(). This further limits our ability to help since neither code execution nor diagnostics are possible within WordPress. Combined with the blocked shell_exec(), it is technically impossible to perform transcript extraction in this environment.
I strongly recommend contacting your hosting provider to review these restrictions or to consider moving to a hosting environment that allows you to run external tools like YT-DLP.
11:10 am

March 3, 2024

I create PHP file to test fungsi shell_exec,
exec, dan
proc_open:
Login to see the quote
result:
Testing shell_exec: ✅ shell_exec output: shell_exec works Testing exec: ✅ exec output: exec works Testing proc_open: ✅ proc_open output: proc_open works For this "As expected, the plugin detected the missing folders and downloaded and reinstalled the components."
every time i click update, syndicator log showing:
[15-06-25 09:09:18] Failed to retrieve https://github.com/shuchkin/simplexls/archive/refs/heads/master.zip
[15-06-25 09:09:18] cURL response: Illegal characters found in URL
[15-06-25 09:09:18] cURL failed, switching to file_get_contents()
[15-06-25 09:09:19] Failed to retrieve https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp
[15-06-25 09:09:19] cURL response: Illegal characters found in URL
[15-06-25 09:09:19] cURL failed, switching to file_get_contents()
Thanks for the update - that helps clarify things further. Your test confirms that shell_exec, exec, and proc_open are all working on your server, which means yt-dlp should be executable. So if you're still getting this:
Login to see the quote
Then it's not a PHP-level restriction, but likely a networking or yt-dlp-level issue. For example:
- yt-dlp may be unable to reach YouTube (due to DNS, firewall, or network restrictions).
- YouTube may be responding with a CAPTCHA, an error page, or blocking your server's IP. If you have accessed YouTube many times in a row, trying to download the video and transcript, then your IP is most likely blocked there.
To investigate this further, we would need to capture the actual stdout/stderr output from the yt-dlp execution. The plugin currently doesn't log that, but we may consider adding such a feature in a future update. As for this part of the log:
Login to see the quote
This confirms that your server's cURL extension is returning a false "Illegal characters found in URL" error, even though the URL is 100% valid. This kind of false positive typically points to an outdated or misconfigured libcurl library, or to environmental issues such as broken locale settings, encoding mismatches, or a buggy PHP/cURL build.
Fortunately, the plugin is designed to handle such failures gracefully. It automatically falls back to file_get_contents() when cURL fails. As a result, the required files were downloaded and installed correctly. Although the cURL error appears in the log, it doesn't affect the plugin's functionality in this case (the log says, "file_get_contents() was used when cURL failed"). The components are being downloaded and installed properly - so nothing is broken on the plugin's side. To debug the transcript issue further, you could try running this command directly on your server via SSH (if you have access):
Login to see the code
Then check if a .json3 file is created and contains transcript data. If it doesn't, the issue lies in the environment or YouTube's response - not in the plugin.
Most Users Ever Online: 541
Currently Online:
6 Guest(s)
Currently Browsing this Page:
2 Guest(s)
Top Posters:
ninja321: 86
harboot: 70
s.baryshev.aoasp: 68
Freedom: 61
Pandermos: 54
MediFormatica: 49
Member Stats:
Guest Posters: 337
Members: 3018
Moderators: 0
Admins: 1
Forum Stats:
Groups: 1
Forums: 5
Topics: 1710
Posts: 8811
Newest Members:
contato.cezar.vieira, zarata.stz, kravproton, vipulmediaworks, braibantjulien, kustomerAdministrators: CyberSEO: 4149